Software modules contain executable code in the 1C language, which is necessary in order to respond in a certain way to the actions of the system or user when visual development tools are not enough. We can also describe our own methods (procedures and functions) in software modules.

Typically a software module consists of three sections:

• variable declaration area;
• area of ​​description of procedures and functions;
• main text of the program.

Example of a program module structure:

//***************** VARIABLE DECLARATION AREA **********************

Perem Last Name Export; / /this is a global variable
Change Name, Patronymic; //this is a module variable
Perem full name; //this is also a module variable and can be accessed

//from any procedure and function of our module

//*************** AREA DESCRIPTION OF PROCEDURES AND FUNCTIONS ****************

Procedure Procedure1 ()
Variable Total ; / /Result is a local variable (procedure variable)

Total = Last name + " "+ First name + " "+ Middle name;

End of Procedure

Function Function1()

// function operators

Return(LastName + " "+ FirstName);

EndFunction

//******************* MAIN TEXT OF THE PROGRAM ***********************

Last name = "Ivanov";
Name = "Ivan";
Patronymic = "Ivanovich";

//******************************************************************************

In a particular software module, any of the areas may be missing.
Variable declaration area placed from the beginning of the module text to the first Procedure or Function statement or any executable statement. This section can only contain Variable variable declaration statements.

Area for describing procedures and functions placed from the first Procedure or Function statement to any executable statement outside the body of the procedure or function description.

Main program text area is placed from the first executable statement outside the body of procedures or functions to the end of the module. This section can only contain executable statements. The main program text area is executed at the moment of module initialization. Usually, in a section of the main program, it makes sense to place operators for initializing variables with any specific values ​​that must be assigned before the first call to procedures or functions of the module.

Software modules are located in those places in the configuration that may require a description of specific operating algorithms. These algorithms should be formalized in the form of procedures or functions that will be called by the system itself in predetermined situations (for example, when opening a directory form, when pressing a button in a dialog box, when changing an object, etc.).

Each individual software module is perceived by the system as a single whole, so all procedures and functions of the software module are performed in a single context.

The module execution context is divided into client and server. In addition, some software modules can be compiled on both the client side and the server side.

Application module (managed or regular)

The application module describes the procedures (handlers) of events that are initialized at the start and end of the system. For example, when the application starts running, you can update some configuration data, and when you exit the application, you can ask whether it is worth exiting the program at all. In addition, this module intercepts events from external equipment, for example, trading or fiscal. It is worth noting that the application module is executed only when the application is launched interactively, that is, when the program window is launched. This does not happen if the application is launched in com connection mode.
In the 1C 8 platform there are two different application modules. These are the Regular Application module and the Managed Application module. They are triggered when different clients are launched. Thus, the Managed Application module is triggered when the web client, thin client and thick client are launched in managed application mode. And the regular application module is triggered when the thick client is launched in normal application mode. The application launch mode setting is specified in the "Basic launch mode" configuration property.

An application module can contain all 3 sections - declarations of variables, descriptions of procedures and functions, as well as the main text of the program. The application module is compiled on the client side, which greatly limits our use of many data types. You can extend the application module context using methods of common modules that have the “Server Call” property set. All application module variables and methods that are marked as export will be available in any configuration module running on the client side. However, as tempting as it may be, you should not place a large number of procedures and functions here. The more code there is in a given module, the longer the compilation time, and, consequently, the application launch time.

As noted above, the application module handles application startup and termination events. To handle each of these events in the application module, there are a pair of handlers Before... and When... The differences between them are as follows: when executing code in the Before... handler, the action has not yet taken place and we can refuse to execute it. This is what the Reject option is for. In the On.. handlers, the action has already taken place, and we cannot refuse to launch the application or exit it.

External connection module

• can contain all 3 areas
• located in the root section of the configuration

The purpose of the module is similar to the purpose of the application module. It processes the start and end events of the application. The external connection module is triggered when the application is launched in com connection mode. The outer join process itself is not an interactive process. In this mode, programmatic work with the information base occurs and the application window does not open, which imposes certain restrictions on the use of methods intended for interactive work. In this mode, calls to dialog forms, warnings and messages to the user, etc. cannot be used. They simply won't be executed.

As in the application module, all three areas are available here: variable declarations, descriptions of procedures and functions, as well as the main text of the program. The main difference from the application module is that in com-connection mode all work with the infobase occurs on the server side, so the external connection module is compiled on the server side. Accordingly, export variables and methods of common client modules are not available in it.

Session module

• runs on the server side
• located in the root section of the configuration

This is a highly specialized module designed exclusively for initializing session parameters. Why did you need to make your own module for this? Its use is due to the fact that the application itself can be launched in different modes (resulting in the execution of either a managed application module, a regular application module, or an external connection module), and initialization of session parameters must be done regardless of the startup mode. In order not to write the same program code in all three of these modules, we needed an additional module that runs regardless of the application launch mode.

