1c enterprise modules and their purpose. Common modules

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 launch? 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 to view 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 indicate the location of compilation (availability) on the Server or on the 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 executed when accessing a 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. Module events managed application are processed when launching the Thin and Thick Client of the Managed Application and the Web Client.

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 in the menu Service).

The form will open Options. On the bookmark General 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 context menu at the level of the root configuration object, or the properties palette for the root node.

The outer join process itself is a process program work With information base, 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 various 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.

Any quantity can be added common modules. For Common Module methods to be available elsewhere in the configuration, they must be defined with keyword Export. 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. given 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 name of the method, 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, turning to this directory necessary.

Those. there is a need to temporarily expand user rights, and then return them to initial 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 running application, depending on the work on the Client or 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 Common 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 will be 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 Only available 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 module controlled form clearly separated by 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 fixed methods of an object class, you can create for an object additional methods 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, it can be considered that it is applicable for of this element(in most cases this is exactly the logic).

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 looked at all of our program code in fragments from application solution, and as a rule, they wrote it in some small test configuration. 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!

Almost all configuration objects have a manager module, and for most objects an object module. Often, novice programmers do not understand the differences in the purpose of these two modules.

Understanding the difference in their purpose allows you to write program code that is more correct in structure, and in some cases save 1C server resources and increase the performance of the application solution.

In the article we will look at the fundamental differences between these modules both from the theoretical side and using a specific practical example.

Theory

Let's turn to the basics of object-oriented programming (OOP) and draw an analogy with our example. In OOP, methods for objects can be divided into static and simple. Simple Methods can only be called on a specific object that we have access to in the current code context. Static methods do not have direct access to object data. To access an object, you first need to create an instance of it. The same applies to the 1C:Enterprise 8.x platform.

In the object module, the platform stores procedures and functions that can only be called when working with a specific object, for example, with the object of the “Nomenclature” directory element. The manager module contains procedures and functions that can be applied to all objects of this type, but with the initial creation of an instance of this object. That is, to change an item of nomenclature from this module, first execute the “GetObject()” method to reference the element and then work with it.

Let's move on from theory to practice.

Practice

Let's move on to a practical example. Let's assume that we need to solve the problem of printing a list of products. The user prints a product either directly from a directory element or from the product list form. Let's consider two ways to complete the task.

Print procedure in object module

In the directory object module, add the following function:

// Pass a reference to a directory element to the function Function PrintSelectedProducts(Link) Export TabDoc = New TabularDocument; Layout = Directories. Goods. GetLayout("Layout"); Request = New Request; Request. Text = " SELECT | Products . Presentation AS Product,| Goods . MarkDeletion,| Goods . Article |FROM| Directory . Products AS Products|WHERE | Goods . Link B(&Product Array)" ; Request. SetParameter(" Array of Products ", Link); //Select by link

The program code is completely generated by the print designer. The only thing worth noting is the display by reference to the “Products” directory element in the request. The reference is passed as a parameter to the function. As a result of calling the function "PrintSelectedProducts" will be returned spreadsheet document with a completed product position.

The program code for calling the "PrintSelectedProducts" object method using the "Print" form command is presented in the following listing:

&OnClient Procedure Print(Command) // Contact the server procedure to receive the generated spreadsheet document TabDoc = PrintServer() ; // Show the generated spreadsheet document TabDoc. Show() ; EndProcedure & OnServer Function PrintServer() // Convert the form object into a directory object "Products" to call a function from the object module ObjectItem = FormAttributeValue("Object" ) ; // Call the object module procedure, passing there a link to the current directory element. Result // return to client part Return ObjectProduct. PrintSelectedProducts(Object.Link) ; EndFunction

Thus, we printed the current directory element by working with its object. But the task said to print a list of products that the user himself must select. When working with an object, it is not possible to give the user such an opportunity in a simple way. The most correct way would be to print from the list of items in the “Products” directory.

Printing procedure in the manager module

Let's add the following export procedure to the directory manager module:

