Object 1c "Functional options" - designed to highlight the functionality in the application solution that can be enabled (disabled) during implementation without changing itself (together with the Subsystems, they form the 1C thin client interface). They are part of the functional options mechanism.
Function Options Mechanism includes two metadata objects:
- Functional option;
- Functional options parameters.
More
Function option is a metadata object that can directly affect the composition of the application interface (if the functional option stores its value in a Boolean attribute). With the help of objects of this type, you can hide elements that relate to inaccessible functionality. For example, the Currency accounting option can hide Currencies, the Currency from field, the Currency amount column from reports.
The source of the value of the functional option is the metadata object selected as the property Storage , for example, it can be .
In the case of storing the value of a functional option in a directory attribute or resource, additional information is required that indicates exactly how to select the option value. A separate metadata object is provided for this purpose − Function Options Parameters.
We can say that the parameters of functional options are the coordinate axes of the space of values of functional options. Moreover, one parameter of functional options can determine the value of "its" coordinate axis simultaneously for a plurality of functional options.
[hide]
Functional options may affect:
- to user interface:
- global ;
- requisites (including columns of requisites of the form such as Value Table or Value Tree);
- form commands;
- on reports implemented using a data composition system;
- on algorithms written in the built-in language - it is possible to get the values of functional options from the built-in language and use them in various conditions, for example, to reduce the amount of calculations (see, for example, ).
ATTENTION! If the client application works with the file version of the infobase through the web server, then changing the functional option will change the user interface only after restarting the web server (restarting the client application will not change the user interface).
Properties of 1C Functional Options
- Storage - a field in which you need to select an object with the boolean type. As a rule, constants are used.
- when getting - the flag is responsible for the possibility of obtaining the value of the functional option in the privileged mode.
- Composition - a list of objects and attributes of objects, the visibility of which is turned on / off when the functional option is turned off / off (to be controlled using a managed form).
For example, depending on the conditions of a specific implementation, you can provide for disabling accounting for goods by warehouses so that when registering goods receipt documents, the Warehouse field is not displayed in the document form.
Features of using 1C Functional Options:
- Function options can have values of arbitrary type (not necessarily Boolean).
- When adding a new constant to use a functional option, be sure to include it in the appropriate subsystem and assign permissions to it.
- Working with functional options is available from the built-in language, thanks to which the developer can create his own algorithms for the values of functional options.
- The command interface command will be excluded from the command interface if the function option is disabled:
- attribute, which is a command parameter;
- the type of the command parameter (if the type of the command parameter is compound, then the command becomes unavailable when all parameter types are disabled).
ATTENTION! Functional options and their parameters do not affect the composition of the database: all tables and fields are present in the database, regardless of the state of the functional options.
Influence of functional options on the details and commands of the form:
- managed form type<Вид>An object ( DirectoryObject, DocumentObject, etc.) will be disabled if the corresponding object is disabled by the functional option. Only those functional options that have no parameters are parsed.
- The main attribute of the type managed form DynamicList will be disabled if the functional option disables the configuration object that is specified as the main table of the dynamic list. Only those functional options that have no parameters are parsed.
- A form attribute of a reference type is disabled if the configuration object that forms that type is disabled by a functional option. The form attribute of a composite type is disabled if the functional options disable all component types.
- The form table will be disabled if it displays the data of a form attribute disabled by a functional option.
- There are no types in the type selection dialog (for example, for input fields associated with attributes of a composite type) if the configuration objects that form these types are disabled by a functional option. Information about types disabled by functional options is cached on the client side and cleared after 20 minutes or during a method call UpdateInterface().
ATTENTION! Unlike the command interface, the parameter values of functional options are set only for a specific instance of the form.
Creating a Functional Options Parameter
The functional option parameter is created using the 1C configuration object "Functional options parameters".
[hide]
This can be done in the configuration window by adding a new object.
Function Options Parameter Properties:
- Usage - sets a set of objects whose values will determine how the value of the functional option should be selected. The list of available objects includes dictionaries and dimensions of the information register. For each parameter of functional options in this list, you can select one directory (from the entire list of directories) and one dimension of each information register.
ATTENTION! You cannot use the same metadata object in more than one function option parameter.
With the release of the 1C:Enterprise 8.2 platform, a new object appeared in the configuration tree - "Functional options". It is actively used in all standard configurations based on managed forms, and serves to simplify the process of displaying individual attributes, objects in the interface. For example, in your configuration there is a module for exchanging with external web services. This module uses a number of details in documents, registers and individual components in subsystems. The module is optional and not required by every company. It is logical, since not everyone needs the module, then it is also not always necessary to display all the elements / fields associated with it.
In older versions of the platform, solving such problems required writing additional code that had to be called in all dependent sections. For example, if we needed to hide certain form details (depending on the value of a setting), then we needed to call the appropriate code when opening the form. It was not very convenient and in most cases the developers gave up on such things.
Well, if you want to hide only the fields in the form of documents, but we can still have forms of registers with which user interaction is also possible. Writing a generic display control function is quite difficult and will require extra time, which is never enough.
Functional options are designed to solve this and many other difficulties associated with the display of interface elements / composition of available objects in the user interface. In this note, I will not consider examples of the use of the main purpose of functional options, but will pay attention to their use in a not quite standard way. Perhaps it is familiar to many advanced developers, but I came to this method quite by accident. More precisely, it was inspired by the practice of programming in JavaScript.
Case #1: functional option as a wrapper over other objects
The first non-standard feature of functional options is the ability to create wrappers. Consider the simplest example - constants. For example, you add a new constant to a configuration with a huge number of user roles. In order for users to access the value of the constant, you need to set the corresponding roles to read permissions. If the rights are not set, then users will not be able to get its value. If there are many roles and they are not inherited from the base role, then you will have to spend time checking the appropriate boxes.
The functional option can solve this problem more elegantly. The idea is as follows: we create a constant (for example, ). We do not assign rights to it. We create a functional option of the same name and specify it in the property "Storage" specify a constant "Ability to Save Data". We also set the flag "Privileged Mode on Receive".
That's it, now in any place in the code where you want to refer to a constant, we write like this:
Since we set the option to privileged mode, no additional rights need to be specified for the constant. Of course, it is not necessary to apply this technique in all cases of conceivable and unthinkable situations. Remember, a competent arrangement of rights is the key to peace of mind. Use the trick only when absolutely necessary.
Case number 2. Additional level of abstraction
I don’t know how to properly call this method, but in my opinion it sounds exactly like that. Consider the previous example. We still have the same constant “Ability to save data”. We work with it using the functional option of the same name as a wrapper.
Now imagine that we wanted to get rid of the constant and switch to using a reference book. A typical scenario for solving such a problem (if we use only a constant) would be to run a global search tool in order to find a reference to the constant. Let me remind you that if we do not use a functional option as a wrapper, then we must refer to a constant like this:
Constants.DataSaveAbility.Get();
We find all the calls and replace it with the path to the new storage object. Agree, it's pretty inconvenient. If we used the previous case (using a functional option as a wrapper), then to “move” we only need to go to the properties of the functional option and change the property "Storage". For example, put there "Directory" or "Register of Information". No games with a global search are required. The code for accessing the value of a constant through a function option will remain the same:
GetFunctionOption("DataSavePossibility");
Functional Options is one of the new features of the 1C:Enterprise 8.2 platform. The meaning of their use lies in the fact that they allow you to customize the user interface in accordance with the settings of functional options, set the visibility of details in forms. In addition, the developer has the ability to implement program code, the execution of which depends on the state of the functional option.
Let's create a functional option that allows you to enable and disable payroll maintenance in the configuration. With its help, we can quickly hide those parts of the interface that are related to solving computational problems. A function option by itself does not store any value that allows it to be enabled or disabled. Usually, a constant is used to store the state of a functional option, although it can also be bound to another object, for example, to an attribute of some object.
Let's create a new constant and call it AccountingSalary, type - boolean. Let's include a constant in the subsystem Administration and into the constants form so that we can edit it. In addition, in the form of constants, we will set the AfterWrite handler of the following form:
&At the Client Procedure AfterWrite(WriteParameters) UpdateInterface(); EndProcedure
The meaning of using the command UpdateInterface() is to update, redraw the interface after the change of the constant associated with the functional option takes effect. Otherwise, in order for the changes to take effect, you will have to restart the configuration.
Let's create a new functional option, call it AccountingSalary, on the tab Main, in the parameter Storage we indicate the newly created constant, fig. 7.23. Include a functional option in a subsystem Administration.
Rice. 7.23.
Now let's go to the tab of the functional option settings window Compound and select everything (Figure 7.24) that relates to payroll. If any objects, for example, directories, refer to different parts of the configuration, we will not mark them, otherwise, when the functional option is turned off, they will "disappear" from the interface.
Rice. 7.24.
Subsystem selection Payroll preparation in this case does not lead to automatic selection of all objects included in the subsystem. When choosing, we only mean hiding or showing the command interface section Payroll preparation.
By running the system in user mode, we can enable and disable the visibility of objects related to the payroll subsystem of our configuration by simply setting or unchecking the flag of the constant AccountingSalary.
More difficult use case functional options is to set the visibility of individual form elements in the event that the value of the functional option is stored in the attribute of an object.
We will make changes to the configuration, in particular, to the directory Individuals add a boolean attribute Has Experience in Human Resources and place it on the form of the directory element.
Function Options is a metadata object located in the "General" group:
Functional options are part of the mechanism of functional options that allow you to enable or disable some functionality in the application solution depending on the user's needs, without modifying the configuration itself.
For example, not every organization can use inventory control. If warehouse accounting is not used, then it makes sense to remove the warehouse field in all documents, directories and registers - then functional options come to our aid.
Let's look at an example:
Let's create a functional option " Warehouse Accounting".
Storage: the field storing the value is specified.
You can select a constant, a directory attribute, or an information register resource.
We will use a constant.
Let's create a constant " Keep AccountingIn Warehouses" and select it in the storage field. This constant will be responsible for enabling and disabling the functional option. Set the checkbox "Privileged mode when receiving". This checkbox means that the values of the functional option will be received in privileged mode:
We are updating, launching 1C Enterprise. Set the value of the constant = True:
As a result, we have:
When setting the constant = False, we get:
Do you have a question, do you need the help of a consultant?
So, we have created a functional option that manages fields of the DirectoryLink.Warehouse type
Let's now look at an example of using function options parameters.
Let's add a new functional option " Currency accounting"
Storage: Directory.Organization.Props.Currency Accounting
Let's add to the composition the details of the document "Set item prices" - "Currency"
In the form of a Document in the procedures "On CreationAtServer" and "OrganizationOnChange"
Let's add the following code:
Update the configuration and run it.
We create two Organizations and for one of them we check the box "Currency accounting"
What do we get as a result? As a result of using the parameters of the functional option, you and I received parametric control of the "Currency" field in the "Set item prices" document. Those. for the Alpha organization, the Currency field will be displayed, and for the Beta organization, the Currency field will not be displayed.
Let's make sure of this. Open the document and try to change the "Organization" field
When setting org="alpha", the currency is displayed; change to "Beta" - the currency is removed
Print (Ctrl+P)
1. Purpose of functional options
Functional options allow the developer to describe the capabilities of the application solution, which can be quickly enabled or disabled at the implementation stage and/or during system operation. For example, the ability to work with additional product properties can be separated into a separate functional option. Then, if you disable this feature, all related (with additional product properties) features will “disappear” in the interface of the applied solution.
The system is able to automatically take into account the state of the settings made - hide disabled features, making the application interface more clear and understandable to the user.
During development, situations arise when the value of a functional option should depend on certain parameters, for example, not all organizations maintain currency accounting. To implement such a dependency, use the Parameters of functional options - objects that parameterize functional options.
2. What functional options affect
2.1. general information
Functional options may affect:
● On the user interface - when you turn off any functional options, the system hides all elements related to it in the user interface. This affects the following interface elements:
● global command interface;
● form attributes (including form attribute columns of the ValueTable or ValueTree type);
● form commands;
● reports implemented using the data composition system.
ATTENTION! If the client application works with the file version of the infobase through the web server, then changing the functional option will change the user interface only after restarting the web server (restarting the client application will not change the user interface).
● Algorithms written in the 1st language – it is possible to get the values of functional options from the 1st language and use them in various conditions, for example, to reduce the amount of calculations.
ATTENTION! Functional options and their parameters do not affect the composition of the database. All tables and fields are present in the database regardless of the state of the functional options.
2.2. Global command interface
The effect of functional options on the global command interface is that the system hides the commands of all objects related to disabled options. For example, if the value of the Purchases functional option is set to False , then the commands for opening the Purchases section, creating a Goods Incoming document, opening the Goods Incoming list, etc. will be hidden.
In turn, the Purchasing option can take into account the value of a functional option parameter, for example, Organization. By changing the value of this parameter using the methods of the built-in language, it is possible to change the state of the functional option, and, consequently, the visibility of the interface element.
You should also consider the following features of the formation of the command interface:
● The command will be excluded from the command interface if the attribute, which is a command parameter, is disabled by a functional option.
● The command will be excluded from the command interface if the command parameter type is disabled by a function option. If the command parameter type is compound, then the command becomes unavailable when all parameter types are disabled.
2.3. Form
In a form, functional options can affect form attributes and commands and (as a result) change the visibility of associated form elements (fields and columns for form attributes, buttons for form commands). When developing a form, the following features of the system behavior should be taken into account:
<Вид>An object ( DirectoryObject m, DocumentObject, etc.) will be disabled if the corresponding configuration object is disabled by a functional option. Only those functional options that have no parameters are parsed.
● The main attribute of the type managed form DynamicList will be disabled if the functional option disables the configuration object that is specified as the main table of the dynamic list. Only those functional options that have no parameters are parsed.
● The form attribute of a reference type is disabled if the configuration object that forms this type is disabled by a functional option. The form attribute of a composite type is disabled if the functional options disable all component types.
● Disables form type props<Вид>An object (including the main form attribute), if the configuration object that constitutes this type is disabled by a function option. Only those functional options that have no parameters are parsed.
● The form table will be disabled if it displays the data of a form attribute disabled by a functional option.
● There are no types in the type selection dialog (for example, for input fields associated with attributes of a composite type) if the configuration objects that form these types are disabled by a functional option. Information about types disabled by functional options is cached on the client side and cleared after 20 minutes or during a method call UpdateInterface().
ATTENTION! Unlike the command interface, the parameter values of functional options are set only for a specific instance of the form.
2.4. Data composition system
The data composition system is mainly used for building reports. Functional options affect the composition of the data that is displayed in the report, and the composition of the report settings available to the user. For example, if the functional option is disabled Currency accounting, then in the report that displays the register of documents Goods receipt, there will be no column Currency and Currency amount, and in the settings there will be no possibility of selection, grouping, sorting, etc. by the field Currency.
2.5. Characteristics
Functional options affect the visibility of form fields that display the value of an object characteristic. To do this, it is necessary to include in the functional option an attribute that stores the value of the characteristic.
Consider an example. Characteristics are used for the Goods directory, types of characteristics are stored in the plan of characteristic types Characteristics, and values are stored as a resource of the information register ValuesCharacteristics. The resource is part of the functional option AccountingCharacteristics.
Rice. 1. Effect of functional options on performance
In case of deactivation of the functional option AccountingCharacteristics in the forms, the visibility of the fields (column Value and field Value ), displaying the values of characteristics, is turned off, as shown in Fig.1.
3. General scheme of work
The functional options mechanism includes two types of metadata objects: Function option And .
A functional option is a metadata object that can directly affect the composition of the application interface (if the functional option stores its value in an attribute of type Boolean ). With the help of objects of this type, you can hide elements that relate to inaccessible functionality. For example, the Currency accounting option can hide the Currencies lookup, the Currencies field from documents, the Currency amount column from reports. The source of the value of the functional option is the metadata object selected as the Storage property, for example, this
may be a constant.
If the value of a functional option is stored in a directory attribute or information register resource, additional information is required that indicates exactly how to select the option value. A separate metadata object is provided for this purpose − Function Options Parameters.
We can say that the parameters of functional options are the coordinate axes of the space of values of functional options. Moreover, one parameter of functional options can determine the value of "its" coordinate axis simultaneously for a plurality of functional options.
Rice. 2. Parameterizable functional option Consider an example: let's say total accounting depends on a warehouse owned by a particular organization (see Figure 98). In our information base
you can keep records on behalf of different organizations and in different warehouses.
To store the values of functional options, we will create a register of information, where the dimensions (coordinate axes) will be:
● Organization (appropriate type);
● Warehouse (appropriate type).
The resource of the information register will be the value of the functional option of total accounting.
Then the general structure of the configuration will look like this:
● Information register Sum Accounting:
● Organization dimension;
● dimension Warehouse;
● the resource Total Accounting of the Boolean type.
● Functional options parameter Organization . The Usage property points to the dimension Organization of the information register SumAccounting.
● Functional options parameter Warehouse . The Usage property points to the Information Register Warehouse Sum Accounting dimension.
● Functional option Total Accounting. The Storage property points to the SumAccounting information register resource SumAccounting.
As a result, in order to determine the need for total accounting, we need to specify the values of the parameters of the functional options (Organization and Warehouse) in each specific case and get the value of the functional option.
So, in the example shown in Fig. 2, for Organization 1 and Warehouse 1, total accounting is allowed, and for Organization 2 and Warehouse 1, total accounting is prohibited.
4. Interaction with other objects
Functional options can be assigned to the following configuration objects:
● Subsystems,
● General commands,
● Common shapes,
● Constants,
● Selection criteria,
● Handbook,
● Document,
● Magazine,
● Chart of accounts,
● Plan of types of characteristics,
● Plan of settlement types,
● Business process,
● Task,
● Exchange plans,
● Report,
● Processing,
● Accumulation register,
● Information register,
● Accounting register,
● Calculation register,
● Team,
● Attribute of the metadata object,
● Tabular part,
● Details of the tabular section,
● Sign of accounting,
● Subconto accounting sign,
● Addressing details,
● Register measurement,
● Register resource.
Also, functional options can affect the visibility of form elements.
5. Creation
5.1. Creating a functional option
In order to create a functional option, you need to create a configuration object Functional option. This can be done in the Configurator mode in the usual way, that is, in the configuration window, select the General item, then Functional options and add a new object.
Rice. 3. Creating a functional option This will create a Functional Option configuration object that can be used to assign functional options to other metadata objects.
Rice. 4. Storing the value of a functional option In addition to the name, the object has a mandatory property - Storage. In the editor, you can select one of the objects for it, which will be the source of the option value. The list of available objects includes:
● constants,
● details of directories,
● information register resources.
There is no restriction on the source type of the option value, but only those functional options that store their values in attributes of the Boolean type are suitable for interface control. Function option values with other types are only available for parsing in 1C:Enterprise.
The Privileged Mode on Get property determines how the function option value is retrieved (and cached).
Rice. 5. Privileged mode when getting the value of a functional option If this property is set, then the value of the function option is obtained in privileged mode. The resulting value is cached for all sessions associated with this infobase.
If the Privileged Mode on Get property is cleared, then getting the value of the functional option is done in normal mode.
Caching is done for the current session. Both the value (if it was possible to get it) and the sign of the impossibility of obtaining the value (in the event that the value could not be obtained) are cached.
The cache is flushed when session parameter values change.
ADVICE. It is recommended to set the Privileged Mode on Get property for all cases where the value of a functional option does not contain sensitive information.
5.2. Creating a Functional Options Parameter
In order to create a functional option parameter, you need to create a configuration object Function Options Parameters. This can be done in the Configurator mode in the usual way, that is, in the configuration window, select General, then Function Options Parameters and add a new object.
In addition to the name, the parameter has the required Usage property. It specifies a set of objects whose values will determine how the value of the functional option should be selected. The list of available objects includes dictionaries and dimensions of the information register. For each parameter of functional options in this list, you can select one directory (from the entire list of directories) and one dimension of each information register.
ATTENTION! You cannot use the same metadata object in more than one function option parameter.
6. Usage
6.1 Assigning metadata to objects
A metadata object (for example, a directory) can be attributed to one or more functional options. To do this, use the Functional options property, which contains links to the functional options created in the configuration.
Rice. 6. Assigning a functional option to an object The list of available options is limited only to those options for which an object with a value type of Boolean is assigned in the Storage property.
ATTENTION! If no functional option is assigned to an object, then it is always considered visible. Otherwise, the object is considered visible if at least one of the function options assigned to it is enabled (i.e., the function options are ORed together).
6.2. Assigning form details and commands
Objects belonging to the form (Attributes and Commands) can also be used in the functional options mechanism.
Rice. 7. Assigning a Function Option to a Command You can do this in the form editor by setting the Functional options property for the required object.
The state of the functional options will affect the display of form objects in the same way as it does with metadata objects.
For example, in the case of a command disabled by a functional option, all buttons associated with it will be removed.
If no functional option is assigned to a form attribute or command, then the form attribute or command is considered always visible. Otherwise, the form attribute or command is considered visible if at least one of the functional options assigned to it is enabled.
6.3. Use in the data access restriction mechanism
Under the conditions of the data access restriction mechanism Functional Options can be used in the same way as Session Options. It is permissible to use only options that do not depend on parameters, that is, those that are bound to constants.
ATTENTION! The system controls the uniqueness of names between session parameters and functional options.
6.4. Determining the Function Option Value
The value of the functional option is determined by the object specified in the Storage property. In the case of a constant, its value is used. For an option associated with a directory attribute or information register resource, the values stored in these objects. In order to find a specific object that stores the value of the functional option, additional information is needed - a set of parameter values of the functional options.
If the option is stored in a directory attribute, the parameter must contain a link to a specific element of the directory. If the option is stored in an information register resource, the values of all dimensions of the register must be specified. In this case, each measurement must be characterized by its own parameter.
If not all parameters are specified for a functional option of the Boolean type, then the addition “by OR” of all values with no parameters is performed. For example, if a feature option is stored in a detail register with dimensions Organization and Warehouse, and only the dimension Organization is specified, then the value of the feature option will be True if at least one of the warehouses listed in the dimension Warehouse has the value of the feature option set to True.
For a functional option that is of type other than Boolean , an incomplete parameterization situation results in an exception being thrown.
The built-in language methods allow you to get the value of the option, both depending on the parameters passed, and for the parameters set
for command interface or specific form. In the case when the change of the value of the object specified in the property of the functional option Storage is performed in a transaction, the actual value of the functional option will be changed only after the completion of the transaction. While the transaction is open, the value of the functional option will be equal to the value that is relevant at the moment the transaction starts.
If a functional option is bound to a periodic information register resource, then the system uses a slice of the latter to obtain the option value. If you want to receive the option value on some other date, you must specify a value for the Period functional options parameter, which has the Date type, which will be used as the date when the slice was received. This parameter does not need to be created in the metadata. It is provided automatically by the system.
When using parameterized function options, the following behaviors should be taken into account:
● In list forms, the attribute column associated with a parameterized functional option will be displayed if the infobase stores at least one enabled value of this functional option.
● If you want the details associated with functional options to be disabled by default when opening the form, then you need to
set the values of these parameters to values that are not in the infobase (for directories - a null reference, for information registers - measurement values for which there are no records). In this case, the function option will have the value False .
● When a group reference is specified as a parameter (if the parameter type of a functional option allows the creation of groups), and not a reference to an element, the behavior of the system will be as follows:
● if the attribute that stores the value of the functional option is used for both the element and the group, then the value of the functional option will be determined by the value of this attribute.
● if the attribute in which the value of the functional option is stored is not used for the group, then when obtaining the value of the functional option using methods GetFunctionOption(), () and () will return NULL . If, parameterized with this value, a function option affects the user interface, the system will treat it as disabled (the function option will have the value False).
● For commanding metadata objects, it is possible to link to a parameterized function option. In the command interface, the commands of such objects will be displayed only if there is at least one combination of functional option parameters, in which the value of the functional option is True . However, using the () method, you can set specific values for the parameters of functional options, and then the visibility
commands will be determined by the specified parameters.
● The dynamic list automatically uses the functional options used by the form. If the attributes used in the dynamic list request are disabled with a given combination of functional options parameters, the data on them will not be selected and displayed in the dynamic list, and the attribute will be removed from the lists of available attributes in the data display settings dialog
dynamic list (in 1C:Enterprise mode).
7. Working with functional options in the built-in language
Global context methods GetFunctionOption() And GetFunctionInterfaceOption() return the value of the function
options. The difference between them is that the first method allows you to specify a set of functional option parameters, and the second method returns the value of the functional option based on the parameters specified for the command interface. The form has its own method that returns the value of the option for the parameters specified within the form − GetFunctionOptionForm().
To update the global command interface, explicitly call the method SetInterfaceFunctionOptionParameters().
The command interface will be updated to reflect the new state of the functional options.
NOTES F. If the value of a functional option changes in the database, then the global command interface and the forms that are open at that time are not automatically updated. To do this, use the method UpdateInterface() after writing the values of the functional options to the database.
It should be remembered that setting the parameters of the functional options (and executing the method UpdateInterface()) leads to the following consequences:
● for each form, all auxiliary forms are closed (with the corresponding handlers being called);
● forms that refuse to close are not closed;
● the content of the main form elements is updated;
● if the main form was the active form at the time of the interface update, the main form is displayed in accordance with the new set of elements;
● if an auxiliary form was the active form at the time of the interface update, then:
● the command to open an auxiliary form will be executed if it is available after updating the interface;
● otherwise, the composition of the main form elements is updated and its display is performed;
● if at the time of updating the interface, the active form was an auxiliary form opened with a command that is not related to the form's navigation bar, then instead of this form, the content of the main form elements will be updated and displayed.
To update a particular form, either reopen it or call the SetFormFunctionOptionsParameters(),
at the same time, the sequence of actions described above works only for the form in the context of which the setting of the parameters of the functional options of the form is called.
Parameters do not have to be specified all at once, you can change the value of a particular parameter or set of parameters selectively. But it is the group setting of values with one call that is more efficient.
To get the parameter values, you need to call the corresponding function ( GetInterfaceFunctionOptionParameters() or
GetFormFunctionOptionsParameters()), which will return the set parameters as a structure, where the parameter name will be the key.
When opened, the form automatically uses the parameters of the functional options set for the command interface.