In the session module, there is one single event “SettingSessionParameters”, which is executed very first, even before the application module event BeforeSystemStartOperation. The variable declaration section and the main program section are not available in it. You also cannot declare export methods. The module is compiled on the server side.

Common modules

• may contain an area describing procedures and functions
• executed on the server or client side (depending on the module settings)
• is located in the tree branch of the configuration objects “General” - “General modules”

Common modules are intended to describe some common algorithms that will be called from other configuration modules. The general module does not contain variable declaration areas and the main program text. You can declare export methods in it, the availability of which will be determined by the module settings (on which side it is executed: on the server or client side). Due to the fact that the variable description section is not available, global variables cannot be defined in common modules. You can use an application module for this.

The behavior of a common module depends on the parameters set (global or not, various compilation flags, whether a server call is available, etc.). Here are some tips for setting up common modules:

It is good practice not to use the Global flag everywhere. This will reduce the startup time of the application, and also improve the readability of the code (of course, if the common module has a completely meaningful name);
- It is not advisable to use more than one compilation flag. There are not so many methods that need to be executed in different contexts, and if such methods are still required, then a separate common module can be allocated for them;
- the “Call server” flag makes sense only if the module is compiled “On the server”. Therefore, all other compilation flags should be removed to avoid various problems;
- if the module methods involve massive data processing, reading and writing to the database, then to increase the speed of work it is better to disable access control by setting the “Privileged” flag. This mode is only available for shared modules compiled on the server.

Form module

• can contain all 3 areas
• executed on the server and client sides

The form module is designed to process user actions with this form (processing a button click event, changing form details, etc.). There are also events associated directly with the form itself (for example, its opening or closing). Modules of managed and regular forms differ, first of all, in that the module of a managed form is clearly divided into context. Every procedure or function must have a compilation directive. If the compilation directive is not specified, then this procedure or function is executed on the server side. In its normal form, all code is executed on the client side.

The structure of a managed form contains a section for declarations of variables, descriptions of procedures and functions, and the main text of the program (executed at the time of initialization of the form). We can access standard form events through the list of expected procedures and functions of the form (Ctrl+Alt+P), or through the properties palette of the form itself.

If a form has a main attribute assigned, then the properties and methods of the application object used as the main attribute become available in the form module.

Object module

• can contain all 3 areas
• runs on the server side

This module is available for most configuration objects and is generally intended for processing events directly related to the object. For example, events of recording and deleting objects, checking the completion of object details, posting a document, etc.

Some object module events duplicate the form module events. For example, events associated with a recording. However, it should be understood that the events of the form module will be executed exclusively in the specific form of the object, that is, when the specific form is opened. And the events of the object module will be called in any case, even at the moment of programmatic work with the object. Therefore, if you need methods associated with an object without being tied to a specific form of the object, then it is better to use the object module for this.

Object manager module

• can contain all 3 areas
• runs on the server side

The object manager module appeared only starting from version 1C 8.2. The manager module exists for all application objects and is designed to manage this object as a configuration object. The manager module allows you to expand the functionality of an object by introducing (writing) procedures and functions that relate not to a specific instance of a database object, but to the configuration object itself. The object manager module allows you to place general procedures and functions for a given object and access them from outside, for example, from processing (of course, if this procedure or function has the Export keyword). What new does this give us? In general, nothing except organizing procedures by objects and storing them in separate places - Object Manager Modules. We can just as successfully place these procedures and functions in general modules, but 1C recommends placing general procedures and functions of objects in the Object Manager Module. Examples of using the procedures and functions of the Object Managers Module: initial filling out individual details of a directory or document under certain conditions, checking the completion of details of a directory or document under certain conditions, etc.

Command module

• may contain a section describing procedures and functions
• executed on the client side

Commands are objects subordinate to application objects or the configuration as a whole. Each command has a command module in which a predefined CommandProcess() procedure can be described to execute that command.

Today we’ll look at common modules, what they are, why they are needed and how to use them. You can put functions that are used in several documents into a common module. For example, calculating the amount in the tabular part of the document.

For example, let's take our old configuration, which I used in previous articles. We have two documents in it: Arrival of Goods to the warehouse and Release of Goods to the warehouse. Both documents have procedures that calculate the amount in a tabular row.

Each document contains the same code for calculating the amount.

Procedure MaterialsPriceOnChange(Element)
TabularPart Row = Elements.Materials.CurrentData;
TabularPartLine.Amount = TabularPartLine.Quantity * TabularPartLine.Price;
End of Procedure

Today we’ll move it to a common module and call it from the document.

We create a general module for calculating the amount

And so let's start, first you need to create a common module. To do this, go to the configurator, look for the item General modules, right-click and add new ones, write the name WorkWithDocuments. We enter the following code into it.

Also be sure to check the boxes next to Client (Managed Application) and Server in the properties window.