// Pass an array of links to products Function PrintSelectedProducts(ArrayProducts) Export TabDoc = New TabularDocument; Layout = Directories. Goods. GetLayout("Layout"); Request = New Request; Request. Text = " SELECT | Products . Presentation AS Product,| Goods . MarkDeletion,| Goods . Article |FROM| Directory . Products AS Products|WHERE | Goods . Link B(&Product Array)" ; Request. SetParameter(" Array of Products ", Array of Products) ; // Set selection by array Result = Request. Run(); HeaderArea = Layout. GetArea("Title"); AreaFooter = Layout. GetArea(" Basement "); TableHeadArea = Layout. GetArea("Table Header"); TableFooterArea = Layout. GetArea("TableFooter"); DetailRecordsArea = Layout . GetArea("Details"); TabDoc. Clear() ; TabDoc. Output(AreaTitle) ; TabDoc. Output(TableHeadArea); TabDoc. StartAutoGroupingRows() ; SelectionDetailRecords = Result. Choose() ; While SelectionDetailedRecords. Next() LoopDetailRecordArea. Options. Fill(SelectionDetailRecords) ; TabDoc. Output(DetailedRecordsArea, DetailedRecordsSelection.Level()) ; EndCycle ; TabDoc. FinishAutoGroupingRows() ; TabDoc. Output(TableFooterArea); TabDoc. Output(AreaFootground) ; Return TabDoc; EndFunction

The main difference from a function in an object module is the function parameter. Now an array with links to products that need to be printed is passed as a parameter.

The program code of the “Print” form command module looks like this:

& On the Client Procedure Print(Command) TabDoc = PrintServer() ; TabDoc. Show() ; EndProcedure & OnServer Function PrintServer() // Pass an array of links of selected products in the directory list // into the manager module function "PrintSelectedProducts" Return Directories. Goods. PrintSelectedItems(Items.List.SelectedRows) ; EndFunction

In this case, the result of executing the command in 1C:Enterprise mode will be as follows:

If we use the method from the manager module, we can access the data in the “Products” directory without obtaining an object for each link. Since getting an object means getting all the data from the database for a directory element and placing the received data in RAM, implementing the task in the second way will have a positive effect on performance. After all, in this case we will use a minimum of resources ( RAM) server machine.

What to use?

As always, it all depends on the specific task. If you need to print a document, then more best option- use the manager module. If you need to fill an object, for example, external processing filling tabular parts, then in this case it is better to place procedures and functions in the object module, since their work involves working with the object.

In the standard configuration of "Trade Management" version 11, the manager module is used everywhere for printing documents. If you look at the "Management" configuration manufacturing enterprise", then the manager module is practically not used, since the configuration was written in older versions of the platform, where there was no full support for this mechanism.

Configuration with examples from the article.

Platform modules 1C:Enterprise 8.3, 8.2

Common modules

Functions that are declared with the "export" flag in such a module can be called from anywhere in the configuration. The call is made via CommonModuleName.FunctionName().

Such modules do not have a variable section.

The execution of common modules depends on the settings in their properties:

Flag "Global"

If this flag is set, then the context of such a module becomes global. That is, when accessing its export functions, you do not need to specify the module name. But the names of its export functions must be unique within the global configuration context.

Server flag

The functions of such a module can be executed on the server.

"Client (regular application)" flag

The functions of such a module can be executed on the client in the mode regular application.

"Client (managed application)" flag

The functions of such a module can be executed on the client in managed application mode.

"Server Call" flag

The flag is available for modules with the "Server" flag set. Allows the client to call the export functions of this module (which will be executed on the server).

External Join flag

The export functions of such a module can be called when connecting from an external source.

Flag "Privileged"

In a module with this flag, rights checking will be disabled. Suitable for productivity or administrative activities.

Reuse option

If you enable this option, the return values of export functions will be cached immediately after the first call. Caching is possible for the duration of the call (the execution time of a specific procedure) or for the duration of the user session.

Application module

Designed to handle application startup and termination events. There are two types: for regular and managed applications.

You should not overload it, as this affects the application startup time.

Session module

A special module that is used to initialize session parameters. It is necessary in order not to duplicate code in various application modules.

It should be used carefully, since the module can be executed several times, and can also be executed without further starting the database. Executed before application modules.

Sincerely, (teacher and developer).

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 connections.

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 fires when the web client starts, thin client and thick client 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 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 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.

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 time compilation, 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 various modes(which results 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 attributes, 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.