Getting the data displayed by a dynamic list
In addition to primitive data types that can be found in any programming language, there are unique types in 1C. Each of them has its own properties, methods, functions, purpose and nuances of use in the system. One of these types is a dynamic list, which greatly facilitates many applied tasks. That is why developers must know and be able to handle this universal tool.
Features of dynamic lists in 1C
The purpose of this type is to display information from any database tables, regardless of its type. The mechanism was created on the basis of SKD and has similar capabilities. But this does not mean that you will necessarily have to write a request in the 1C language, although this opportunity exists and should be used. You can simply specify the table whose information interests you and 1C will independently generate a simple query.
To see how a dynamic list is formed and what data it shows, you need to open the managed forms where it is located in the configurator: in the list of details, use the context menu to open its properties and pay attention to the “Custom Request” item. If there is no checkbox, then the “Main table” parameter reflects the database table from which the data is taken. Otherwise, the dynamic list reflects the data of a custom query, which can be seen by opening the list settings.
The custom query scheme is much more commonly used, as this provides an excellent opportunity to combine and display a wide variety of data. Most often, this mechanism is used to reflect warehouse balances, item prices, receipts, expenses or purchases. You need to use it carefully, as performance may drop for complex queries.
Another useful property of a dynamic list opens when you click on the “List Settings” inscription. This menu allows you to make information more accessible and understandable to end users, even when using a standard set of fields. Regardless of whether the request is arbitrary or not, you will see the “Settings” tab, where you can specify:
- Dynamic list selection;
- Groups;
- Sorting;
- Decor.
The use of parameters makes dynamic lists universal and quite flexible. You can also link them to details on a managed form, and the data will change depending on the parameters selected by the user. The use of these mechanisms can be understood and appreciated by considering examples of real-life problems.
As an example, consider the task of reflecting the remains of nomenclature on a controlled form. In real practice, such orders occur quite often in various configurations, and a dynamic list is ideal as a tool. For this task we will have to use a custom query, dynamic list parameters and its settings.
For greater clarity, let's create a separate external processing and place a dynamic list on it. To implement our plans, the table with the nomenclature will not be enough, so we need to allow an arbitrary query. In it we will describe the left connection of the directory with the list of items and the register of balances and set the directory as the main table. This scheme will allow users, working with a dynamic list, to add or change items.
Since our request used the “CurrentDate” parameter, we need to set its value before using processing. To do this, in the form module in the “When CreatedOnServer” procedure, using a standard command, assign it the “CurrentSessionDate” function. We also need to display the dynamic list on the control form and change the order of the fields for clarity. Drag the “Nomenclature Remaining” attribute into the form elements (upper left part) and use the blue arrows to change the order of the fields in the table on the form.
&On the Server Procedure When Created on the Server (Failure, Standard Processing) Nomenclature Remains. Parameters. Set ParameterValue("CurrentDate", CurrentSessionDate()) EndProcedure
Already at this stage, we can open our external processing in 1C and see that the dynamic list is working. We can look at balances, create items and groups, and search. Often customers ask to add the ability to choose the date on which they will see balances. In the case of a form with a dynamic list, this is achieved through an additional field and setting parameters using it.
Add the “DateRemaining” attribute of the “Date” type and transfer it to the form elements. In the field events, we create the “OnChange” event and write the code for setting the “CurrentDate” parameter used in the dynamic request. So that when opening the form the user immediately understands on what date he sees the balances, we will make small changes to the “When CreatedOnServer” procedure.
As a result, our Dynamic List form can reflect balances as of any date.
We have considered only a small part of the capabilities of this toolkit, but this is already enough to understand the convenience of this type of dynamic list. A similar mechanism is used for many tasks, but it is most often found in typical configurations in managed forms:
- Selection;
- Lists.
To receive a dynamic list and its request in standard managed forms, the developer needs to open the desired form in the configurator. In the details section, find the details with the “DynamicList” data type (most often it is highlighted in bold). Its properties contain the request text, selections and other settings.
Platform 1C:Enterprise 8.2 can work with many records in a database table in a dynamic way, that is, read data in portions. Previously in articles we looked at the mechanism of dynamic lists and methods for optimizing work with them.
Today we will solve a non-standard problem for dynamic lists. We will need to calculate the total using the “Amount” document attribute and display it in the footer of the list. Similarly, calculate the average value for the "Rating" field and also display it in the footer of the dynamic list. The calculation of the total fields must take into account the selection set by the user in the document list settings.
The whole difficulty lies in the fact that a dynamic list does not receive all entries at once, but receives them in portions. Accordingly, we cannot immediately obtain a summary of all documents corresponding to the current selection. How to calculate the total?
Implementation
And so, let's move on to solving the problem. Let's start with changing the form, then we will describe the algorithm for obtaining the final values.
Form and interface
First, let's prepare a document form to display the resulting fields. To do this, add two string details of the form “Rating” and “Amount”.
The total values for the documents will be recorded in these details.
To display the values of details in the footer of a dynamic list, you must enable the corresponding option for the associated element of the list form (see the following screenshot).
Now you need to decide on what event the results in the list footer will be updated. For ease of development, let's add the "Update" command and the corresponding form element to the command panel. When this command is executed, the totals will be updated.
In the test configuration, which you can download from the link at the end of the article, I also added a summary update event when recording a document. In this case, the form notification mechanism is used. We will not dwell on this in more detail.
Algorithm
The most problematic part remains - you need to get the total values. Let's proceed as follows: we will form a request to the database to obtain the values of the final fields in accordance with the selection set in the dynamic list. It is worth considering that the selection may have a complex condition from groups.
Note: the settings for dynamic lists (see screenshot above) are based on the mechanisms of the data composition system (DCS). Accordingly, you can work with them in a similar way (programmatically adding, changing, reading, etc.).
The stages of forming a request to obtain results are as follows:
1. We receive the initial request for the dynamic list.
 |