Now you need to slightly change the code in the document form module. On the left in the configuration we look for the document Goods Arrival, expand the windows to the Forms window, double-click on Document Form and in the form window that opens, go to the Module tab at the bottom. We have this code

This procedure works when changing the Quantity in the tabular part of the Goods Receipt document and calculates the amount.

&OnClient



End of Procedure

And this procedure starts working when the Price changes in the tabular part of the Goods Receipt document and calculates the amount.

&OnClient

TabularPart Row = Elements.Materials.CurrentData;
TabularPartLine.Amount = TabularPartLine.Quantity * TabularPartLine.Price;
End of Procedure

Replace it with this one

&OnClient
Procedure MaterialsQuantityOnChange(Element)
TabularPart Row = Elements.Materials.CurrentData;

End of Procedure
&OnClient
Procedure MaterialsPriceOnChange(Element)
TabularPart Row = Elements.Materials.CurrentData;
WorkWithDocuments.CalculateSum(TabularPartRow);
End of Procedure

As you noticed, only one line changes; at first glance, it may seem that one line has been replaced by another. But don't forget that this is an example. In fact, the amount of code can be much larger if, for example, you performed calculations using a complex formula, in which case the code will be noticeably reduced.

We do the same for the document Release of goods from warehouse, run and check the functionality of the code. So you and I have made the first common module, I hope my article will be useful to someone.

The article continues the series “First steps in development on 1C”, it discusses in detail the following issues:

• What is a software module and what sections does it consist of?
• What is the application module for? Why are there two of them? When does which one start? What are the subtleties of the work?
• What events are associated with the start of system operation, how and where to process them?
• What is the external connection module for? When and how to use it?
• When is the session module used?
• What are common modules? What are its properties and operating rules? Why use the “Reuse of return values” property?
• When is the form module used and what events can be processed in it?
• What is the object module for? What sections does it consist of? How can I see the available module events?
• What are the subtleties of working with value manager modules (for constants) and recordset modules (for registers)?
• What are the differences between an object module and a manager module? When should you use the latter?

Applicability

The article discusses the 1C:Enterprise platform 8.3.4.496. The material is also relevant for current platform releases.

Modules in "1C:Enterprise 8.3"

Modules are those objects that contain program code.

There are quite a large number of types of modules in the Platform, each of which has its own purpose and features.

Any line of code must be in some module. There are general-purpose modules and object modules. Some modules can be compiled on both the Client and the Server, and some only on the Server.

A module may consist of several sections. The variable description section describes local variables of this module, which can subsequently be used in any procedure.

Within each procedure, you can access a module variable. In addition, within the procedure itself there may be another variable declaration with the same name. This will be a local variable of this procedure.

Despite the same name, these are two different variables: one is used inside a specific procedure, and the other is used outside it.

In some modules, variables may have a compilation location (availability) on the Server or Client. For example:

The section describing variables is followed by a section of procedures and functions, where local methods of this module are indicated. Some modules must specify where the procedure or function will be compiled.

In principle, the compilation directive can be omitted. In this case, the default compilation directive is Server. However, for the convenience of analyzing program code, it is recommended to explicitly indicate where a given procedure will be compiled. The order in which the procedures are described does not matter.

At the end of the module, after describing all procedures and functions, there is a section of the main program, which can contain some operators and initialize local variables of the form module. This section is executed when accessing the module.

So, for example, when opening an element form, the main program section of the form module is executed first.

It should be noted that the variable declaration section and the main program section do not exist for all modules (i.e., these sections are not valid in some modules). A section for describing procedures and functions can exist in absolutely any module.

Application module

This module is designed to handle the events of application startup and termination. For example, when you launch the application, you can download currency rates from the Internet. When terminating an application, you can confirm with the user that he or she intends to quit.

Also in the application module there are special handlers that allow you to intercept external events from the equipment.

These could be events from a magnetic card reader or fiscal registrar. And these events can also be processed in some way.

Please note that it is the interactive startup of the system that is monitored in the application module.

The application module will not work if the 1C program is launched, for example, in com connection mode. In this case, the program window is not created.

It should be noted that in Platform 8.3 there are two different application modules: the Managed Application module and the Regular Application module. Managed application module events are processed when the Managed Application Thin and Thick Client and Web Client are launched.

Module Regular application works when running the Thick Client in mode Regular application, which contains the usual command interface in the form Main menu.

If the application is running in Managed, and in mode Regular application, then it is necessary to describe the handler procedures as for the module Managed Application, and for the module Regular application.

Module Managed Application can be selected from the context menu of the root configuration node.

This module can also be opened from the properties palette of the root configuration element.

To open a module Regular application, you should refer to the configuration settings (command Options on the menu Service).

The form will open Options. On the bookmark Are common configuration editing mode must be specified Managed Application And Regular application.

In this case the module Regular application it will also be possible to open from the properties of the root node.

List of events that can be processed for Managed And Regular application is the same.

