Platform modules 1C:Enterprise 8.3, 8.2
General 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 parameters set 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.
Flag "Server"
The functions of such a module can be performed on the server.
Flag "Client (regular application)"
The functions of such a module can be executed on the client in the mode of a normal application.
Flag "Client (managed application)"
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 this module's export functions (which will be executed on the server).
Flag "Outer join"
The export functions of such a module can be called when connected from an external source.
Flag "Privileged"
In a module with this flag, permission checking will be disabled. Suitable for productivity or administrative activities.
Reuse option
If you enable this option, then the return values of the export functions will be cached immediately after the first call. Caching is possible for the duration of the call (the time of execution of a certain procedure) or for the duration of the user session.
Application module
Designed to handle application start and end 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. Needed in order not to duplicate code in different application modules.
It should be used with care, as the module can be executed several times, and also be executed without further start of the base. Runs before application modules.
Sincerely, (teacher and developer).
The article presents short review and features of functionality such as Reusing the return values of shared modules.
Problems when working with 1C
Often, when working with the 1C program, it is required to obtain the values stored in the database, they do not change for years. An example would be the value of constants. This group of values can conditionally include the search for one of the elements of the directory or the search for the node of the exchange plan using the code, as well as the need to get the value of the details of the objects.
Such problems are solved quickly and simply using the following types of structures:
If DocumentDate > Constants.Regulation1137StartDate.Get() Then
But each time this code is executed, the database is accessed.
Many programmers use the following method to unload a database. They perform just one request to the knowledge base and cache the data that they may need. However, this method does not unload the databases to the desired value. The reasons for this may be as follows:
· not quite clear cycle of code execution (for example, during group reposting of documents);
Obtaining a strict set of data required not in this moment sometimes impossible or difficult;
· use of already cached data in various forms/calls.
Module with reuse return values
To solve the problems described above, the use of models with the reuse of return values will help. What it is? This is a general client or server module, in which the "Per call" or "Per session" function should be set to Reuse return values. All operations and functions directly in the module are described as before.
The undoubted advantage of this method is that the return of the cached value occurs without actually executing the function code. This happens with all subsequent calls to the export functions of these modules. The same effect can be seen when measuring performance.
When the code is executed, the returned values are cached through the values of the passed parameters. So this happens directly when the code is executed
Node1 = OurModule.GetExchangeNodeWithAccounting("0001");
Node2 = OurModule.GetExchangeNodeWithAccounting("0002");
Both one and the other call lead to the execution of the corresponding operation and return different references. However, the nodes with the code 0001 or 0002 will be returned already during the next calls, without causing a repeated operation and, accordingly, without accessing the database.
The values will be cached in isolation on each session on both the client and the server (depending on whether the call was made from the client or server module). Everything will work flawlessly if there are any peculiarities in the access rights settings or any other dependency of the received value.
A few BUT
As with any rule, there are exceptions to this method. Should not be specified complex types in the parameters of functions that are simple enough such as Date, Number, Indefinitely, and so on. You should not try to specify as parameters, for example, a structure, an object, or a table of values. You will get the result the first time, but nothing sensible will come out the second time.
The return value can be of any type.
In addition, do not forget to pay attention to the size of the data you are caching, since the server memory, although huge, is not unlimited.
Feature or bug from 1C
Values that are reused have an interesting feature. It can be assumed that this is a feature or a bug, but in any case, it is worth paying attention to.
When you enter the following code:
ValueStructure1 = OurModule.GetAttributesValuesStructure(ObjectReference);
ValueStructure1.Name = "New name";
ValueStructure2 = OurModule.GetAttributesValuesStructure(ObjectReference);
in ValueStructure2.Name, exactly the New name will appear. This can be used to update values that have actually changed in the database, but it is not known how much longer this can be done. Because when creating standard solutions, this cannot be done.
If the cached data has been changed
If cached values have changed in the database, there is only one way to use it - the UpdateReusedValues method. In this case, the values of the settings of all functions are reset in all modules. There is no possibility of updating by some parameter values, either functions or modules.
How a request is made in a loop
If you don't want to use a function that reuses return values, here are a few more creative ways to solve the problem.
· Universal procedures that return the details of arbitrary links.
· Creation of procedures that return values of constants by their name. By the way, such procedures are in standard versions.
· Return a volume slightly larger than needed to reduce the number of calls. For example, if you need to get the rate of several currencies at the same time, it is desirable to call the function exclusively by date without selecting currencies. Having received all the rates, determine which currency is now needed and which is not.
· Creation of a procedure that will execute a query with simultaneous caching of the result obtained (incoming parameters - query text, several parameter names and values).
There is one more method I would like to talk about in more detail. This method is based on the use of a function that contains a call to the database, with the return value being reused directly in the loop, that is, a kind of query in the loop. In some cases, this construction can improve performance. The following condition must be met: there must be a small number different meanings input parameters encountered in the loop, and most of the combinations have already been received at least once earlier in this session. It should be remembered that it is extremely difficult to get a certain set of combinations of all input parameter values in advance, and trying to get values for all possible combinations can lead to reading too much data from the database.
We have given you only exemplary functions and methods. Therefore, before using them, evaluate the conditions in which your code will work.
Print (Ctrl+P)
Objects located in the branch of the configuration tree Common modules are designed to contain the texts of functions and procedures that can be called from any other configuration module.
ATTENTION! A generic module can only contain procedure and function definitions.
The procedures and functions of a common module that have the Export keyword in their headers are among the constituent parts global context. You can learn more about writing procedures in a common module in the "Format of program module source texts" and "Operators" sections of the 1C:Enterprise language help.
To edit a common module, in the properties palette of an object of the Common modules type in the Configuration window, in the Module property, click the Open link. The text of the general module will be issued for editing in the 1C:Enterprise text editor in the program module text editing mode.
The common module, being part of the configuration, is saved only as part of the configuration.
The Global property determines whether the exported methods of a shared module are part of the global context.
If the Global property is set to True, then the exported methods of the shared module are available as methods of the global context.
If the Global property is set to False, then a property is created in the global context with the name corresponding to the name of the shared module in the metadata. This property is read-only. The value of this property is a GenericModule object. Through this object, the exported methods of this common module are available. Thus, accessing methods of non-global shared modules looks like XXXXX.YYYYY, where XXXXX is the name of the property corresponding to the context of the shared module, and YYYYY is the name of the shared module's exported method.
Example:
WorkWithTradeEquipment.ConnectBarcodeScanner();
Various context and common modules
Using the properties of common modules and preprocessor instructions, you can organize the execution of various methods of common modules in the desired context.
Each property of the common module is responsible for the ability to compile (and execute) the common module in a particular context.
The following properties are available, which are responsible for the context in which the methods of the shared module are available:
● Client (regular application)– methods of the common module will be available for the thick client in the normal application mode;
● – common module methods will be available for thin client, web client, and also for thick client in
managed application mode;
● Server – methods of the common module will be available on the server;
● Outer join– methods of the common module will be available in the outer connection.
If multiple properties are set at the same time, this means that the methods of the shared module will be available in multiple contexts.
If a shared module has the Server property and any other property set, this means that the shared module will be available on the server and in the selected client at the same time. At the same time, it is necessary to understand that in fact it will be several variants of the compiled code (according to the number of selected clients and for the server itself).
In this case, if a method located in such a common module is called from the client side, then the client copy of the common module will be used, and if from the server, the server copy will be used. In this case, using preprocessor directives (for more details, see here), you can “protect” the server from the code that cannot be executed on it.
Consider an example. There is a method in the common module (which can be executed on the thin client and on the server) that has slightly different behavior on the thin client side and on the server side. Let's see how this can be done:
#If ThinClient Then
// Show warning
ShowAlertUser(“On the client”);
#EndIf
EndProcedure
Then on the server side, the code will look like this:
Procedure CommonModule() Method Export
// Various important code goes here
EndProcedure
And on the thin client side, the code will look like this:
Procedure CommonModule Method() Export
// Various important code goes here
// Show warning
ShowUserAlert("On Client");
EndProcedure
There are several ways to transfer control from the client to the server:
● call a server common module method;
● in a form or command module, call a method that is preceded by compilation directives &AtServer, &AtServerWithoutContext
However, it is not possible to call methods of client common modules (that do not have the Server property set) and client methods of a form module or command module from server procedures. Control will return to the client after the outermost call to the server method has completed.
The exception is the methods of the form module and the command module, which are preceded by compilation directives &At the ClientAt the Server, &At the ClientAt the ServerWithoutContext
The following points should also be mentioned:
● If a shared module is available to more than one client, then when writing code, consider the maximum restrictions that clients may impose, or use preprocessor instructions to "isolate" client-specific code.
● Preprocessor instructions also make sense when a common module has multiple execution contexts, such as an external connection and a thin client, or (more commonly) a client and a server. In this case, the preprocessor instructions will wrap interactive code that cannot be used on the server, but is possible on the client (see example above).
For more information about preprocessor instructions and compilation directives, see the Execution of Procedures and Functions section of the 1C:Enterprise Language Help.
The Server Invocation property controls whether the exported methods of the server common module can be called from client code.
If the property is set, then the exported methods of the server-side shared module are available to be called by the client. If the property is not set, then such exported methods can only be called from server methods (both methods of server common modules and server methods of the form module and command modules).
Advice . We recommend that you set the Server Invocation property to False in cases where the server-side common module contains methods that you do not want to call from the client (for security reasons, for example).
Note. If properties are set at the same time Client (regular application), Client (managed application), Outer join, then the Call Server property is automatically reset. If the Call server property is set, the properties are automatically reset Client (regular application), Client (managed application) and Outer join if these properties were set at the same time.
Property Privileged is designed to disable access control when executing methods of a common module.
NOTE. If property Privileged is set, then the Server property is automatically set for the common module and other properties are reset ( Client (regular application), Client (managed application) and B external connection). A privileged shared module can only run on the server.
Reusing return values
If the shared module is not global, then the Reuse return values property becomes available. This property can take the following values:
● Do not use - Return values are not reused for functions in this shared module.
● Per Call and Per Session - The shared module uses the data reuse detection method. The essence of this method lies in the fact that during the execution of the code, the system remembers the parameters and the result of the functions after the first function call. When the function is called again with the same parameters, the stored value is returned (from the first call) without executing the function itself. If the function changes the parameter values during its execution, then calling the function again will not do it.
The following features of saving call results can be distinguished:
● if the function is executed on the server and called from the server code, then the parameter values and the result of the call are remembered for the current session on the server side;
● if the function is executed on a thick or thin client, then the values of parameters and call results are stored on the client side;
● if the function is executed on the server side and called from the client code, then the values of the call parameters are remembered both on the client side and on the server side (for the current session).
Stored values are deleted:
● if the property is set to For the duration of the call:
● on the server side – when control is returned from the server;
● on the client side – when a top-level 1C:Enterprise procedure or function terminates (called by the system from the interface, and not from another 1C:Enterprise procedure or function);
● if the shared module property is set to For the duration of the session:
● on the server side – at the end of the session;
● on the client side – when the client application is closed.
Saved values will be deleted:
● on the server, thick client, external connection, thin client, and web client with normal connection speed - 20 minutes after the stored value was calculated or 6 minutes after the last use;
● in a thin client and a web client with low connection speed - 20 minutes after calculating the stored value;
● when there is a shortage of RAM in the server's working process;
● when restarting a workflow;
● When a client switches to a different workflow.
After deleting the values, the call to the exported function is performed as in the first call.
This property of common modules does not affect the execution of procedures – procedures are always executed.
If a shared module has return value reuse set, there are a number of restrictions on the parameter types of the exported function. Parameter types can only be:
● Primitive types ( Undefined, NULL, Boolean, Number, String, Date).
● Any references to database objects.
● Structures with property values of the above types. In this case, the identity of the parameters is controlled "by the content" of the structures.
If the exported function returns any object, it actually returns a reference to the object stored in the cache. If the state of the object changes after receiving this reference, then a subsequent call to the same function will return a reference to the already changed object without actually executing the function. This behavior will continue until the stored value is removed (for whatever reason). In other words, changing the state of an object obtained as a result of calling a function from a common module with reuse of return values is not the basis for actually calling the function. Also keep in mind that the returned object cache is indifferent to
state of privileged mode at the time of the function call, with return values reused. This feature can lead to next feature behaviors:
● The actual execution of the function call with return value reuse (the first call) was done with privileged mode enabled.
● When executing a function, an object was received that cannot be received with privileged mode disabled.
● Subsequent calls to the function were made without setting the privileged mode.
● However, until the cache of returned objects is cleared or the actual call is made again, the function will return a formally inaccessible object.
● The reverse behavior is also true, where the first call is made without setting privileged mode, and privileged mode does not return an object that might have been obtained in privileged mode.
If the common module has a property Reusing return values is set to For the duration of the session, then the values returned by the functions of such a module cannot use values of type TemporaryTable Manager.
If a function of a shared module, with reuse set, is called from the same shared module (for example, with the name SharedModule ), then you should remember the following feature: if the function is called by the name MyFunction() , then the function will be executed every time the function is called . In order to use stored values, the function must be called by its fully qualified name:
GeneralModule.MyFunction().
The global context method removes all reused values, both server-side and client-side, regardless of where the method is called. After executing the method UpdateReusableValues() the first function call will be executed completely.
The article continues the cycle "First steps in development on 1C", it discusses in detail the following issues:
- What software module And what sections does it consist of?
- What is the application module for? Why are there two? When does it start? What are the details of the work?
- What events are associated with the start of the system, 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 shared modules? What are its properties and rules of operation? Why use the Reuse Return Values property?
- When is the form module used and what events can be handled 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 is the difference between an object module and a manager module? When should you use the latter?
Applicability
The article deals with 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 a fairly 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 a module. There are general purpose modules and object modules. Some modules can be compiled both on the Client and on the Server, and some only on the Server.
A module can consist of several sections. The variable declaration section describes the local variables of this module, which can later be used in any procedure.
Within each procedure, you can access the module variable. In addition, within the procedure itself, there may be another declaration of a variable with the same name. This will be a local variable for this procedure.
Despite the same name, these are two different variables: one is used inside a specific procedure, and the other is used outside of it.
In some modules, the variables can be set to the compilation location (availability) on the Server or on the Client. For example:
The variable declaration section is followed by the procedures and functions section, which specifies the local methods of the module. Some modules require you to 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 the program code, it is recommended to explicitly indicate where this procedure will be compiled. The order in which the procedures are described does not matter.
At the end of the module, after the description of all procedures and functions, there is a section of the main program, which may contain some operators, initialize the local variables of the form module. This section is executed when the module is accessed.
So, for example, when opening the form of an element, the section of the main program of the form module is executed first of all.
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 invalid in some modules). A procedure and function description section can exist in absolutely any module.
Application module
This module is designed to handle application startup and shutdown events. For example, when you start the application, you can download exchange rates from the Internet. At the end of the application, you can make sure the user about his intentions to end the work.
Also in the application module, there are special handlers that allow you to intercept external events from the equipment.
These can be events from a magnetic card reader, fiscal registrar. And these events can be handled in some way too.
It should be noted that it is the interactive launch of the system that is tracked in the application module.
The application module will not work if the 1C program is launched, for example, in com-connection mode. In this case, the program window is not created.
It should be noted that in Platform 8.3 there are two different application modules: the Managed Application module and the Regular Application module. Managed application module events are fired when the Thin and Thick Clients of the Managed Application and the Web Client are launched.
Module General application works when the Thick Client is started in the mode General application, which has the usual command interface in the form main menu.
If the application is running and Managed, and in the mode General application, then it is necessary to describe the handler procedures as for the module managed application, and for the module General application.
Module managed application can be selected from the context menu of the configuration root node.
This module can also be opened from the properties palette of the root configuration element.
To open a module General application, you should refer to the configuration settings (command Options on the menu Service).
A form will open Options. Bookmark General config edit mode must be specified Managed application and General Application.
In this case, the module General application can also be opened from the properties of the root node.
List of events that can be processed for Managed and General application the same.
In this module, you can place a variable declaration section, a section for describing arbitrary procedures and functions, and a section for the main program. 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 while the module is open.
The opened Procedures and functions window displays all 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 related to system shutdown (“before” and “at”). As well as processing an external event (for example, an event of a shop equipment).
When the "before" event handler is executed, it is considered that the action has not yet taken place. When the “on” event handler is executed, the action has already taken place.
Event BeforeStartingSystem occurs at the moment when Enterprise 8.3 is launched, but the application itself has not yet appeared on the screen. This event has such a parameter as Refusal.
If this parameter is set to True, then the application will not start. Event When Starting the System assumes that the action has already been taken, the window has already been created, and in this case we can, for example, display some special form. You can no longer refuse to launch.
Similarly, before shutting down the system, the application is still open and you can choose not to shut it down. When the system was shut down, the application window was already closed. It is only possible to perform additional actions, such as 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 compiled entirely 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 the module managed application you need to make a Server call, then for this you will need to create special with a flag displayed .
In the module General application there are no such restrictions, since this module will be compiled when loading the Thick Client. Almost all data types are available in the Thick Client.
Procedures, functions and variables of an application module can be described as export.
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, from the form module of some object, you can call a procedure or function of the application module. However, it is recommended to use General Modules to describe general algorithms. The main purpose of the application module is to handle the start point and end point.
By analogy with the application module, this module is designed to handle the program opening event and the shutdown event.
Unlike the application module, which is initiated when the application is launched interactively, the external connection module operates in com-connection mode, i.e. when a 1C:Enterprise 8 object is created and a connection is made to a specific database.
This module has events: When Starting the System and when shutting down the system.
The outer connection module can be opened using either the context menu at the level of the root configuration object or the properties palette for the root node.
The external join process itself is a process of programmatic work with an infobase, not an interactive one. Accordingly, at this moment it is impossible to use dialog forms, 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 connection, the Outer Connection Module is compiled entirely on the Server.
session module
This module is needed in order to initialize session parameters. Session parameters are fast 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.
An event is provided in the Session Module SettingSessionParameters.
When the application starts, this procedure is called the very first. Session parameters are needed for any application operation: both when launched interactively and when launched in external connection mode.
The Session Module describes various actions to initialize session parameters depending on different conditions.
This module, as a rule, describes several procedures that are called from the procedure SettingSessionParameters. Therefore, all these procedures are separated into a separate module.
The session module always runs in privileged mode. This means that no permission check will be performed when accessing the database. The session module is compiled on the Server, i.e. it is possible to call any server methods (including reading values from the database).
It is possible to define only procedures and functions in the Session Module, i.e. there is no variable declaration section and no main program section. You cannot declare export methods in a Session Module.
If at system startup it is necessary to perform some actions on the Server, for example, to create an element of some 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 multiple times during application execution;
- if the number of elements in the array of session parameters is equal to zero (the array of required parameters has the data type Undefined), then this is the moment the application is launched;
- since the Session Module works in privileged mode and there will be no access checks, you should be very careful when working 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, extra actions can be performed in the event handler of the SetSessionParameters event.
These modules are descriptions of some general algorithms, i.e. procedures and functions that can be called from various places.
Logically related methods can be grouped into different Common Modules. These modules are created inside the General branch.
You can add any number of shared modules. To make Common Module methods available elsewhere in the configuration, they must be defined with keyword Export. Client procedures of common modules will be available on the Client, and server procedures - on the Server.
In Common modules, only the section describing procedures and functions is available. Those. in the Common module you cannot declare variables and you cannot describe a section of the main program.
If a global variable is needed, either session parameters or application module export variables can be used.
For Common modules, you can set some parameters that will affect the behavior of this module. If the Global property is set for a Common module, then the export methods declared in this module will be available from outside directly, without any additional instructions.
Those. the General module will participate in the formation of the global configuration context.
Property Global for common modules can be useful. However, you should not use it universally for all common modules.
Those , which are marked with 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 the compilation of this module will be performed at the time of the first call to it (that is, after the system starts).
In addition, the use of global shared modules affects the understanding of the code. Calling methods of a non-global shared module is done through the name General module and the name of the method, for example:
Cost Calculation Module. Allocate Indirect Costs();
At the same time, the names of the General modules should reflect the content of the procedures described in them. Specifying the name of the Common Module when calling a procedure makes the code easier to understand.
For General module in Properties Palette property can be set Privileged.
Access rights are not controlled in a privileged module. This is necessary if in General module it is required to perform bulk data processing, obtaining data from the database.
Access control increases database access time, and bulk algorithms often need to run as fast as possible.
For example, a resource-intensive operation is the calculation wages. 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 control is performed.
In this way, a significant increase in performance can be achieved. This is especially true for the case of using the mechanism of line-by-line access differentiation to table records.
If the 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, an appeal to this guide is necessary.
Those. there is a need to temporarily expand the user's rights, and then return them to their original state. This effect can be obtained by using privileged Common modules.
To do this, in a privileged General module it is necessary to issue a procedure that accesses the necessary 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. Flags are used to determine whether the Common Module will be available on the Client (managed application), on the Server, in the External Connection mode.
In addition, if you switch the configuration editing mode to a Managed application and a regular application, then one more compilation context will be possible - the Client (normal application).
Thus, there are four options for the functioning of the program. Depending on the running application, depending on the work on the Client or on the Server, certain Common modules will be available or unavailable.
In addition to the ability to specify compilation flags, it is possible to specify compilation directives for procedures and functions located in the Common module.
If a compilation directive is specified for a method, then although the Generic module is available in all specified contexts, the accessibility of a particular method will be limited by the compilation directive.
In this case, the procedure cannot be accessed in a context that is not available in general for the entire module.
If the compilation directive is not specified for a procedure (function), then it will be compiled in all contexts defined for the module.
Those. in effect, multiple copies of the procedure will be made. The choice of a particular compiled instance depends on where the procedure is called (by the rule of closest call). At the same time, it should be taken into account that the code of such a procedure must be written taking into account its accessibility in all contexts defined for the module.
Common modules that are available in several different contexts at the same time are primarily designed to create procedures that are available in several contexts.
When creating a Generic module, it's good practice not to specify compilation directives. Those. the accessibility 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 multiple compilation flags set are rarely used in practice. These are some common actions available on both the Client and the Server. Usually, these are some simple calculations.
Important! It is possible to access the export server methods of the Shared Module from the Client, but only if this Shared Module is compiled only on the Server. At the same time, a special checkbox is intended to provide access from the Client. .
For non-global Common modules, it is possible to cache those values returned by functions. Those. the system can remember the result of its execution after the first call to the function. If this function is called again with the same parameters, the system will return the value already from the cache.
The purpose of this mechanism is to speed up repeated calls. To configure this behavior, you need to Properties Palette module to set the appropriate value for the Reuse return values property.
By default, this property is set to Do not use. Other possible values: cache At the time of the call, or For the duration of the session.
This property makes sense to use only for those functions, the result of which depends solely on the input parameters. This mechanism is only available for non-global Common modules.
If the value of the corresponding parameter For the duration of the call is selected, then the cache will be active as long as the procedure from which the method of the Common module was called is running. If the value is For the duration of the session, then the cache is conditionally considered to be active while the user is working.
However, there are certain time limits. The cache is cleared automatically 20 minutes after the value is cached.
Form Module
This module is designed to handle user actions. For example, describe the program's reaction algorithm when a button is pressed. Or, for example, at the time of entering the value in the 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 open event and do some initial initialization. You can also handle the form close event and check if the user entered everything correctly.
There are forms managed and forms normal. The form data modules differ primarily in that the managed form module is clearly separated into a context. Each procedure (function) must have a compilation directive. In its 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 moment the form is initialized, i.e. when the user opens it. The figure shows a list of standard events for a managed form.
The list of managed form events is also visible in the property list for the form itself. This list is called in the managed form editor.
AT managed form you can handle the write event of the element. This event is present only for forms of objects (reference books, documents, and some others). If the form is not bound to a specific object, then there is no write event.
For a regular form module, the list of standard events is somewhat smaller, because in a managed form, many events are made in pairs (one is executed on the Client and the other on the Server). In the usual form, all code is executed on the Client.
Object module
These modules are typical for directories, documents, plans of types of calculations, charts of accounts and many other objects. The object module is designed to process 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 interactive writing, when working with a specific form.
The write event in the object's Module will be fired on any write from any form of the given object. Also, if the object is written programmatically, the object's module event will fire in that case.
In the write event of the Object Module, you can embed all checks for the correctness of the data being written, since this procedure will work out at the time of absolutely any write.
The module of this object can be called via the context menu, from the object's Properties Palette, and from the object editing window.
The figure below shows a list of available events of the directory module.
In the Object Module, you can place a section for describing variables, describe 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 the local variables of this 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 are not required for procedures and functions of the Object Module. Some configuration objects do not have Object Modules.
This is due to the features 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.
AT Value manager module you can handle recording events Constants and filling check 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 population 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 available from outside.
Those. In addition to using the fixed methods of an object class, you can create additional methods for an object in the Object Module. This module should describe the relevant procedure with the keyword Export.
Then it will be possible to refer to this procedure from outside. Moreover, this method will be displayed in the context tooltip. New methods in the context tooltip are highlighted in blue (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.
Thus, it is possible to extend the functionality of objects (add new methods and new properties). The properties are dynamic and are not stored 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 edit window.
You can override some standard events in the Manager Module. For example, in ProcessingReceivingDataChoice, when an element is selected from the dictionary, you can do some additional filtering or checking.
In addition, you can create additional methods in the Manager Module and specify that they are export methods. In this case, it is possible to access these methods from outside.
In order to perform this call, you need to get the data type DirectoryManager.
The difference between the export methods of the Manager Module and the Object Module is that in order to call the method of the Object Module, you first need to get the object itself (that is, somehow get a link and then convert this link into an object).
After that, the export variables and methods of the Object Module will be available. For the Manager Module, the call is simpler, for example:
Directories.Accounts.MethodName
These are two different appeals. Convert from reference to object (method GetObject) is a fairly serious action for the system, since when an object is received, absolutely all the data of this object is read, which can be quite lengthy.
The second difference is that ObjectModule invoked in the context of a specific element. Accordingly, we can assume that it is applicable for this element (in most cases, this is the logic laid down).
As for the Manager Module, it describes some general action for a group or for all elements of a directory or some document. For example, if you need to print a reference item, you can use the Object Module.
But in the Manager Module it is possible to make a more universal mechanism that will print, among other things, a group of elements.
In addition, accessing the object's 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 configuration of the 1C:Enterprise system. If we sum up all of the above, then 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
- Program modules are classified according to the types that we examined in this article. Each view is defined by its placement and available programming context.
- The structure of the module consists of some 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 kind of module, namely the command module. It does not represent anything remarkable, and we suggest that you familiarize yourself with its functionality.
So far, we have considered all our program code fragmentarily from the applied solution, and, as a rule, we wrote it in some kind of small test configuration of our own. Are you aware that “you can’t just take it” and start editing the code of a typical configuration? Not? Then in the next article we will explain it all!
