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, program work occurs with information base and the application window does not open, which imposes certain restrictions on the use of methods designed 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 certain text file, which 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 vary depending on the different types 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.

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 structure software module:

//***************** 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 the function is executed on the server side. IN regular 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 common procedures and functions for a given object and access them from outside, for example, from processing (of course, if this procedure or function will be with keyword Export). 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.

Hello.
In this post we will look at the application module, its purpose and place of compilation.

1C application module is intended mainly to catch the moment the application is launched and the moment it shuts down.
There are also handlers here that allow you to intercept an external event from the equipment.

Managed application module events fire when the Thin Client, Web Client, and Thick Client of a managed application are launched.
The managed application module monitors interactive system startup.

The managed application module contains:
variable declaration section
procedure and function description section
main program section
Procedures, functions and variables of a managed module can be described as export (accessible outside the given module). This module may also contain special event handlers that occur under certain circumstances.

Let's look at the list of handlers that can be called by pressing ( Ctrl+Alt+P).
Before the System Starts - the action has not yet occurred (1C Enterprise 8.2 is being launched, but the application itself has not yet appeared on the screen). If the “Failure” parameter is set to “True”, then the application simply will not start. When the System Starts - the action has already been completed (there is no “failure” parameter). Before the System Shutdown - the application has not disappeared yet (there is a “failure” parameter).
At System Shutdown, the interactive window has already closed.

Take a look at the syntax assistant and read more about managed and regular application events.

The application module is always compiled entirely on the client side. Those. from it we can access server procedures and functions of common modules and will not be able to access configuration objects such as documents, directories.
When the system starts, the managed application module is compiled and the more export procedures and functions are declared in it, the longer the system startup will take.

Regular Application Module

The regular application module can be seen in the same place as the managed application module, but if it is not visible, then in the configurator parameters on the “General” tab, select the “Edit configuration for launch modes” option to the “Managed application and normal application” position.
How to do this, see the article:.

Regular application module events fire when the regular application's thick client is launched.
Everything that was said for the managed application module is also true for the regular application module.

Events Before... and During....

The difference between the procedures Before Starting the System Operation (Failure) and When Starting the System Operation ()

Before the System Starts Operation (Refusal) - the action has not yet been completed and we can refuse to perform it.
AtSystemStart() - the action has already been completed, and we cannot refuse to launch the application or exit it.

That's all, thank you for your attention.

Please leave comments, your opinion is important to me.

Guard: Registration of medical certificates in 10 minutes. To get a certificate from the State Traffic Safety Inspectorate you need to spend a couple of days, but there is an option to buy a certificate for a license. It is possible to deliver a certificate and also include a copy of the licenses

P.S. And I like Jamala – You’re Made of Love

1.1. Common modules are created to implement procedures and functions united according to some characteristic. As a rule, procedures and functions of one configuration subsystem (sales, purchasing) or procedures and functions of similar functionality (working with strings, general purpose) are placed in one common module.

1.2. When developing shared modules, you should choose one of four code execution contexts:

	Common module type	Example of a name	Server call	Server	Outer join	Client (regular application)	Client (managed application)
1.	Server	General Purpose (or General Purpose Server)
2.	Server to call from client	GeneralPurposeCallServer
3.	Client	General Purpose Client (or General Purpose Global)
4.	Client-server	General PurposeClientServer

2.1. Server common modules are intended to host server procedures and functions that are not available for use from client code. They implement all the internal server business logic of the application.
For correct operation configurations in external connection, managed and regular application modes, server procedures and functions should be placed in common modules with the following characteristics:

• Server(checkbox Server call reset),
• Client (regular application),
• Outer join.

In this case, the ability to call server procedures and functions with parameters of mutable types is guaranteed (for example, DirectoryObject, DocumentObject and so on.). Typically this is:

• handlers for subscriptions to events of documents, directories, etc., which take a mutable value (object) as a parameter.
• server procedures and functions, to which an object is passed as a parameter from modules of directories, documents, etc., as well as from modules with event subscriptions.

Server-side shared modules are named according to general rules for naming metadata objects.
For example: Working With Files, General Purpose

In some cases, a postfix can be added to prevent name conflicts with global context properties "Server".
For example: RoutineTasksServer, Data ExchangeServer.

2.2. Server common modules for calling from client contain server procedures and functions that can be used from client code. They constitute the client programming interface of the application server.
Such procedures and functions are placed in common modules with the following feature:

• Server(checkbox Server call installed)

Server-side common modules for calling from a client are named according to the general rules for naming metadata objects and must be named with a postfix "CallServer".
For example: Working With FilesCalling Server

Please note that export procedures and functions in such shared modules must not contain parameters of mutable types ( DirectoryObject, DocumentObject etc.), since their transfer from (or to) client code is impossible.

See also:Restriction on setting the “Server Call” flag for common modules

2.3. Client Common Modules contain client business logic (functionality defined only for the client) and have the following characteristics:

• Client (managed application))
• Client (regular application)

The exception is when client procedures and functions must be available only in managed application mode (only in regular application mode or only in external connection mode). In such cases, another combination of these two characteristics is acceptable.

Client common modules are named with a postfix "Client".
For example: Working With FilesClient, General PurposeClient

See also: minimizing code running on the client

2.4. In some cases, it is permissible to create client-server common modules with procedures and functions, the content of which is the same on both the server and the client. Such procedures and functions are placed in common modules with the following characteristics:

• Client (managed application)
• Server(checkbox Server call reset)
• Client (regular application)
• Outer join

Common modules of this type are named with the postfix "ClientServer".
For example: Working With FilesClient, General PurposeClientServer

In general, it is not recommended to define common modules for both the server and the client (managed application). It is recommended to implement functionality defined for the client and for the server in different common modules - see paragraphs. 2.1 and 2.3. This explicit separation of client and server business logic is dictated by considerations of increasing the modularity of the application solution, simplifying developer control over client-server interaction and reducing the risk of errors due to fundamental differences in the requirements for the development of client and server code (the need to minimize code executed on the client , different availability of objects and types of platforms, etc.). In this case, you need to keep in mind the inevitable increase in the number of common modules in the configuration.

A special case of mixed client-server modules are form and command modules, which are specifically designed to implement server and client business logic in one module.

3.1. It is recommended that names of common modules follow the general rules for naming metadata objects. The name of the general module must match the name of the subsystem or separate mechanism, the procedures and functions of which it implements. It is recommended to avoid such general words as “Procedures”, “Functions”, “Handlers”, “Module”, “Functionality”, etc. in the names of common modules. and use them only in exceptional cases when they more fully reveal the purpose of the module.

In order to distinguish between common modules of one subsystem, which are created to implement procedures and functions performed in different contexts, it is recommended to give them the postfixes described earlier in paragraphs. 2.1-2.4.

Start