This module can contain a variable declaration section, a description section of arbitrary procedures and functions, and a main program section. But in addition to arbitrary procedures and functions, special event handlers can be located in the module.

The list of available handlers can be viewed by calling the list of procedures and functions of the current module when the module is open.

The Procedures and Functions window that opens displays all the procedures and functions of this module, as well as events for which handlers have not yet been created.

There are two events associated with the start of the system (“before” and “at”). Two events associated with system shutdown (“before” and “at”). And also processing of external events (for example, events of commercial equipment).

When a "before" event handler is executed, the action is considered to have not yet taken place. When the “at” event handler is executed, the action has already been completed.

Event Before Starting the System occurs at the moment when Enterprise 8.3 is launched, but the application itself has not yet appeared on the screen. This event has the following parameter: Refusal.

If this parameter takes the value True, then the application will not start. Event When Starting the System assumes that the action has already been completed, the window has already been created, and in this case we can, for example, display some special form. It is no longer possible to refuse the launch.

Similarly, before shutting down the system, the application is still open and you can refuse to close it. When the system shuts down, the application window has already closed. It is only possible to perform additional actions, for example, deleting some files or sending an email.

In the module Managed Application Directives for compiling procedures and functions are not specified, since the module is entirely compiled on the Client side. This means that in the procedures and functions of the module we will not be able to directly access, for example, reference books.

If from module Managed Application need to make a Server call, then for this you will need to create special with a flag .

In the module Regular application There are no such restrictions, since this module will be compiled when loading the Thick Client. Almost all types of data are available in the Thick Client.

Procedures, functions and variables of an application module can be described as exports.

Since the module is compiled entirely on the Client, this means that in client procedures we can access this method and this property.

For example, you can call a procedure or function of an application module from the form module of an object. However, it is recommended to use Common Modules to describe general algorithms. The main purpose of the application module is to process the start point and end point.

By analogy with an application module, this module is designed to process the program opening event and the shutdown event.

Unlike the application module, which is initiated at the moment of interactive launch of the application, the external connection module operates in COM connection mode, i.e. when a 1C:Enterprise 8 object is created and connected to a specific database.

This module has events: When Starting the System And Upon System Shutdown.

The external connection module can be opened using either the context menu at the root configuration object level, or the properties palette for the root node.

The process of external connection itself is a process of programmatic work with the information base, and not interactive. Accordingly, at this moment you cannot use dialog forms or display warning messages, since there is no user interface.

In the External Connection Module it is possible to describe export variables and export methods that will be available on the side where the external call to 1C:Enterprise 8.3 occurs.

Since there is no user interface in an outer join, the Outer Join Module is compiled entirely on the Server.

Session module

This module is needed to initialize session parameters. Session parameters are quick global variables whose values ​​are available anywhere in the configuration.

You can open the Session Module either through the context menu or through the properties palette of the root node.

The Session Module provides an event SettingSessionParameters.

When the application starts, this procedure is called first. Session parameters are needed for any application operation: both when launched interactively and when launched in external connection mode.

The Session Module describes various actions to initialize session parameters depending on different conditions.

This module, as a rule, describes several procedures that are called from the procedure SettingSessionParameters. Therefore, all these procedures are separated into a separate module.

The session module always runs in privileged mode. This means that no permissions check will be performed when accessing the database. The session module is compiled on the Server, i.e. It is possible to access any server methods (including reading values ​​from the database).

In the Session Module it is possible to define only procedures and functions, i.e. there is no variable description section and no main program section. You cannot define export methods in a Session Module.

If, when starting the system, it is necessary to perform some actions on the Server, for example, create an element of a directory, then, as an option, it is possible to use the Session Module, because it is compiled on the Server and is always reliably executed at system startup. However, the following points must be taken into account:

• procedure SettingSessionParameters is executed not only at system startup, but also when accessing uninitialized session parameters. Those. the SetSessionParameters handler can be called repeatedly during application operation;
• if the number of elements in the session parameters array is zero (the array of required parameters has a data type of Undefined), then this is the moment the application is launched;
• since the Session Module operates in privileged mode and there will be no checking of access rights, you should work very carefully with database objects, since the user can gain access to data that should not be provided to him;
• When the system starts, it is not yet known for certain whether the application will be launched. In this case, unnecessary actions may be performed in the SetSessionParameters event handler.

These modules represent a description of some general algorithms, i.e. procedures and functions that can be called from various places.

Logically related methods can be grouped into different Common Modules. These modules are created inside the General branch.

You can add any number of shared modules. To make Common Module methods available elsewhere in the configuration, they must be defined with the Export keyword. Client procedures of common modules will be available on the Client, and server ones – on the Server.

In General Modules, only the section describing procedures and functions is available. Those. in the General Module you cannot describe variables and you cannot describe a section of the main program.

If a global variable is needed, you can use either session parameters or application module export variables.

