And Data Transfer Object to code structuring, managed form in 1C 8.2 environment.

Introduction

Let's start with a short description of the concept of "managed form" and related concepts of the 1C platform. Platform experts can skip this section.

Became available in 2008 a new version platform 1C: Enterprise 8.2 (hereinafter referred to as Managed Application), which completely changes the entire layer of work with the interface. This includes the command interface, and forms, and the window system. This not only changes the user interface development model in the configuration, but also proposes a new architecture for the separation of functionality between the client application and the server.
A managed application supports the following types of clients:

Thick Client (Normal and Managed Launch Mode)
Thin Client
Web client

A managed application uses forms built on new technology. They're called Managed Forms. For ease of transition, older forms (so-called regular forms) are also supported, but their functionality is not developed and they are only available in the rich client launch mode.
Main differences of managed forms for the developer:

Declarative, not "by pixels" description of the structure. The specific placement of elements is done automatically by the system when the form is displayed.
All functionality of the form is described in the form details and commands. Details are the data that the form works with, and commands are the actions performed.
The form is executed both on the server and on the client.
In the context of the client, almost all application types are not available, and accordingly it is impossible to change the data in the infobase.
For each method or form variable, it must be specified compilation directive A that specifies whether the execution location (client or server) and access to the form's context.

Here are the directives for compiling form methods:

&AtClient
&On server
&OnServerWithoutContext
&At the ClientAt the ServerWithoutContext

Let's illustrate the above. The screenshot shows an example of a managed form and its module in development mode. Find declarative description, props, compilation directives, etc.

All further discussions will be about the right side of the illustration, about how to structure the module code and what principles will allow you to implement effective client-server interaction.

Let's define the problem

Several years have passed since the new version of the 1C platform has been actively used and many solutions (configurations) have been released both by 1C and its many partners.
Have developers developed a common understanding of the principles of client-server interaction when creating forms during this time, and has the approach to implementation changed? software modules in new architectural realities?

Consider the code structure (form module) in several forms of the same typical configuration and try to find patterns.
Under the structure, we mean sections of code (most often these are comment blocks) allocated by the developer for grouping methods and directives for compiling these methods.
Example 1:
Event handler section Method - on the client Method - on the server Method - on the client Section of service procedures and functions Input control auxiliary functions
Example 2:
Service procedures and functions Payment documents Valuables Event handlers
Example 3:
Service procedures on the server Service procedures on the client Service procedures on the server without context Header event handlers Command event handlers
Example 4:
General-purpose procedures Form event handlers Procedures of the "contact information" subsystem
In fact, the code structure is missing, or to put it mildly, it is similar to what was in forms 8.1:

Non-informative words "General, Service, Auxiliary."
Timid attempts to separate client and server methods.
Often methods are grouped by interface elements "Working with tabular part Products, Contact information".
Arbitrary arrangement of methods and code groups. For example, Event Handlers may be at the top in one form, at the bottom in another, not highlighted at all in a third, and so on.
And let's not forget that this is all within the same configuration.
Yes, there are configurations in which the words “General, Service, Auxiliary” are always in the same places, but ...

Why do you need a code structure?

Simplification of maintenance.
Simplify learning.
Fixing general/important/successful principles.
…your option

Why does the existing development standard from 1C not help?

Let's look at the principles published on the ITS disks and in various "Developer's Guides ...", recommended when writing a managed form.

Minimize the number of server calls.
Maximum computing on the server.
Non-context server calls are faster than context calls.
Program with client-server interaction in mind.
etc.

These are slogans that are absolutely true, but how can they be realized? How to minimize the number of calls, what does it mean to program in client-server mode?

Design patterns or generational wisdom

Client-server interaction has been used in various software technologies for decades. The answer to the questions outlined in the previous section has long been known and is summarized in two basic principles.

Remote Facade(hereinafter Remote Access Interface)
Data Transfer Object(hereinafter referred to as Data Transfer Object)

Word to Martin Fowler, his description of these principles:

… each object potentially intended for remote access must have low granularity interface, which will minimize the number of calls required to perform a particular procedure. … Instead of requesting an invoice and all of its points separately, it is necessary to read and update all points of the invoice in one call. This affects the entire structure of the object...Remember: the remote access interface does not contain domain logic.
... if I were a caring mother, I would definitely tell my child: “Never write data transfer objects!” In most cases, data migration objects are nothing more than bloated fieldset… The value of this disgusting monster lies solely in the possibility transmit multiple items of information over the network in one call- a technique that is of great importance for distributed systems.

