In the 1C:Enterprise platform, there is such a thing as a “Program module". In short, a module is a 1C object that contains the application code. But in 1C there are several types of these modules. So how do they differ from each other? And in which module should the developer place his code? Below I will try to answer these questions.
In general, all 1C source code is stored in modules. There are several types of modules, they differ in their properties. But before proceeding to consider their properties and differences, I will first briefly tell you in general what the concept of "Program module" in 1C is.
So, there is the concept of a general-purpose module or an object module. In the first case, the module exists on its own and is not associated with any other object. In fact, it is a separate object of the system. A module of this kind usually contains general-purpose source code, some frequently used procedures, and functions. If we are talking about an object module, then we mean a Catalog module, for example, or a Document module. Such a module usually contains the code that is associated with this particular Catalog or this Document.
Some modules can be compiled on the server (and the process of executing this code happens on the server), some on the client, and some modules on both the server and the client.
Naturally, in each module, you can declare module variables that will be available to any procedure of this module. In some modules, variables can be specified with the compilation location (availability) on the server or on the client. For example:
This is followed by a section of procedures and functions, which specifies the local methods of this module. In some modules, you must specify where the procedure or function will be compiled - on the server or on the client.
In principle, the compilation directive can be omitted. In this case, the default compilation directive is the server. Nevertheless, for the convenience of analyzing the program code, it is recommended to explicitly indicate where this procedure will be compiled. The order in which the procedures are described is irrelevant.
At the end of the module, after the description of all procedures and functions, there is a section of the main program, where some operators may be contained, local variables of the form module are initialized. This section is executed when accessing a module.
So, for example, when we open 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 allowed in some modules). A section describing procedures and functions can be present in absolutely any module.
Well, in general terms I described, let's go to see in more detail! So, in total there are seven types of program modules in 1C:
The application module can be opened as follows:
This module is designed to handle application launch and shutdown events. For example, a developer can initialize equipment in this module if it is used in work, for example, a cash register or electronic scales. And at the end of the application, you can make sure that the user intends to finish the work. The screenshot below is a list of events that a developer can intercept and process in this module:
As you can see, for some events, handlers have already been created, and for some, not yet.
Also, notice the "ExternEventProcessing" event. This event is raised when an external application sends a message in a custom format. Traditionally, 1C uses this event to integrate with various retail equipment. On the screen below you can see an example of data processing from a barcode scanner:
The application module does not need to specify compilation directives for procedures and functions, since the module is fully compiled on the client-side. This means that in the procedures and functions of the module, we will not be able to directly refer to, for example, Catalogs.
If we still want to make a server call from the application module, then for this we need to create special Common modules with the Call Server flag set. We'll talk about this below.
Procedures, functions, and variables of the application module can be described as exported. To do this, use the Export keyword:
Since the application module is executed on the client, such variables and procedures will be available in all client procedures of our application.
For example, from a form module of a document, you can call a procedure or function of an application module. However, it is recommended to use Common Modules to describe common algorithms. The main purpose of the application module is to handle the start and end of our application.
This module is needed in order to initialize session parameters. Session parameters are fast global variables whose values are available anywhere in the configuration. We can open the module like this:
This module has only one event “SessionParametersSetting” that we can handle.
The Session Module describes various steps to initialize session parameters based on different conditions. For example, we can set the session parameter "CurrentUser" and refer to this parameter during the program operation:
A very important nuance - the session module is always executed in privileged mode. This means that no checking of access rights is performed when accessing the database. The session module is compiled on the server, so any server-side methods can be called. And export methods cannot be described in the session module.
By analogy with the application module, this module is designed to handle the event of opening the program and the event of shutting down.
Unlike the application module, which is initiated at the moment of interactive launch of the application, the external connection module operates in the COM connection mode, i.e. when the 1C: Enterprise object is created 8.
Since the connection to 1C via a COM connection is quite slow and it only works on Windows, there is probably no need to describe the operation of this module in more detail now. Currently, it remains in the 1C platform, rather than for compatibility with old applications.
Most importantly, there can be many of these modules. The developer can add as many of them as needed to solve his problems.
In general, these modules are intended to store source code (procedures and functions) and this code is available from various places in our application. For methods of common modules to be available elsewhere in the application, they must be defined with the Export keyword. Client procedures of common modules will be available on the client, and server procedures on the server.
There can be several common modules that are logically related to each other, for example, they perform some common tasks. In the screenshot below, several different common modules store the program code that is used to work with currency rates:
In common modules, the developer can only describe procedures and functions. That is, variables cannot be described in a common module. If the developer needs a global variable, then you can use either the session parameters or the export variables of the application module (which we discussed above).
For common modules, we can set some parameters that will affect the behavior of this module.
For example, if the Global property is set for a common module, then the export methods declared in this module will be accessible from outside directly, without any additional instructions.
For example, a call to an export procedure located in such a module might look like this:
That is, if the module is global, then its methods can be accessed without specifying the name of the module itself.
If we disable the Global flag for the module, then we can refer to the export procedure as follows:
It might seem like it's best to use the Global flag for all modules in your application, but avoid it if possible.
There are several reasons for this. First, the more global modules there are, the slower the system will start since global modules are compiled at system startup, but ordinary ones only when they are accessed. Secondly, procedures with the same name can be used in different modules, but if these modules are global, this will lead to conflicts and errors in the system operation.
The next very important property for a common module is Privileged:
If this flag is set for a common module, then all procedures that will be performed in this module will be performed without access control.
What is it for? There are complex algorithms that process large amounts of data, for example, this is very common in industrial accounting. And the enabled control of rights slightly slows down the work of such algorithms. Using the "Privileged" flag allows you to speed up the work of such an algorithm.
Or, for example, in the process of work, it is necessary to give the user more complete rights in order to read data that is usually inaccessible to him. In this case, you can also use the procedure placed in the general privileged module.
Finally, I may notice that if a shared module is privileged, then the procedures of that module can only be executed on the server.
In general, for common modules, it is possible to specify the compilation location. With the help of flags, we can set where the module will be compiled: either on the client or on the server, and it is also possible, if both flags are set, that the common module will be compiled on both the server and the client:
Modules that have several compilation flags set at the same time are rarely used in practice. These are some common actions available on both the client and server. Usually, these are some kind of simple calculations.
It is also possible to compile a common module to work with an external connection:
It is possible for the client to access the export methods of a common module, but only if this common module is compiled only on the server. In this case, to ensure access from the client, a special flag "Call Server" is intended:
For non-global common modules, it is possible to cache the values returned by functions. That is, after the first call of the function, the system can remember the result of its execution and, at the next call of the function, return the result without calculation. If this function is called again with the same parameters, the system will return the result from the cache.
The purpose of this mechanism is to speed up repeated calls and generally speed up the application. To enable this option, common modules have the "Reuse return values" flag:
By default, this property is set to “Do not use”. Other possible values: cache "During call" or "During session":
If the value of the corresponding parameter "During call" is selected, the cache will remain in effect as long as the procedure from which the call to the method of the common module was made is running. If the value "During session" is selected, then it is conventionally assumed that the cache will be active while the user is working.
However, there are certain time limits. The cache is cleared automatically 20 minutes after the value has entered the cache.
This module is designed to handle user actions. For example, we can describe in this module a button click handler. Or, for example, at the moment of entering a value in a field, immediately perform a validation check.
In addition to events related to form controls (buttons, input fields), there are events related directly to the form itself.
Below is the screenshot is a list of events that can be generated by the document form:
For example, we can handle the form open event and do some initial initialization. We can also handle the form close event and check if the user entered everything correctly.
Important note! In a form module, procedures and functions can be executed both on the server and on the client. The developer himself decides where the code will be executed using compilation directives. If a procedure in a form module is declared without a directive, then by default it will be compiled (and executed) on the server:
Important note! In a form module, a developer can handle the item write event:
This event is only present for forms associated with objects (eg catalog form, document form). If the form is not tied to a specific object, then there is no event “OnWrite”.
It’s very important to understand here that the "OnWrite" event occurs precisely when the form is being recorded interactively. Therefore, in the form, it’s most expedient to check the correctness of data input from the user and to carry out global processing of the data in the object module, which also has the "OnWrite" event.
An object module, as its name implies, is in almost every object in 1C, for example, catalogs, documents, charts of accounts, and many other objects.
The object module is designed to handle standard events. For example, the event of entering a new product into the catalog, the event of deleting an item, posting a document, etc.
Basically, the write event also exists in the form module (we covered this above). But the write event in the form module occurs during interactive recording when working with a specific form.
The “OnWrite” event in the object module will be executed on any write from any form of the given object. And even if the object is saved programmatically, in this case, the event of the object module will also fire.
All checks for the correctness of the data being written can be built into the write event of the object module since this procedure will be processed during absolutely any write.
Each object has its own list of events that can be handled in the object module. For example, here is a list of events for a catalog object module:
A similar list of events for the document object module:
As you can see, the list of events is different for different types of objects. It should also be noted that all object module procedures are always compiled and executed on the server. Accordingly, there is no need to specify compilation directives for procedures and functions of an object module.
In object modules, we can describe methods that can be exported, and these methods will be available from outside. To do this, describe the corresponding procedure with the “Export” keyword in the object module. Then it will be possible to access this procedure from outside:
Similarly, a developer can create a new property by declaring a variable with the Export keyword. This property can also be accessed from outside:
Thus, it is possible to expand the functionality of objects (to redefine new methods and new properties).
Important note! It should be understood that these new properties are dynamic and are not saved in the database when the object is written!
If we want to use a property for an object that will be stored in the database and whose value will be used several times, then in this case we should create an object attribute:
The manager module (as well as the object module considered above) is available for many objects (catalogs, documents, registers, etc.):
In general, the manager module and the object module are very similar. For example, the manager module also has a list of events that can be handled:
Also in the manager module, we can create a method with the "Export" keyword and this method will be visible from the outside:
But you probably saw the difference between how to access the methods in the object module and how to access the methods of the manager module. This is the difference between these modules: the manager module and the object module.
To refer to the export methods of an object module, the developer must first obtain the object itself. And from the point of view of the system, this is a rather "expensive" operation, since at this moment the entire object is being read.
The second difference is that the object module is available for a specific object, for example, for a specific product, or a specific invoice.
And in the manager module, it is possible to refer to a group of elements at once, or even to all elements at once. For example, if we want to print a catalog item, for example, some product, then we can place the print procedure in the object module and it will work. But it will be much more efficient if the printing procedure is placed in the manager module. In this case, it can be made universal, and it will print both one object and a group.
Well, it's time to summarize. We examined what software modules in 1C are, how they differ from each other, in which cases it is necessary to use one or another software module.
But that's not all. We still have a lot of interesting things. Stay with us!