For General modules, you can set some parameters that will affect the behavior of this module. If the Global property is set for a General module, then the export methods declared in this module will be accessible from outside directly, without any additional instructions.

Those. the General module will participate in the formation of the global configuration context.

Property Global for general modules it may be useful. However, you should not use it everywhere for all common modules.

Those , which are marked with the sign Global, will be compiled at system startup. The more such modules, the slower the program will start.

If the flag Global For General module is not specified, then compilation of this module will be performed at the time of the first call to it (i.e. after the system starts).

In addition, the use of global common modules affects the understanding of the code. Methods of a non-global common module are called through the name General module and the method name, for example:
Cost Calculation Module.DistributeIndirectCosts();

In this case, the names of Common Modules must reflect the content of the procedures described in them. Specifying the name of the Common Module when calling a procedure helps to better understand the code.

For General module V Properties palette you can set the property Privileged.

The privileged module does not control access rights. This is necessary if General module It is required to perform mass data processing, obtaining data from the database.

Controlling access rights increases the time it takes to access a database, and mass algorithms often need to work as quickly as possible.

For example, payroll is a resource-intensive operation. It needs to be done as quickly as possible. To do this, algorithms that calculate wages are placed in privileged .

At the same time, all procedures that ensure the completion of payroll documents are outside these Common modules. It is in these procedures that access rights control is performed.

In this way, significant performance improvements can be achieved. This is especially true when using a mechanism for row-by-row access control to table records.

If a Common Module is privileged, then the procedures of this module can only be compiled on the Server.

There are situations when some object should be inaccessible to the user, for example, a certain directory. But when carrying out any one document, reference to this reference book is necessary.

Those. There is a need to temporarily expand user rights and then return them to their original state. This effect can be obtained by using privileged Common modules.

To do this in a privileged General module You should create a procedure that accesses the required data.

This procedure will be called from the corresponding document. Those. the user is actually granted extended rights at the time this procedure is called.

For Common modules It is possible to specify the compilation location. The flags are used to determine whether the Common Module will be available on the Client (managed application), on the Server, or in External Connection mode.

In addition, if you switch the configuration editing mode to Managed application and regular application, then another compilation context will be possible - Client (regular application).

Thus, there are four options for the functioning of the program. Depending on the running application, depending on the work on the Client or on the Server, certain Common Modules will be available or unavailable.

In addition to the ability to specify compilation flags, it is possible to specify compilation directives for procedures and functions located in the Common Module.

If a compilation directive is specified for a method, then although the Common Module is available in all specified contexts, the availability of the specific method will be limited by the compilation directive.

In this case, the procedure cannot be accessed in a context that is not accessible to the entire module.

If you do not specify a compilation directive for a procedure (function), it will be compiled in all contexts defined for the module.

Those. Essentially, multiple copies of the procedure will be made. The choice of a particular compiled instance depends on where the procedure is called (by the closest call rule). It should be taken into account that the code of such a procedure must be written taking into account its availability in all contexts defined for the module.

Generic modules that are simultaneously accessible in several different contexts are primarily designed to create procedures that are accessible in multiple contexts.

When creating a General Module, it is considered good practice not to specify compilation directives. Those. The availability of procedures and functions should be determined by the properties of the module itself.

With this approach, client procedures will be located in separate Common Modules, and server procedures will be located in separate Common Modules.

Modules that have several compilation flags set are used extremely rarely in practice. These are some common actions available on both Client and Server. Usually these are some simple calculations.

Important! It is possible for the Client to access the export server methods of a Common Module, but only if this Common Module is compiled only on the Server. In this case, a special flag is provided to provide access from the Client .

For non-global Common modules, it is possible to cache the values ​​returned by functions. Those. After the first call of a function, the system can remember the result of its execution. If this function is called again with the same parameters, the system will return the value from the cache.

The purpose of this mechanism is to speed up repeat calls. To configure this behavior you need to Properties palette module, set the appropriate value for the Reuse of return values ​​property.

By default, this property is set to Do Not Use. Other possible values: cache During the call, or For the duration of the session.

This property makes sense to use only for those functions whose results depend solely on the input parameters. This mechanism is available only for non-global Common Modules.

If the value of the corresponding parameter For the duration of the call is selected, the cache will operate as long as the procedure from which the General Module method was called is running. If the For the duration of the session value is selected, then it is conditionally assumed that the cache will operate while the user is working.

However, there are certain time restrictions. The cache is cleared automatically 20 minutes after the value enters the cache.

Form module

This module is designed to process user actions. For example, describe the algorithm for how a program reacts when a button is pressed. Or, for example, at the moment of entering a value in a field, immediately check for correctness.

In addition to events associated with form controls (buttons, input fields), there are events associated directly with the form itself.

For example, you can handle the form's opening event and perform some initial initialization. You can also handle the form closing event and check whether the user entered everything correctly.

There are controlled forms and regular forms. The modules of these forms differ primarily in that the managed form module is clearly divided into context. Each procedure (function) must have a compilation directive. In normal form, all code is used on the Client.