As we can see, the request selects all document details. To add a little more complexity, I added my own “Rating Level” field, generated by the “SELECT” construct.
2. We form the text of the request conditions (section “WHERE”) and substitute it into the original request.
We need to add conditions to the received source request text in accordance with the configured dynamic list selection.
The procedure, depending on the type of the passed selection element (group or selection element), generates the corresponding condition text. All conditions in a group are surrounded by parentheses, and those included in the group are also surrounded by parentheses. The conditions between expressions depend on the parent group (an “AND” condition is placed between the top elements in the hierarchy).
If an element has a usage flag set (the "Usage" property), then the element is processed. The generated text also depends on the comparison condition (Equal, not equal, in a list, etc.). The dependence of the generated condition text on the type of comparison can be seen in the following function.
Another interesting function, in my opinion, is “GetFieldTextByView”. It is needed in order to substitute fields that are formed by query language expressions into the query conditions. Above, I added the “Rating Level” field to the original request. If the user uses it in selection, then the entire expression must be substituted into the query condition. This function gets the field text from the request based on its representation. For such complex fields, it will return the entire text of the expression.
For more details on the algorithm, see the test configuration attached to the article. Below is a screenshot of the selection settings and the request conditions generated for them.
The generated condition text is appended to the original dynamic list request. The result of the query is placed in a temporary table.
3. We place the first query in a temporary table and perform grouping by summary fields with the necessary aggregate functions.
Let me remind you that we need to get the average value for the “Rating” field and the total amount for the “Amount” field. We have already generated a request taking into account the selections; all that remains is to calculate the total values. This is done with the following request:
After executing the request, we process the resulting result, return it to the client and write it into the form details that we created earlier. Ultimately, we got the results displayed in the footer of the dynamic list (see the first screenshot in the article).
Optimality of the solution
In general, this approach can have a negative impact on performance. For example, if the program calculates the total without a set selection in a dynamic list, then the number of selected records can be huge (for example, over several years). As a result, each update of the results can last tens (!!!) seconds. Therefore, it makes sense to calculate the results only if selection has been established. I set these conditions in a test configuration.
Plus, we can only calculate the totals and request on the server side. Therefore, you need to approach the server seriously, since the procedure for updating the totals can be performed very often. Imagine a cash register receipt journal in a trade organization, where up to 5 receipts can be entered per minute, and up to 300 receipts per hour. Each time a document is written, the totals will be updated. Therefore, it would be reasonable to reduce the transmitted traffic by using out-of-context procedures.
The following screenshot shows the program code for calling an out-of-context server function that returns totals.
The first parameter is passing the dynamic list selection, the second is a structure of the type “SelectionFieldNameSelectionFieldValueType”. Please note that the first parameter in the function is obtained as its own value. I can’t say exactly why, but if you pass the selection as a link, the platform gives an error stating that the selection cannot be changed. The error was circumvented only in this way.->
Note: the use of out-of-context procedures allows you to reduce the size of transmitted traffic by several times, since form data is not transmitted to the server, unlike context-sensitive server procedures ("&OnServer" directive).
Conclusion
In conclusion, I will say that this approach to calculating totals in a dynamic list is incorrect from the point of view of development methodology. It would be correct to get the total by registers. For example, in the check journal, again, we can get the amount of money in the current cash register either from documents or from the corresponding accumulation register.
Plus, the use of accumulation registers will allow you to calculate totals without taking into account selection, since the system works optimally with already calculated totals for previous months.
Nevertheless, the method described in the article takes place when solving problems.
Files for download:
Print (Ctrl+P)
Dynamic list
1. General information
A dynamic list is a special data type that allows you to display arbitrary information from database tables on a form. To do this, you need to specify the table from which you want to display data, or describe the resulting selection in a query language.
The mechanism is based on a data composition system and provides capabilities for sorting, selecting, searching, grouping and conditionally formatting the received data. In this case, the data source is a request, which is either generated by the system automatically (based on the specified data) or written manually by the developer.
Rice. 1. Options for creating a dynamic list
When creating form attributes of the type DynamicList a developer can choose two ways to form a data query:
● By specifying the main table - in this case, you just need to specify the table (Main table property) from which you want to receive data, and the system will automatically generate a query for the data (see the right part in Fig. 1).
● Manually generating a request - for this you need to set the Custom request property (see the left side of Fig. 1). After this, manual generation of a request to obtain data from the infobase will be available.
A query can retrieve data from multiple tables, so you can specify a primary table. This is so that the dynamic list can determine which data is primary and which is secondary, and can correctly select and display information, as well as provide standard commands. However, if it is impossible to determine the main table in the query, then it can not be specified, but then
the dynamic list will not provide commands related to the main table. In addition, in this case (without specifying the main table) the efficiency of obtaining data by a dynamic list will be significantly reduced.
To improve performance, it is recommended that any joins used in a custom query only to retrieve additional data be made optional by using a data composition system query language extension.
For a dynamic list, which is the main form attribute, it is possible to set selection values using a form parameter Selection. To do this, it is necessary that the name of the structure property located in the parameter Selection,
coincided with the name of the dynamic list selection field. In this case, the value of the structure property will be set as the right value of the selection element. If an array, a fixed array or a list of values is passed as the value of an element of the Selection parameter of a dynamic list form, then a condition with the In List option is added to the selection, in the right value of which a list of values is placed (to which the array and fixed array are converted).
An arbitrary query in a dynamic list can be a query in which a parameter is used to generate the value of a field, for example:
CHOOSE
CHOICE
WHEN Delivery.Coefficient = 1 THEN &Presentation
OTHERWISE Delivery. Coefficient
END AS Ratio
FROM
Moreover, if the type of the parameter value differs from the type of the object attribute (for example, Props1 has type Number, and the parameter value is type Line), then to display the field correctly, you must explicitly cast the parameter value to the desired type:
CHOOSE
CHOICE
WHEN Delivery.Coefficient = 1 THEN EXPRESS(&Representation AS String(100)) ELSE Delivery. Coefficient
END AS Ratio
FROM
Document.Delivery of Products HOW to Deliver
If the field by which selection is set is disabled using functional options, then selection by such a field is not installed, even if the selection value is passed as form parameters or selection parameter links.
Using the Dynamic data reading property, you indicate to a dynamic list the need to read data in small portions
(for more details about ways to obtain data using a dynamic list and data caching, see below). Regardless of this attribute, the following conditions apply:
● If the view mode is set to hierarchical list, only the data of the current group and the data of all parent elements (without children) will be read.
● If the tree view mode is set, only data from open tree nodes will be read.
● One-time loading of dynamic list data is not supported if hierarchical browsing is set (Display property is set to Tree) and the initial tree display is set to Expand all levels. To obtain data, as many requests to the server will be made as there are nodes in the displayed list.
Within a single data retrieval, a dynamic list reuses previously created temporary tables if the following conditions are met:
● The list batch query has no queries after the main batch query.
● The composition of temporary tables and the fields in them is unchanged from the previous execution of the batch request.
In its work, the dynamic list uses the values of the following properties of metadata object details:
● format,
● editing format,
● hint,
● sign for highlighting negative values,
● mask,
● multi-line mode sign,
● sign of advanced editing,
● password mode.
When displaying and editing the selection and parameters of the data composition system, the editing format of the corresponding field is used.
2. Limitations and features
When setting selection in a dynamic list, remember that selection does not affect groups if the display mode for the dynamic list is Hierarchical List or Tree. By “groups” we mean an element of a directory or plan of characteristic types whose ThisGroup property is set to True.
Qualifications automatically applied by a dynamic list to the standard details Owner, Parent, Date, Period and ThisGroup are applied
using standard data composition system tools. Selection, automatically applied by a dynamic list to key fields, can be applied both by standard means of the data composition system and by directly adding conditions to the request text IN to the fields of the main table. As a result of applying selections using layout tools, they can be applied both in nested queries and in parameters of virtual tables.
When developing dynamic lists, it is recommended to test all dynamic lists with custom queries. During the verification process, you should make sure that if a list query contains nested queries or virtual tables, and in them fields with aliases that match the aliases of the standard details Owner, Parent, Date, Period, ThisGroup or key fields are available for selection, then these fields are valid correspond to the standard details with which their nickname matches. If this is not the case, you should change the request so that they match or
the nickname was different.
If you choose to manually generate a request, then some restrictions are imposed on the request:
● Using the FIRST statement in a dynamic list query is not supported. If you need to use a selection limited by the number of records in a dynamic list, you should rework the request for generating a dynamic list in such a way that the actual content of the request is placed in a subquery and limit the number of records received in this subquery. You can also use a temporary table instead of a subquery.
● Selection, sorting and grouping are not supported:
- According to the details of the tabular parts.
- View fields.
- DataVersion field.
- PredefinedDataName field.
- Chart of accounts table type field.
- Field Type of Movement of the accumulation register table.
- Field TypeValues of the characteristic type plan table.
- Type field Type;
- Field of type String (unlimited length).
- Field of type BinaryData.
● Sorting and grouping by Subconto fields is not supported<НомерСубконто>and ViewSubconto<НомерСубконто>Tables MovementsSubconto of the accounting register.
● Grouping by fields that are query language expressions containing aggregate functions is not supported.
● When the main table is selected, the dynamic list query has the following restrictions:
- Joins are not supported.
- The ORDER BY section is not supported. You should use a query without a main table or set the necessary ordering through the dynamic list settings.
● If a dynamic list is displayed as a hierarchical list or tree, then an entry will not be displayed as a dynamic list unless at least one parent of that entry is displayed. In other words, to display an element of a hierarchical list, a dynamic list must also display all the parents of that element up to the top of the list. In this case, by the top of the list we mean either
the root element of the hierarchical object displayed by a dynamic list, or the element set as the ParentTopLevel property of a form table extension for a dynamic list.
Using the following tables as the main table of a dynamic list is not supported:
● A table that does not have a key that uniquely identifies each table record (a reference for object tables and a record key for register tables). However, the following tables can be set as the main table of a dynamic list (despite not having a key):
● Subconto table of the accounting register;
● all virtual tables of the accounting register, except for the MovementsSubconto table;
● tables of constant values (including the Constants table);
● tables of external data sources without key fields;
● cube tables of external data sources;
● accumulation register tables:
- revolution table;
- balance table;
- table of turnover and balances.
● calculation register tables:
- table of actual validity period;
- schedule data;
- basic data.
● Tables of tabular parts of objects;
● Change registration tables (used in data exchange mechanisms);
● Sequence tables;
● Conversion tables (used in periodic settlement mechanisms).
● A table that is used in a query only in an outer join.
In other words, a dynamic list with the specified main table will work correctly if, as a result of executing the query,
specified as a data source, the number of rows obtained from the main table does not increase (taking into account the imposed selection). If, as a result of executing a query, the number of rows obtained by the query from the main table increases, this will lead to a violation of the uniqueness of the key of the records of the table displayed by the list. In this case, you must disable the use of the main dynamic list table.
When working with a dynamic list, you must take into account access rights to the details displayed by the list:
● Data from dynamic list columns that are marked with the Always Use property, but for which the current user does not have the View right, is not transmitted to the client side. Access to data of such columns (using the CurrentData property and the RowData() method)
not possible on the client side.
● If the current user does not have the View right on a key field of a dynamic list, retrieving data from that dynamic list results in an access violation error.
For a dynamic list that displays an enumeration list, there is no option to interactively customize the list.
The composition of the columns and settings of the dynamic list are associated with the query fields using aliases of the selection fields. If an alias is not explicitly specified in a query for a selection field and the field is a system one, then the field name for the English version of the built-in language is used as an alias.
The specified relationship means that when changing (or explicitly specifying an alias for a field for which an automatic alias was used)
alias of the query field that generates the dynamic list data, the dynamic list attribute settings will be lost, the form elements will “lose” the displayed details, the dynamic list settings will become incorrect, etc.
If the data source of a dynamic list is a table (regular or virtual), which allows you to set a selection by period, then if the user sets the display period in such a dynamic list (command Set date interval...),
the specified period boundaries will be set as selection values or virtual table parameters. If by means of language extension
queries for the data composition system, the names of the virtual table parameters were explicitly specified - the parameters with the specified
names. Tables for which it is possible to control the period for displaying or processing data:
● register tables (main or virtual), for which it is possible to select by period (for the calculation register - by registration period);
● main tables of documents, business processes and tasks;
● main tables of document journals;
● main sequence tables, sequence boundary tables.
The dynamic list query parameter can be an array or a list of values. However, if the parameter is a list of values, then only the first value in the list will be used as the selection value. If a dynamic list uses a query with parameters, the initial setting of parameter values must be performed in the OnCreateOnServer handler.
When displaying dynamic list data, keep the following points in mind:
● When you programmatically change the properties of a dynamic list, the command panels associated with the list are not automatically repopulated.
with this dynamic list.
● If multiple fields are grouped into a group with the grouping mode in a cell and in the grouped fields there is a field that is displayed as a checkbox, then this checkbox will always be displayed first in the resulting cell (to the left of the text).
In a dynamic list, when determining the data type for fields whose expressions include parameters, fields, or literals, the resulting type is determined by the types of the fields and literals. If the parameter value type is not included in the resulting data type, its value will be truncated.
For example, in the following example the field will be of type Number.
CHOICE
WHEN IT'S A LIE
THEN 5
OTHERWISE
&Parameter
END
If you set the Parameter parameter to a value of another type, the dynamic list for that field will receive the value 0 (the default value for the Number type).
If in such a situation you need to select a parameter of a different type, it is recommended to use the query language construct EXPRESS. For example,
if in the above example you need to pass a string no longer than 100 characters into the parameter, then you should replace the simple indication of the parameter with an expression with an explicit type cast:
CHOICE
WHEN IT'S A LIE
THEN 5
OTHERWISE
EXPRESS(&Parameter AS String(100))
END
If the arbitrary text of a dynamic list request uses parameters in the expressions of the selection fields, you should explicitly indicate the type of parameters using the construct EXPRESS. For example, instead of &Nomenclature AS Nomenclature use
EXPRESS(&Nomenclature AS Directory.Nomenclature) AS Nomenclature. Otherwise searching through the search bar may work
incorrect or produce errors.
3. Methods for retrieving and caching data with a dynamic list
When obtaining data to display, a dynamic list uses one of three methods:
1. Reading from the database is performed in chunks with a number of data elements slightly greater than the number of rows simultaneously displayed by the list (but not less than 20). Data is not cached on the server.
2. Reading from the database is done in pages of 1,000 data items. Data is being cached on the server. Hierarchical data is cached: no more than 2 pages of elements are cached for each parent. No more than 20 pages of items are cached per dynamic list. Caching will be enabled by a dynamic list for the following tables:
● Selection criteria;
● All tables of the accounting register, except for the main table and the MovementsSubconto table;
● All accumulation register tables, except the main table;
● All tables of the information register, except the main table;
● All tables of the calculation register, except the main table;
● Virtual table of Tasks by Performer;
● Tables of external sources without keys;
● Cubes from external sources.
3. Reading from the database is performed in pages of 1,000 elements. The first portion is equal to 1 page. Each subsequent portion increases by 1 page (when the end of the previous sample is reached). The closer the “view point” moves to the end of the displayed data, the larger the sample is read from the database, eventually becoming equal to all the displayed data. Data is being cached on the server. The maximum number of entries in the cache and dynamic list is 1,000,000.
Depending on what is selected by the main table of the dynamic list and what value the Dynamic reading property takes, one or another method of reading data is used:
● One of the following tables is specified as the value of the Main table property: exchange plan, directory, list of documents, document journal, plan of characteristics types, chart of accounts, plan of calculation types, business process, task, table of business process points:
● One of the following tables is specified as the value of the Main table property: the main table of the information register, the accumulation register, the accounting register, the calculation register, the virtual table of the accounting register MovementsSubconto:
● Dynamic reading property:
● Installed: method 1 is used (description of methods is given above).
● Reset: Method 2 is used (description of methods is given above).
● The Main table property contains the selection criterion table or task table by executor (Tasks By Performer):
● Key identifying a table row: Link.
● The Main table property specifies the virtual table of the information register SliceFirst or SliceLast:
● Key identifying a table row: RecordKey.
● The Dynamic reading property is not applicable.
● Method 2 is used (description of methods is given above).
● The Main table property is set to one of the virtual register tables, except those listed above:
● The Dynamic reading property is not applicable.
● The Main table property is not specified, an arbitrary query is used:
● Key identifying a table row: Number.
● The Dynamic reading property is not applicable.
● Method 3 is used (description of methods is given above).
For display, data is transferred to the client in portions, the size of which is similar to the portion size in the 1st method of reading data (described at the beginning of this section).
When you create a form that contains a dynamic list, 45 data items for each visible dynamic list are initially passed to the client (if the list has more than 45 items). If the dynamic list displays more than 45 rows, an additional server call will be made when the form is opened to retrieve the missing data items.
4. Dynamic list settings
Property List settings - clicking on the Open hyperlink opens a form for setting up the display of a dynamic list. Setting up a list is done in the same way as similar operations in a data composition system.
Rice. 2. Conditional styling of a dynamic list When setting up a dynamic list in the configuration, the application developer has the opportunity to do the following:
● set the fields by which you want to sort;
● describe the selection of data in the list;
● specify conditional appearance settings;
● set the fields by which you want to group the data.
It makes sense to set the sorting to the developer if you are not satisfied with the default sorting installed by the system.
ADVICE. It should be remembered that poor selection of sorting fields (as well as selection and grouping of data) negatively affects the efficiency of dynamic sampling.
From the point of view of an application developer, dynamic list settings consist of several parts that are interconnected. The main property through which you can manage the settings of a dynamic list is LinkerSettings. This object contains three sets of settings that, when the system runs, determine the final settings applied to the dynamic list:
● Settings – settings created in the Configurator mode. The dynamic list's Order property provides quick access to the Settings.Order property of the dynamic list's settings builder, so the following constructs are equivalent:
List.Order and List.SettingsLinker.Settings.Order;
● UserSettings – these are settings that are changed by the user in 1C:Enterprise mode;
● Fixed Settings – these settings are set from the built-in language. This property also contains selection values that are transferred to the form using its parameters. The dynamic list properties Selection, Options, Conditional Appearance provide quick access to the fixed settings of the dynamic list settings builder. In other words, these calls are equivalent:
List.Settings Composer.FixedSettings.Selection and List.Selection.
When creating the final settings for a dynamic list, various settings options are combined as follows:
● If any type of settings is entirely marked as custom, then the resulting settings include the custom settings
(List.ComposerSettings.UserSettings). Moreover, if any settings elements are marked as unavailable, then these settings will be placed in the resulting settings from the List.Settings Composer property. Settings.
● If any type of settings is marked as custom not entirely, but element by element, then:
● Items marked as custom will be included in the resulting settings from the List.SettingsComposer.CustomSettings property.
● Items marked as unavailable will be included in the resulting settings from the List.SettingsComposer.Settings property.
● Fixed settings (List.SettingsComposer.FixedSettings) are added to the resulting settings “as is”. At the same time, it is unacceptable that the fixed and user settings contain settings of the same name, for example, selection with the same left value in the condition.
If the dynamic list settings contain settings that are disabled using functional options, these settings will be removed from the list of available settings when the dynamic list data is retrieved.
Controlling which settings will be available to the user and which will not is done in the dynamic list settings window.
Rice. 3. Control inclusion in user settings The checkbox at the bottom of the window (see Fig. 3) is responsible for placing the entire type of settings in the settings (normal or quick). This feature is available for selection, ordering, grouping, and conditionalization. If the settings are specified with the Quick Select editing mode, then in the User Settings Group property of the table of the form displaying the dynamic list, you must specify an empty group of the form in which the elements associated with the quick user settings of the dynamic list will be located. If the group is not specified, quick user settings will not be displayed on the form. It is also possible to explicitly invoke the creation of custom settings using the built-in language using the CreateCustomSettingsFormItems() method of the dynamic list extension.
It is also possible to choose whether to place specific settings items in the user settings. This feature is available for selection and conditional design elements (see Figure 3).
If you need any special settings to be loaded when opening a dynamic list, this can be done in two ways:
● Using the dynamic list form parameter UserSettings. The data contained in this parameter will be placed in the user's dynamic list settings.
● Using the dynamic list form parameterUserSettingsKey. If you specify this parameter when opening a form, then the user settings located in the settings storage with the specified key will be loaded into the dynamic list, which is the main attribute of the form.
5. Search in a dynamic list
A dynamic list located on the form provides the ability to interactively search the displayed data. The search can be carried out using the following tools: search bar, search dialog, search for the current value, using the search history and setting the period (for dynamic lists displaying documents). The search result is a limited set of records
a dynamic list (of those available to a given user) that match the search criteria.
To control the search capabilities of a dynamic list, there are three table properties on the managed form that displays the dynamic list:
● Search string position – determines the position of the search string. Can take the following values: Auto, Command Bar, None, Top, Bottom.
Rice. 4. Search string in a dynamic list If the value of this property is set to Command Panel, then the search string will be displayed in the form command panel (if the dynamic list is the main form attribute) or in the command panel associated with the dynamic list. The search bar placed in the command bar is always pressed to the right edge of the command bar (along with the buttons located to the right of the search bar).
If the property is set to No, then the search string will not be on the form, and when you start typing the search string, a dialog will open.
If the property is set to Top, the search bar will be located between the list command bar and the table displaying the dynamic list. If the property is set to Bottom, the search string will be placed immediately after the table displaying the dynamic list.
● If the Compatibility Mode property is set to Do not use or older than Version 8.3.4 – the value is Command Panel.
Go to the search line as follows:
● By pressing the key combination Ctrl+F;
● Mouse;
● When you start typing in a dynamic list (taking into account the value of the SearchOnTyping property of the dynamic list).
● View State Position – describes where the view state will be displayed: what fields were searched and what values
searched in every field. Can take the following values: Auto, None, Top, Bottom
Rice. 5. Search state in dynamic list If the property is set to No, then the view state will not be present on the form. As a result, it will be possible to determine whether the search has been completed or not only by the availability of the Cancel Search button.
If the property is set to Top, the view state will be located between the list command bar and the table displaying the dynamic list. If the property is set to Bottom, the view state will be placed immediately after the table displaying the dynamic list.
If the form was created in 1C:Enterprise version 8.3.4 and earlier, the property is set to No. If the form was created in 1C:Enterprise version 8.3.5 and older, the property is set to Auto. The real value of the property in this case will be determined as follows:
● If the Compatibility Mode property is set to Version 8.3.4 (and lower) – value No;
● If the Compatibility Mode property is set to Do not use or older than Version 8.3.4 – value Top;
● Search Control Position – Determines where the search control button will appear. The button opens a menu that contains the following information: commands Find by current value, Advanced search, Cancel search, Set period (for document and journal lists) and search query history (last 5 queries). The property can take the following values: Auto, None, Command panel.
Rice. 6. Managing search in a dynamic list If the property is set to No, then the search control button will not be on the form (but the commands will be available using the More menu). The Command Bar property value places a button on the command bar associated with a table displaying a dynamic list.
If the form was created in 1C:Enterprise version 8.3.4 and earlier, the property is set to No. If the form was created in 1C:Enterprise version 8.3.5 and older, the property is set to Auto. The real value of the property in this case will be determined as follows:
● If the Compatibility Mode property is set to Version 8.3.4 (and lower) – value No;
● If the Compatibility Mode property is set to Do not use or older than Version 8.3.4 – the value is Command Panel;
If there are several command panels on a form, the source of commands for which is one table of the managed form (displaying dynamic list data), then the search line and the search control button will be located in only one command panel:
● Or in the command bar of the dynamic list itself (if it has auto-completion enabled)
● Or in any of the remaining command panels.
Let's look at the features of using search in a dynamic list:
● To make the search convenient to use (including in terms of performance), you must enable full-text search for all configuration objects that can be used as the main table of the dynamic list. Also, the full-text search should include all details of configuration objects that may be displayed in a dynamic list and for which a search may be required.
If an object is excluded from full-text search, then the search mechanism in question will work, but the performance of such a search will be extremely low. It is not recommended to use search on objects that are not indexed by full-text search.
● The application solution must have a routine task that regularly updates the full-text search index.
● The search is not performed across all columns of the dynamic list (and configuration object), but only through those columns that are displayed in the table.
● Search in a dynamic list by fields of reference types with arbitrary representation is performed by fields that are used for
representation formation (see here). The fields included in the view are obtained taking into account the ViewFieldGettingProcessing() handler of the corresponding object.
● For dynamic lists with a specified main table, full-text search is used on the main table. All non-indexed links from the main table will be added to the full-text search results. The result of a full-text search for the main table is used as a selection based on key fields. A full-text search is also performed on fields displayed in the list from other tables (if the field and configuration object are using full-text search). Without full text search enabled, data may be
found, but the search itself will be very slow.
If an error occurs while attempting to perform a full-text search, the search will be performed without applying the full-text search.
For example, this can happen when searching for one letter and a large number of lines in the information base starting with this letter.
● If a selection with the comparison type Equals is used for a field in the main table of a dynamic list, then when performing a full-text search, a selection value will be added to the search query for this table.
● The search string is split into words. This partition is performed according to the following rules:
● The line is broken using space and tab characters as delimiters.
● Then each resulting fragment is processed:
● If the fragment is a date representation (with or without time) based on the current session locale, then the word is the fragment.
● Otherwise, the fragment is split further using the characters “,.-/\” as delimiters. In this case, each resulting fragment of the string is taken as a word.
● For each word, its own set of conditions is formed, which are combined “by OR”. This set of conditions is generated if a full-text search for a given word in the table from which this field was obtained returned at least one object, or a full-text search was not used for this field. The conditions are formed as follows:
● For a field of type String, the condition is FieldName LIKE %Word%.
● For a field of type Number, the condition has the form FieldName=Value, where Value is a word converted to the Number type. If the cast cannot be performed, the field search will not be performed.
● The word is looked up as a substring in the default Boolean representation defined for the current session. If the search word is found in a view, it then searches for the value corresponding to the view in which the word was found. In this case, the search does not use views that are specified using the Format form element property.
● For a field of type Date, the condition looks like FieldName>=StartofDay(Word) ANDFieldName<=КонецДня(Слово). Если Слово подобно дате, в которой год
indicated by one or two digits, the year will be reduced to the current century and this value will be added to the search condition.
● For reference fields, a search is performed on the fields used to form the reference view. In each of these fields search
performed according to the rules described above. The search does not use fields used to form a custom data representation.
The set of conditions for each word are combined “AND”.
● For values with leading zeros, you can search either the string with leading zeros or the string specified without leading zeros.
● If a dynamic list displays a list of documents or a document history, the list view interval that you specify is also displayed in the area of the form reserved for displaying the view status for the desired dynamic list.
● The search by current value command is not available if the main table of the dynamic list is the selection criterion.
● Found string fragments are highlighted when displayed in the table.
● Only one search string is supported for one column. When adding a new search query for a column that is already being searched, the search expression will be replaced rather than the two search queries being added together.
● If the form does not have a form element addition of the form Search string display associated with the table (form element addition Source property) displaying a dynamic list, then pressing the Ctrl+F key combination opens the search dialog.
Rice. 7. Search dialog If the form contains a form element addition of the form Search string display associated with a table (form element addition Source property) displaying a dynamic list, then to open the search dialog you should use the Advanced search command.
● When using the search dialog, keep the following points in mind:
● Opening the search dialog using a keyboard shortcut causes the value of the current cell to appear in the What to search line, and the value of the How to search switch is set to By exact match.
● Opening the search dialog by directly starting to type a search string in the dynamic list leads to the fact that the value of the How to search switch is set to the value By part of the string, and the typed text ends up in the What to search field.
6. Getting the data displayed by a dynamic list
When using dynamic lists, you may need to perform various actions on the data currently displayed by the dynamic list, taking into account the selections and searches applied. Such actions include: processing the displayed information, for example, resending selected documents or setting some details for selected objects, generating a list of available objects (with design, etc.), for example, for printing or saving to a spreadsheet document.
To obtain data that is displayed by a dynamic list, you should use the GetExecutableDataCompositionSchema() and
GetExecutableDataCompositionSettings().
Example of receiving data:
Schema = Elements.List.GetExecutableDataCompositionSchema();
Settings = Items.List.GetExecutableDataCompositionSettings();
LayoutLinker = newDataCompositionLayoutLinker();
LayoutLayout = LayoutComposer.Execute(Scheme, Settings);
CompositionProcessor = newDataCompositionProcessor;
LayoutProcessor.Initialize(LayoutLayout);
OutputProcessor = New OutputProcessorDataCompositionResultInTabularDocument;
ReturnOutputProcessor.Output(CompositionProcessor);
Getting data into a value collection (table or list of values) is done in the same way.
Obtaining dynamic list data in this manner has a number of features that must be taken into account when developing application solutions:
● The following table design is not supported:
● Alternating line colors;
● Header picture;
● Picture of the basement;
● Footer background color;
● Footer text color;
● Footer font;
● Horizontal position in the basement;
● Password mode.
● The conditional appearance specified for a managed form is not supported;
● When ordering a hierarchical table in ascending order by a field of type Link, records containing an empty link are always placed first.
In the process of finalizing configurations, every 1C programmer encounters dynamic lists.
A dynamic list is an interface object used to display various lists of database objects or non-object data - register entries.
For example, a dynamic list is used to display a list of items:
To demonstrate the capabilities of a dynamic list, let's create external processing and add the main form. Let’s add a new attribute to the form with the “Dynamic List” type. Let's go into its properties and see what's there.
We are interested in the “Custom request” property. Enabling it will show us all the capabilities of a dynamic list. We will be able to write a request using almost all the capabilities of the 1C: Enterprise system query language. Check the box and click the “Open” link:
By default, our list will display a list of items with the total balance for all warehouses. To implement such a list, add the following query:
As the main table, we will select “Directory.Nomenclature”, this will allow us to work with a dynamic list, as with a list of nomenclature - add, change, mark directory elements for deletion. Also, installing the main table makes it possible to dynamically read data - this means that the selection will be made in portions, as needed.
Next we need to create form elements for our list:
If we try to run our processing in this form, we will get an error:
To eliminate it, you need to set a value for the “Period” parameter. To do this, you can use the “SetParameterValue” method of the “Parameters” collection of the dynamic list. The method takes two parameters:
. "Parameter" - Type: String; DataCompositionParameter. The name of the parameter or data composition parameter whose value you want to set;
. “Value” - Type: Arbitrary. The value to set.
Can be called in the “OnCreateOnServer” handler of the form:
Do you have a question or need help from a consultant?
We will provide the user with the opportunity to change the period for receiving balances. To do this, add the attribute and the “Date” form element associated with it:
In the “OnChange” handler of the “Date” form element, we will call the “SetParameterValue” method, passing the value of the associated attribute as the value. In a similar way, let’s change the “When Creating On Server” procedure of the form. Since the method is available on the client, there is no need to call the server:
Now when the date changes, the balances will be automatically updated:
Let's assume that users want to see either current balances or planned receipts. Let's consider one of the implementation options. Let's add a boolean type form attribute and an associated switch:
When changing the value of the switch, we will change the text of the request. To do this, we will use the “On Change” event handler for the “Display Quantity On Receipt” form element. We need to change the “QueryText” property of the dynamic list depending on the value of the attribute. Since this property is not available on the client, a server procedure must be called:
Result of the changes made: 
Finally, the dream of every seven-year-old has come true. How often did users of program 7.7 ask for a normal selection of items? So that you can see balances, prices, and set filters. We had to come up with various tricks, including writing external components. In 1C 8.2, dynamic lists appeared. I propose to consider what it is and what they can give us in 1C 8.3.
Let’s take as a basis a certain test configuration of 1C: “Enterprise Accounting 3.0”. We won’t make a selection now, we’ll just add another selection form in the “Nomenclature” directory and make it temporarily the main one:
When created, the system will by default add a table field of the “Dynamic List” type to the form.
Let's go into its properties and see what's there.
First of all, we are interested in the “Custom request” checkbox. This will reveal to us all the advantages of a dynamic list. We will have the opportunity to write our own request, with parameters. Check the box and click the “Open” link:
A window will open with the finished code in . For now, all the fields of the “Nomenclature” directory are simply listed there.
Get 267 video lessons on 1C for free:
As you can see, there is a call button “ ” and a checkbox that makes it possible to dynamically change the contents of the list. That is, when another user changes something in the directory, it will also change in our list. In addition, there is a “Settings” tab, but we will touch on that later.
Custom query in dynamic list
First, let's create the request we need with balances and prices. Like that:
“Settings” tab
And now the best part! Go to the “Settings” tab. And we immediately see that on the first tab we can make any selections for any field in the request:
Programmatically setting query parameters in a dynamic list 1C 8.3
Don’t forget that we have two parameters in the request: “Period” and “Price type”. We must pass them into the request, otherwise there will be an error.
Let's write these parameters in the form parameters, and add the following lines in the form module:
&OnServerProcedureWhenCreatingOnServer(Failure, StandardProcessing) List. Options. SetParameterValue("Period" , Parameters. Date) ; List. Options. SetParameterValue("PriceType", Parameters.PriceType) ; End of Procedure