Examples of templates in the 1C platform

The API available to a developer when developing a managed form contains many examples of these principles.
For example, the OpenForm() method, a typical "coarse" interface.
OpenParameters = New Structure("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form = OpenForm(FormName, OpenParameters);
Compare with v8.1 style.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

In the context of a managed form, a set of "Data Transfer Objects". Can be distinguished systemic and developer-defined.
System ones model an application object on the client, in the form of one or more form data elements. You cannot create them outside of binding to the form details.

DataFormsStructure
DataFormsCollection
DataFormStructureCollection
DataFormsTree

The conversion of data transfer system objects to application types and vice versa is performed by the following methods:

ValueVDataForm()
FormDataToValue()
CopyFormData()
ValueVFormProps()
FormAttributeToValue()

Often an explicit conversion is used when adapting an existing solution. Methods may expect (feature) input parameters, such as ValueTable rather thanFormDataCollection, or the method was defined in the context of an application object and became unavailable for direct call from a form.
Example 1C v8.1:
// on the client in the context of the form FillUsersCache(DepartmentReference)
Example 1C v8.2:
// on the server in the context of the form ProcessingObject = FormAttributeToValue("Object"); ProcessingObject.FillCacheUsers(DepartmentReference); ValueVFormAttribute(ProcessingObject, "Object");

Data migration objects, whose structure is defined by the developer, are a small subset of the types available on both the client and the server. Most often, as parameters and results of methods of a "coarse" interface, the following are used:

Primitive types (string, number, boolean)
Structure
Conformity
array
Links to application objects (unique identifier and text representation)

Example: the method accepts a list of orders to change the status and returns a description of the errors to the client.
&OnServerWithoutContext Function ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [order][error description] For Each Order From Orders Loop StartTransaction(); Attempt DocOb = Order.GetObject(); …. other actions, possibly not only with the order... Exception CancelTransaction(); Errors.Insert(Order, DescriptionError()); End of Attempt; EndCycle; Return Error; EndFunction // ServerChangeOrderStatus()

Structuring the code

The main goals that the managed form module should reflect and approaches to the solution.

Clear separation of client and server code. Let's not forget that at the time of execution these are two interacting processes, in each of which the available functionality differs significantly.
A clear selection of the remote access interface, which server methods can be called from the client, and which cannot? The names of the remote interface methods begin with the prefix "Server". This allows you to immediately see the transition of control to the server when reading the code, and simplifies the use of contextual hints. Note that the official recommendation (ITS) suggests naming methods with postfixes, such as ChangeOrderStatusOnServer(). However, to reiterate, not all server methods can be called from the client, and so logical accessibility is more important than compilation location. Therefore, with the “Server” prefix we mark only the methods available to the client, we will call the example method ServerChangeOrderStatus().
Readability. A matter of taste, we accept the order when the module begins with the procedures for creating a form on the server and remote access methods.
Maintainability. The place to add new code must be clearly defined. Important point, which are automatically created by the method stub configurator, are added to the end of the module. Since form element event handlers are most often automatically created, the corresponding block is placed last so as not to drag each handler to another place in the module.

Below is the basic structure of the module that implements the listed goals.

Graphical option - clearly shows the main flow of execution.
The text version is an example of a template design for quick insert structures into a new form module.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Date=""/> // <Описание> // // /////////////////////////////////////////////////// ////////////////////////////// // MODULE VARIABLES //////////////// /////////////////////////////////////////////////// ////////////// // ON THE SERVER //******* EVENTS ON THE SERVER ******* &On The Server Procedure On CreationOn The Server(Failure, StandardProcessing) //Insert the contents of the handler EndProcedure //******* REMOTE ACCESS INTERFACE ******* //******* BUSINESS LOGIC ON THE SERVER ******* ///////// /////////////////////////////////////////////////// ///////////////////// // COMMON CLIENT AND SERVER METHODS //////////////////////// /////////////////////////////////////////////////// //////// // ON THE CLIENT //******* BUSINESS LOGIC ON THE CLIENT ******* //******* COMMANDS ******* //******* EVENTS ON THE CLIENT ****** //////////////////////////////// ///////////////////////////////////////////////// / / MAIN PROGRAM OPERATORS

About managed forms 1C (Beginning)

Thin Client

There is nowhere thinner. Now the client application does not query the database (this is the server's business). The client application simply displays the interface and data.

It is worth noting that the code structure has become more complicated due to such transformations. On the client, there are no references, objects, table of values... only primitive types are available (string, date, boolean, array, structure...). This means that the programmer must now think about what to get on the server, and how to do it at minimal cost.

Client-Server Interaction

A new approach to the interaction between the client and the server allowed us to create a new model of the user interface. Now the interface is declared(!) interface design begins with data, with details and tabular parts. When creating a prop, you have to think about how it will look in the interface, whether it will be required, how it is related to other props...

No context (state) on the server

The 1C server works on the principle of "stateless" (English state-less). This means that the server only responds to requests, and at the same time does not store anything between two requests (there is temporary storage for this purpose).

FormDataToValue,FormDataCollection,FormData...

We turned to the server, he did everything for us, deleted the data and forgot that we came. All objects named "FormData" + "something there" will help us save our data between two server calls.

Temporary storage

Temporary storage is a special place where (in addition to form details) you can save state on the server. The storage can store data that is not available on the client (that is, that cannot be placed in the form details).

To work with temporary storage, use the MoveToTempStorage() methods Syntax: PlaceToTempStorage(<Данные>, <Адрес>) Description: Stores a serializable value in temporary storage. Availability: Thin client, web client, server, thick client, external connection, mobile application (client), mobile application (server). The method call makes a call to the server.<Адрес>(optional) Type: UniqueIdentifier; Line. The unique ID of the form in whose temporary storage the data is to be placed and the new address is to be returned. Or the address in the temporary storage where the data should be placed. The address must be obtained earlier using this method. If a form UniqueIdentifier or an address in storage is passed, then the value will be automatically deleted after the form is closed. If a UniqueIdentifier is passed that is not a unique identifier for the form, then the value will be deleted when the user's session ends. If the parameter is not specified, the value placed will be deleted after the next server request from the shared module, on context and non-context server calls from the form, on server calls from the command module, or on form fetches. Note: Temporary storage created in one session is not accessible from another session. An exception is the ability to transfer data from a background job to the session that initiated the background job using temporary storage. For such a transfer, in the parent session, place an empty value in temporary storage, passing the form identifier. Then pass the received address to the background job through the parameters of the background job. Further, if this address is used in the parameter<Адрес>, the result will be copied to the session from which the background job was started. Data placed in temporary storage in a background job will not be available from the parent session until the background job completes. and GetFromTempStorage() Syntax: GetFromTempStorage(<Адрес>) Description: Gets a value from temporary storage. Availability: Thin client, web client, server, thick client, external connection, mobile application (client), mobile application (server). The method call makes a call to the server. Note: The result of the execution is not cached, the server is called every time the method is called.

Calling Server Code

Any call to the server code always serializes the transmitted data. All parameters are packed into a string form and transmitted over the network. The result of the work is also transferred back in a serialized form, where it is then restored into familiar objects.

Assignment of module flags

The flag indicates where the module code will be compiled (on the server, on the client, in an external connection)
If a module is compiled in multiple places, then it will only be visible according to the flags
The transfer of code execution is possible only if there is no called module in the current execution context, but it exists elsewhere (if the module exists only on the server, and it does not exist on the client, then the server will be called)

Server call flag

Starting with the 1C:Enterprise 8.2 platform, the "server call" flag has been added. Which just helps to "resolve" the conditions for the transition to another machine. If this flag is assigned to the module, then the module will be visible from the client, if not, then an attempt to call from the client will result in an error. The module code will not be visible, as if it does not exist at all.

Thus, in a regular thick client, you can transfer the code to the server only if you call a common module from the client, for which:

Server checkbox checked
"Call server" checkbox is checked
Removed all "client" checkboxes

With the advent of the 1C Enterprise 8.2 platform, the user interface development mechanism has changed significantly. Now you can create managed forms and applications (Figure 1).

Picture 1

In addition, a new system for separating functionality between the client application and the server is proposed.
A managed application supports the following types of clients:

Thick client (normal and managed launch mode),
thin client,
Web client.

The mechanism for creating managed forms is significantly different from conventional forms. First of all, managed forms differ in that they are created automatically by the system based on special settings; now the programmer does not need to draw each form in detail. All functionality of the form is described in the form of details and commands. Details are the data that the form works with, and commands are the actions performed. For each method or form variable, a compilation directive must be specified, which determines the place of execution (client or server). Compilation directives can be:

&AtClient,
&On server,
&OnServerWithoutContext,
&At the ClientAt the ServerWithoutContext.

A managed form also differs from a regular form in the data types it works with. If a regular form works with most types provided by 1C:Enterprise (including the types DirectoryObject, DocumentObject, etc.), then the following categories of types can be distinguished in a managed form:

types that are directly used in the form are those types that exist on the side of the thin and Web client (for example, Number, ReferenceReference.Products, GraphicScheme, SpreadsheetDocument);
the types that will be converted to special data types are managed form data types. Such types are displayed in the list of form attributes in parentheses, for example (CatalogObject.Products);
dynamic list.

The functioning of managed forms has the following distinctive features (Figure 2):

The form exists both on the client and on the server.

It performs client-server interaction (transfer of data and design properties of elements).

Form does not work with application objects

Figure 2

The form uses special generic objects
DataForms(Figure 3).

Figure 3

Application objects work only on the server and only during certain operations.
When opening a form:

The object is read from the database,
The object is converted to form data,
The object is removed (from memory),
The form data is passed to the client.

When recording:

Form data is received from the client,
The form data is converted into an object,
The object is written to the database,
The object is removed (from memory).

In the last lesson, we considered for a regular (fat) client. In platform version 1C 8.2. They use new screen forms 1C 8.2. They are called managed forms 1C 8.2.

Managed forms 1C 8.2 is the future of 1C. They differ from ordinary 1C 8.2 forms in that they are automatically generated by the system based on special settings (“regular” forms are simply drawn by the programmer at will).

The differences in the development of managed forms 1C 8.2 from the usual ones are significant. Therefore, we have gathered today to separately discuss the creation and modification of managed forms 1C 8.2.

Managed forms 1C 8.2

If you have been developing 1C configurations before, when you open the 1C 8.2 managed form editor, you will immediately be confused by the fact that it is impossible to influence the 1C 8.2 form at all with the mouse.

You cannot change the 1C 8.2 form, you cannot move the element, you cannot even view the properties of the field as before - by double-clicking the field on the 1C 8.2 form.

Now the basis for developing the 1C 8.2 form is not binding fields to coordinates on the form, but special settings. The system automatically generates a managed form 1C 8.2 based on these settings.

The settings consist of a list of 1C 8.2 form elements located in the editor in the upper left corner. The elements of form 1C 8.2 include:

Requisites
Commands (new concept 1C 8.2, may look like buttons or menu items)
Groups (to combine details and commands).

Accordingly, the settings of these elements are not in the properties of the fields, but in the properties of these settings elements (right-click menu, Properties item).

How managed forms 1C 8.2 work

Working with managed forms 1C 8.2 is different for the user. They have more features, but are unusual for those who have been working with 1C for a long time.

First of all, the location of the usual elements on the form 1C 8.2 differs. The command bar is always at the top.

The left side of the command bar is customizable. It usually contains such typical buttons as Record and Post.

The right side of the command panel is the new standard menu of the 1C form All actions. This menu allows you to manage the 1C 8.2 form as you wish, similar to how the settings in the ACS report allow you to significantly change the appearance of the report.

Arbitrary menu items 1C All actions

Depending on whether this form 1C 8.1 belongs to one or another, the menu is filled with items that allow you to manage this object. For example, if it is a directory list form, then there will be commands such as Create or Edit.

Item Customize menu list 1C All actions

If there is a list on the 1C 8.2 form, then the menu has the command Set up list and Display list.
If the Output List command is already familiar to you - it allows you to save any list in 1C in Excel / print it, then the second command is new.

As you have already noticed, there are no more selection buttons on the lists command bar. Instead, the Find button appeared, to which work (as well as to the now disabled positioning of the cursor in the list when typing) - there are complaints.

The functionality of the Find button, of course, is not comparable to the selections, but they have not disappeared anywhere!
They are now in the Customize List menu item. Selection can now be done by any field, and in addition to it, sorting and conditional formatting can be done in the same way as it can be done in SKD reports.

Item Change menu form 1C All actions

The Change form item allows you to similarly change not only the list on the 1C 8.2 form, but also the 1C 8.2 form itself.

The user can independently enable or disable the visibility of fields on the 1C 8.2 form, width and height, activation of the default field when opening, etc.

Using managed forms 1C 8.2 and conventional forms 1C

By default, regular 1C forms are used in configurations for a thick (regular) 1C client, and managed forms are used in configurations for a thin and web 1C client. However, both forms of 1C can be used in any configuration, including simultaneously.

To do this, you must also enter the configuration properties (the top element in the configuration window).

In the configuration properties in 1C 8.2, two new checkboxes have appeared that allow you to enable non-standard use of 1C forms.

Creating Managed Forms 8.2

Adding a new form 1C 8.2 is done in the same way as before - using the Ins button on the keyboard or the Add button. To enter an existing one, double-click on it with the mouse.

By default, the form (regular or managed) that is set in the configuration will be created (see the Main launch mode property in the configuration properties). forms.

The constructor will prompt you to choose the type of form - the form of an element, a list. Here you can add or remove command bars on the form. Most often, these settings are left as is, by default.

A form filled out by default opens - all the details of the 1C object that are added to it. You can tick off a specific list of required fields on the second tab of the constructor.

The form editor consists of three sections.

In the upper left corner is a list of form elements. It consists of fields, commands, and groups that allow you to combine items. The list of commands can be viewed separately on the Command Interface tab.
In the upper right corner there is a list of available form attributes and object attributes (open the cross next to the Object attribute).
Below is a preview of the resulting form.

You can drag the available details to the left and it will become a form element (a field on the form).

If you need to add a button or menu item - on the right side of the Commands tab, you need to create a new Command. This is a wrapper for a function in a form module. In addition to specifying which function will actually be called, you can assign a representation - for example, a picture, as well as the dependence of visibility on a functional option.

Commands are also dragged to the left. If the parent is a command bar, then it will be a command bar button - otherwise just a button.

In the list of form elements (fields), you can not only drag the attribute of the object/form, but also simply add it (button Add or Ins). In particular, you can create a new form object - a Group.

The group can be a command panel (the cursor must be on the Form line). Then you drag commands into it and they become buttons.

The group can be "regular". Then it's a way to group fields both vertically and horizontally. The name of the group can be removed in the properties.

The group can be a panel (pages). The top added group is a panel, and nested groups of this type are pages. Fields are already being dragged onto the pages.

Unnecessary form elements are removed by deleting the form elements in the list.
The position of the field on the form is determined by the order in the list of elements (vertical) or by groups (horizontal). The width and height are set in the properties of the form element.

The form element properties have been greatly expanded and contain a lot of useful things - both appearance control (choice and clear buttons), and checking default values.

The properties of the form itself, including its dimensions, are set at the root element of the form with the same name Form.

Event handlers (response to user actions) are now divided into two types. Old ones - as before, they are specified in the properties of the form and fields (for example, OnChange and OnOpening the form). New - have become commands and are used for menu items and buttons.

From platform version 8.2, 1C began to use new principles for building the interface and user interaction with the database. The new technology is called Managed Application. The mechanisms for constructing forms and the scheme of interactions between the user of the 1C server and the database have undergone the greatest processing. The normal mode is still supported by the platform, but over time, all 1C users will switch to managed forms.

For ordinary users, the managed form of the 1C document differs from the usual one only in appearance. For the developer, this is a new mechanism with its own rules, laws and conditions. Many areas have undergone a change, but the following innovations are considered key among experienced 1C developers:

Independent formation of the form structure and placement of fields by the platform. If earlier developers described the position of the field by specifying pixels, now it is only possible to specify the type of grouping;
The form consists of attributes representing the form data, and commands - procedures and functions performed;
The form code is executed on both the server and client sides. After all, the form itself is a configuration object created on the server and displayed on the client. This means that it combines the client and server parts;
On the client side, many types of data have become unavailable and now there is no way to change the data in the infobase;
For each procedure or function, a special setting must be specified - a compilation directive. It is responsible for the place where the code is executed and can take the following values:
- on the client;
- On server;
- On ServerWithoutContext;
- OnClientOnServer;
- On Client On Server Without Context.

The last point is especially acute in the managed forms mode. If a developer is not well versed in directives or client-server interaction, then it will be extremely difficult for him to create a managed form. All new principles for building managed forms in 1C:Enterprise 8.3 are united by the general concept of a three-tier architecture. It includes client computers, a 1C server and a DBMS where data is stored.

Editing a managed form in the configurator has also become different. Many aspects have changed and the developers of version 7.7, where there were no managed forms, may be surprised. Even the appearance of the form designer has changed, which can be seen by opening any of the forms of the configuration object. When opening an object, we see a window divided into several sections:

Form interface elements. At the top left there is a window that lists all the fields displayed on the selected form, which ensure the interaction of the program with the user;
Form details. At the top right are all the data that the form works with. It is in them that information is stored on the client side;
Displaying a managed form. Below we see a preview of the look based on the interface elements;
Form module. A section that contains the procedures and functions used by this form. Here you can find the code of algorithms for the interaction of the program with both the user and the database.

1C developers are agitating clients to switch to managed forms, so learning the principles of developing managed forms is a matter of time. Starting to work with this type of form, you will understand that this is a step towards standardization of development and compliance with uniform rules. Therefore, the ability to work with managed forms in 1C 8.3 increases your level as a 1C developer.

Guidelines for Designing Managed Forms

First of all, to understand the mechanism of 1C managed mode, you should remember that the form exists both on the server and on the client. Moreover, on the client, this object is only an image of the user interaction interface with the program. All calculations, algorithms, calculations and processing must occur only on the server side. This is dictated not only by the inability to use many functions and parameters on the client, but also by the performance requirements.

You can figure out where the procedure is performed by the name of the directive, which must be written before each procedure and function in the form module. The wording "Without Context" indicates that the data on the managed form will not be passed to this procedure on the server. Thus, in such procedures, it will not be possible to write algorithms based on the values entered by the user. If this wording is not specified, then the form is transmitted in its entirety with all the details, and you can access them.

1C developers strongly recommend using non-context server calls, reducing their number as much as possible and trying not to perform calculations on the client. It is difficult for novice developers without theoretical background to comply with all these rules and change the code correctly. Before you start working on your own, it will be useful to open a managed configuration form, look at the syntax and how the client and server interact.

&НаСервере Процедура ПолучитьПлатежноРасчетныеДокументыИзХранилища(НовыйАдресВХранилище) &НаСервереБезКонтекста Функция ЕстьРасчетыСКлиентом(ДокументОснование) &НаСервереБезКонтекста Процедура ЗаполнитьСписокВыбораКПП(СписокВыбора, Контрагент, ДатаСведений) &НаКлиенте Процедура ЗаполнитьГоловногоКонтрагентаЗавершение(ВыбранноеЗначение, ДополнительныеПараметры) &НаСервере Процедура УстановитьТекстПлатежноРасчетныхДокументов() &НаСервере Функция ЕстьЗаполненныеИсходныеДокументы()

The new rules for developing 1C forms will be of great benefit if all developers adhere to them. Moreover, everyone will feel the changes for the better - both programmers, and companies working in 1C, and franchisees, and 1C developers. The main consequences of the correct operation of managed forms in 1C:

Ease of configuration maintenance and increased code readability. From this we can conclude that an algorithm written by one developer can always be corrected by another employee without spending a lot of time;
Separation of code running on the client and server. Given how different the functionality available on each of these sides is, separating them would be the right move;
Developers have a deeper understanding of platform logic, client-server interactions, and the algorithms they write. In versions 8.0 and earlier, it was very common to find forms of documents or directories developed without understanding the client-server part;
Increasing the speed of configurations and reducing the load on client computers;
Reducing the cost of purchasing computers for workplaces due to the absence of the need to purchase powerful PCs.

The choice of a managed form as the main 1C launch mode can bring many surprises. But with the right approach, this step will bring big dividends, so more and more 1C users throughout Russia decide on it. Taking into account the fact that the 1C company is counting on the development of managed forms in the future, it is risky to stay on obsolete conventional ones.

1c 8.3 managed form events. Under the Hood of Managed Forms