In a managed form module, you can declare procedures and functions, you can declare variables, and you can describe a section of the main program.

The program code of the main program will be executed at the time of initialization of the form, i.e. when the user starts to open it. The figure shows a list of standard events for a managed form.

The list of events of a managed form is also visible in the list of properties directly for the form itself. This list is called in the managed forms editor.

In a managed form, you can handle the item's write event. This event is present only for object forms (directories, documents and some others). If the form is not bound to a specific object, then there is no write event.

For a module of a regular form, the list of standard events is somewhat smaller, because In a managed form, many events are made to be paired (one is executed on the Client and the other on the Server). In its normal form, all code is executed on the Client.

Object module

These modules are typical for directories, documents, plans for types of calculations, charts of accounts and many other objects. The object module is designed to handle standard events. For example, an event for entering a directory element, an event for writing an element, deleting, posting a document, etc.

In principle, the write event also exists in the Form Module. But the write event in the Form Module occurs during the interactive recording process, when working with a specific form.

The write event in the Object Module will be executed on any write from any form of the given object. Additionally, if the object is written programmatically, the object's module event will fire.

In the write event of the Object Module, you can build in all checks for the correctness of the data being written, since this procedure will be executed at the time of absolutely any recording.

The module of this object can be called through the context menu, from the Object Properties Palette and from the object editing window.

The figure below shows a list of available directory module events.

In the Object Module you can place a section for describing variables, describing arbitrary functions that may not be associated with an event, as well as a section of the main program.

In the main program section, you can, for example, initialize local variables of a given module. This program code will be executed when this object Module is accessed.

It should be noted that all procedures of the Object Module are compiled on the Server. Accordingly, compilation directives for procedures and functions of the Object Module are not required. Some configuration objects do not have Object Modules.

This is due to the characteristics of the objects themselves. Such objects include Constants And Registers. For Constant there is no object module, but there is a very similar module called Value manager module.

IN Value manager module you can handle write events Constants and filling verification processing.

The entire module context is executed on the Server.

For registers there is a Recordset Module.

This module also has the ability to handle write events and perform occupancy checks.

In Object Modules, Value Manager Modules (for constants) and Recordset Modules (for registers) you can describe methods that can be made exportable, and these methods will be accessible from the outside.

Those. In addition to using the fixed methods of an object class, you can create additional methods for an object in the Object Module. This module should describe the corresponding procedure with the keyword Export.

Then it will be possible to access this procedure from outside. Moreover, this method will be displayed in the context tooltip. New methods in the context tooltip are highlighted in blue font (blue icon p() for procedures and f() for functions).

Similarly, you can create a new property by declaring a variable with the keyword Export. This property can also be accessed from outside.

In this way, it is possible to expand the functionality of objects (to define new methods and new properties). However, the properties are dynamic and are not saved in the database.

If you need to use a property for an object that will be stored in the database, you should create an object attribute.

Manager module

This module exists for many objects (directories, documents, registers, etc.). The module is opened either through the context menu for the object or through Properties palette, or through the editing window.

In the Manager Module you can override some standard events. For example, in ProcessingReceivingSelectionData, when an element is selected from the directory, some additional filtering or checking can be done.

In addition, you can create additional methods in the Manager Module and indicate that they are export methods. In this case, it is possible to access these methods from outside.

In order to perform this call, it is necessary to obtain the data type DirectoryManager.

The difference between the export methods of the Manager Module and the Object Module is that to access the method of the Object Module, you first need to obtain the object itself (that is, somehow obtain a link and then convert this link into an object).

After this, export variables and methods of the Object Module will be available. For the Manager Module the call is simpler, for example:
Directories.Counterparties.MethodName

These are two different appeals. Convert from reference to object (method GetObject) is a fairly serious action for the system, since when receiving an object, absolutely all the data of this object is read, which can be quite lengthy.

The second difference is that Object Module called in the context of a specific element. Accordingly, we can assume that it is applicable for a given element (in most cases, this is exactly the logic used).

As for the Manager Module, it describes some common action for a group or for all elements of a directory or some document. For example, if you need to print a directory item, you can use the Object Module.

But in the Manager Module it is possible to create a more universal mechanism that will print, among other things, a group of elements.

In addition, accessing the object Module is still a longer action. Therefore, it is more preferable to solve this problem in the manager module.

This concludes our acquaintance with the modules in the 1C:Enterprise system configuration. If we briefly summarize all of the above, the bottom line is the following conclusions:

• A software module is a part of the configuration that can only contain text in the built-in 1C language
• Software modules are classified according to the types we discussed in this article. Each view is determined by its placement and available program context.
• The structure of the module consists of several sections, which are arranged in a certain sequence. The composition of sections is determined by the type of module.

Also note that we deliberately omitted one type of module, namely the command module. It is nothing remarkable, and we invite you to familiarize yourself with its functionality.

