You have a question and need help from a consultant.

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.

SELECT NomenclatureList.Name AS Name, GoodsInWarehousesRemainings.Warehouse AS Warehouse, GoodsInWarehousesRemainings.QuantityRemaining AS QuantityRemaining FROM Directory.Nomenclature AS NomenclatureList LEFT CONNECTION RegisterAccumulations.GoodsInWarehouses.Remainings(&CurrentDate,) AS GoodsOnUS treasuresRemaining software NomenclatureList.Link = ProductsInWarehousesRemainings.Nomenclature WHERE

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.

&OnServerProcedureWhenCreatingOnServer(Failure, StandardProcessing)RemainingDate = CurrentSessionDate(); Item Remains.Parameters.SetParameterValue("CurrentDate", RemainingDate); End of Procedure &On the Client Procedure Remaining DateWhenChanged(Element)Nomenclature Remaining.Parameters.SetParameterValue("CurrentDate",RemainingDate); End of 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:

1. Selection;
2. 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.

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:

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:

Home Notes from Through the Looking Glass

04/21/2014 Receiving dynamic list data

Implemented in version 8.3.6.1977.

We have implemented the ability to easily and conveniently obtain data displayed using a dynamic list.

You may need dynamic list data in order to print it in a non-standard, “specific” form. Or in order to perform certain actions with them. For example, send a letter to all contractors whom you have selected in the list based on certain criteria.

In addition, there are a number of tasks in which the user, in addition to the list of elements, also wants to see the summary data associated with this list. For example, having selected products of a certain product group and a certain supplier, he immediately wants to see the total number of such products in the database.

A dynamic list by itself cannot provide you with this information. The purpose of a dynamic list is to provide quick viewing of large amounts of data. Therefore, it reads the data in chunks required to display on one or two screens. And “knows nothing,” for example, about the total amount of data that he has to count.

In general, in order to get additional information that the user wants, you need to run a database query. Exactly the same as the one used in the dynamic list.

You used to be able to do this. But it wasn't always easy. After all, in addition to the text of the original request on which the dynamic list works, you needed to know all the selections, sortings and other parameters that the user interactively set in the table displaying the data.

Now this problem can be solved simply. The dynamic list table now has two new methods:

• GetExecutableDataCompositionSchema();
• GetExecutableDataCompositionSettings().

Thus, you get the data layout scheme itself, and, most importantly, all its settings, thanks to which the user sees the list exactly like that. All you have to do is programmatically compose the layout and display it in a collection of values ​​(for program processing) or in a spreadsheet document (for display):

As a result, you will receive a structure (or report) containing columns and rows displayed in a dynamic list table.

The important point is that the layout and settings you receive from the dynamic list table take into account, among other things, the visibility of the columns and the search applied. Since the settings are obtained separately, you can change the composition of the fields for your own purposes and get, for example, all the columns of the list, and not just those that are visible to the user.

When outputting to a spreadsheet document, there is one more pleasant moment. In general, the appearance of the report will correspond to the appearance of the dynamic list table at the time the schema and settings are received. Including the conditional design of the table. You will need some additional actions only if you want to transfer the conditional design of the form to the report.