So far, we have considered all of our program code separately from the application solution, and, as a rule, we wrote it in some small test configuration of our own. Are you aware that “you can’t just go” and start editing the code of a standard configuration? No? Then in the next article we will explain it all!

What are modules and what exactly are they intended for? The module contains the program code. Moreover, it is worth noting that, unlike the 7.7 platform, where the code could be located in the properties of form elements and in the cells of the layout tables, in the 8.x platform any line of code must be located in some module. Typically, a module consists of three sections - a section for describing variables, a section for describing procedures and functions, and a section for the main program. This structure is typical for almost all platform modules, with some exceptions. Some modules do not have a variable description section or a main program section. For example, Session Module and any General Module.

The execution context of modules is generally divided into client and server. In addition, some modules can be compiled both on the client side and on the server side. And some are exclusively on the server side or client side. So:

Application module

The module is designed to catch the moments of application launch (configuration loading) and termination of its operation. And verification procedures can be placed in the corresponding events. For example, when starting an application, update some reference configuration data, and when finishing work, ask whether it’s worth leaving it at all, maybe the working day is not over yet. In addition, it intercepts events from external equipment, for example, trading or fiscal. It is worth noting that the application module intercepts the described events only when launched interactively. Those. when the program window itself is created. This does not happen if the application is launched in com connection mode.

There are two different application modules in the 8.2 platform. These are the Regular Application module and the Managed Application module. They are triggered when different clients are launched. This is how the managed application module is triggered when the web client, thin client, and thick client are launched in managed application mode. And the regular application module is triggered when the thick client is launched in normal application mode.

An application module can contain all sections - descriptions of variables, procedures and functions, as well as descriptions of the main program. The application module is compiled on the client side, so this greatly limits us in the availability of many types of data. You can extend the application module context using methods of common modules that have the “Server Call” property set. All variables and methods that are marked as export will be available in any configuration module running on the client side. However, as tempting as it may be, you should not post a large number of methods here. The more code it contains, the longer the compilation time, and therefore the application launch time, which is very annoying for users.

As noted above, the application module handles application startup and termination events. To handle each of these events in the application module, there are a pair of handlers Before... and When... The differences between them are such that when executing the code in the Before... handler, the action has not yet taken place and we can refuse to execute it. This is what the Reject option is for. In the On.. handlers, the action has already taken place, and we cannot refuse to launch the application or exit it.

External connection module

The purpose of the module is similar to the purpose of the application module. It processes the start and end points of the application. The external connection module is triggered when the application is launched in com connection mode. The outer join process itself is a non-interactive process. In this mode, programmatic work with the information base occurs and the application window does not open, which imposes certain restrictions on the use of methods intended for interactive work. In this mode, calls to dialog forms, warning messages, etc. cannot be used. They just won't work.

As in the application module, sections for describing variables, methods, and a section for the main program are available here. You can also declare export variables and methods. The difference is that in com connection mode all work with the infobase occurs on the server side, so the external connection module is compiled exclusively on the server. Accordingly, export variables and methods of common client modules are not available in it.

Session module

This is a highly specialized module and is intended solely for initializing session parameters. Why did you need to make your own module for this? This is due to the fact that the initialization process may require the execution of some code, and in addition, the application may be launched under different clients (which leads to the execution of different application modules or an external connection module), and initialization of session parameters must be done in any launch mode. Therefore, an additional module was required that runs in any application launch mode.

In the session module, there is a single event “SettingSessionParameters”, which is executed very first, even before the application module event BeforeSystemStartOperation. The variable declaration section and the main program section are not available in it. You also cannot declare export methods. The module is compiled on the server side.

You should not be tempted by the fact that this module is executed whenever the application is launched, and you should not place code in it that is not directly related to the initialization of session parameters. This is due to the fact that the SetSessionParameters handler can be called repeatedly during system operation. For example, this happens in cases where we access uninitialized parameters. And although it is possible to catch the moment of the first launch of this event (RequiredParameters is of type Undefined), it should be taken into account that this module is compiled in privileged mode, i.e. it does not control access rights. And the second point is that we still cannot be one hundred percent sure that the system will be launched. Suddenly, a failure occurs in the application module, and we are trying to perform some actions with the database.

Common modules

Modules are intended to describe some common algorithms that will be called from other configuration modules. The general module does not contain a variable description section and a main program section. You can declare export methods in it, the accessibility context of which will be determined by compilation flags. Due to the fact that the variable description section is not available, global variables cannot be defined in common modules. To do this, you need to use the functions of common modules with caching of return values ​​or an application module. It is worth keeping in mind that even if the shared module reuse property is set to “For the duration of the session”, then in this case the lifetime of cached values ​​does not exceed 20 minutes from the moment of the last access to them.
The behavior of a common module depends on the parameters set (global or not, various compilation flags, whether a server call is available, etc.). In this article we will not consider all kinds of settings, as well as behavioral features and pitfalls that arise when setting property flags unreasonably. This is a topic for a separate article. Let us dwell on just a few points that should be followed when setting flags:

• A good rule of thumb is to not use the Global flag everywhere. This will reduce the startup time of the application, and also improve the readability of the code (of course, if the common module has a completely meaningful name).
• It is not advisable to use more than one compilation flag. There are not many methods that need to be executed in different contexts, and if such methods are still required, then a separate common module can be allocated for them.
• The "Server Call" flag only makes sense if the module is compiled "On the server". Therefore, all other compilation flags should be removed to avoid various problems.
• If module methods involve massive data processing, reading and writing to the database, then to increase the speed of work it is better to disable access rights control by setting the “Privileged” flag. This mode is only available for shared modules compiled on the server.

Form module

It is designed to process user actions, i.e. various events related to data entry and processing the correctness of their entry. A module of the usual form is compiled entirely on the client. A managed form module is clearly demarcated by execution context, so all variables and methods must have a compilation directive. If the directive is not explicitly specified, then this variable or method will be compiled on the server side. The form module contains sections for descriptions of variables and methods, as well as a section for the main program.

Object module

This module is typical for many configuration objects and is generally intended for processing object events. For example, events for recording and deleting objects, events for posting documents, etc.

Some object module events duplicate the form module events. For example, events associated with a recording. However, understand that form module events will be executed exclusively on the object's specific form. In general, there may be several of these forms. And the events of the object module will be called in any case, even at the moment of programmatic work with the object. Therefore, if you need to execute some code in all cases, then it is better to use an object module event for this.

The object module is compiled exclusively on the server. In it you can define export variables and methods that will be available in other configuration modules. Using these properties and methods, we can significantly expand the functionality of the object.

Object manager module

This module exists for many configuration objects. The main purpose of this module is to redefine the standard selection event that occurs when entering a line and to expand the functionality of the manager. The module is compiled on the server side. It allows you to define export properties and methods. Calling the manager's export methods does not require creating the object itself.

To all of the above, you can add a picture of some configuration modules and ways of mutually calling methods in managed application mode. The arrow indicates the direction in which you can turn to call the corresponding method. As can be seen from the diagram, the server context is completely closed. But from the client context it is possible to access server methods.

Symbols on the diagram: O.M. Client - Client common module; O.M. Server - Server shared module; M.F. Client - Client procedures of the form module; M.F. Server - Server procedures of the form module.

Any program consists of program code, that is, actually a sequence of actions written in any language that must be performed.

However, this very program must be written somewhere, that is, located somewhere. In most cases, program code is written in plain text files. The only difference is that the extension in them is not .txt, but .cpp or .php.

Where is the 1C program written?

What is Module 1C?

Of course, the 1C code could also be written in some text file. However, there is the concept of 1C Configuration - which includes not only a list of settings, form templates, etc., but also 1C program code. Therefore, the 1C code is stored in the configuration.

The configuration consists of 1C objects, as we have already discussed in previous lessons. Each 1C object contains nested objects, for example, a directory has several forms.

Each 1C object, including some nested ones, has its own Module - a text file that contains program code.

There are also object-independent modules in which program code can be written that is independent of a specific object.

Thus, in 1C there is no “single” program. There is a set of modules for writing program code for each 1C configuration object.

How are 1C Modules used?

The entire program can be roughly divided into two types:

• Object method
• Reaction to events.

Methods. As we said earlier, a 1C object is an integral structure that includes both data and methods for processing it. These methods are a set of actions (methods) that can be called to process data. An example of such an action is DirectoryObject.Write() – writes a directory element to the database.

The methods of many 1C objects can be standard (i.e. programmed in the 1C platform) and written by a programmer in the 1C language. With the help of the second, you can expand the functionality of 1C objects as you wish.

Events. Events are available in many other development tools. The purpose of the program is not only to calculate something at startup, but also to support the user's work.

User event - the user pressed a button. In response, some part of the code will be executed, reacting to user actions.

System events - we recorded the 1C object in the database. The system event “Write object” occurred. It is possible to configure a reaction that will occur to events caused not by the user (who pressed a button or did something else), but by the system itself. A striking example of such an event is when the program starts.

The order of execution of 1C modules

Many languages ​​have such a concept as an “entry point”. This is the very first line or function that will be executed when the program starts.

In 1C there are several such entry points - for each type of client. That is, when starting a thick client, there is one entry point, when starting a thin client, another. This allows you to program features that are different for different types of clients.

The entry point in the corresponding module is the system event handlers BeforeSystemStart() and WhenSystemStart(), respectively (i.e. in order). These functions are executed first, they can start something automatically.

If nothing was launched automatically, then the 1C interface opens in front of the user and then everything depends on it. He presses a button – the button click handler is executed (which in turn can also launch something automatically).

Working with 1C modules

Produced in the configurator. You can open the module using the Configuration window.