Programmatically adding and changing elements of managed forms. Programmatically adding and editing managed form elements Editing form elements

The article continues the series “First steps in 1C development.”

In the configuration on the 1C:Enterprise platform, when displaying information, tables are most often used that display various information lists. Working with such lists can occur both in the form of a list and in the form of an element (processing).

In this article, we will get acquainted with these options for customizing lists, and also look at other features of customizing forms from the user's side.

Applicability

The article discusses the Managed Interface in the “Version 8.2” version of the configuration developed on the 1C 8.3.4.482 platform.

If you work with configurations that support this interface, then the information is relevant for you for current versions of the platform.

If you are working in the new Taxi interface, then the names of some configuration commands, as well as the general sequence of actions, may be slightly different.

In addition, the current version of the platform has added new search capabilities in lists.

Setting up forms and working with lists

For managed form elements, it is possible to change visibility and some other properties. For these purposes in a controlled form in the menu All actions serves as item Change form.

After clicking this command, the “Form Settings” window will appear.

In the window that appears, you can use checkboxes to change the visibility of some details. In this case, the form is automatically scaled.

You can change the order of details. Add a new group and place some details (elements) into it, defining the option for their grouping (horizontal, vertical).

Details included in the group will be posted accordingly. In addition, you can configure properties such as width, height, and header data for elements.

You can define attributes that will be activated when the form is opened.

An important feature is the ability to add new fields to the form. This becomes possible through reference type attributes.

For example, having a reference type attribute on the form Counterparty, can add The contact person, if this detail is present in the “Counterparties” directory.

If necessary, additional fields can be removed. Fields created in the configurator cannot be deleted. All settings made by the user are saved.

To return to standard settings in the Form Settings window in the menu All actions you should select the item Set default settings.

In addition to customizing forms in the managed interface, it is possible to customize lists (directory elements, documents).

In the form of a list in the menu All actions contains a special command Customize the list.

The “List Settings” window will open. In this window you can select, sort, define conditional formatting and grouping.

The figure shows a form for editing the selection.

Selection can be made using several fields. In this case, by default the selection will work according to the AND condition. You can also use the OR and NOT conditions.

To use the OR (NOT) condition, you need to add the appropriate group (OR Group, NOT Group) using the Group Conditions command.

The figure shows a form for defining sort fields.

Grouping can be configured. In the figure, the field for grouping is selected Counterparty.

The next figure shows how grouping will be performed.

You can freely color the list or apply other elements of conditional design (font selection, specific formatting) according to a given condition, as well as select a list of fields to be formatted.

The figure shows the result of conditional design of the field background Sum.
When the amount is > 100,000.

It should be noted that it is possible to view directories in hierarchy mode.

Hierarchical viewing of directories can be configured through the item View Mode on the menu All actions. You can choose one of the options: Hierarchical list, List, Tree.

It is also possible to configure your own grouping of directory elements by certain details.

For example, you can group items by supplier. The example is similar to where we looked at grouping the “Sales of goods and services” documents by counterparties.

A convenient feature is multiple selection in lists and subsequent execution of group actions (posting, canceling, unchecking deletion).

Objects in the list are selected by holding down the key Shift or Ctrl.

Searching for a certain value in a list has its own characteristics. The search operates in selection mode. Only those rows that satisfy the search condition remain.

To search by value in the current column, just position the cursor on the desired column and click on the button Find in the command panel. A window will appear in which you should also click on the button Find.

To make your search more specific, you can use the checkbox Search in found.

When searching for a row of data of a reference type (for example, units of measure), you should select the appropriate search option ...(by line).

This concludes with lists and ways to configure them. In the next article, we will continue to get acquainted with the interface and look at a convenient tool for informing the user, which we have not talked about before. What kind of instrument is this? :)

1C are created automatically by the system when using the application solution. They are the basis for presenting (displaying) information in the 1C:Enterprise system.

Structure of form 1C

Form B is a logical description of the composition of the form. elements describes what the form will look like. The placement of form elements is performed automatically by the system when it is displayed.

The displayed part of the form (visible to the user) is described as a tree that includes form elements (see the figure below, the “Form elements” field):

group including other elements,
input fields,
checkboxes,
switches,
buttons,
tables that include column elements, etc.

"Elements of 1C form"

[collapse]

A group of form elements can be represented as

panel with frame,
panel with pages (bookmarks),
the page itself,
command panel.

All functionality of the form is described as follows:

details (data the form works with);
commands (actions performed).

Customizing the appearance of a managed form

Customizing the appearance of a managed form by the user

The appearance of a managed form can be customized at the user level. For this feature, in the form actions there is a command “More” - “Change form” (managing only those form elements that are defined at the development stage or according to standard rules for form autogeneration).

"More" - "Change shape"

Command "More" - "Change shape":

After clicking “Change form”, the 1C form settings window is displayed:

[collapse]

In addition, in user mode it is possible to:

change the order of forms, move them from one column to another (if the desktop is organized in two columns), but you cannot change the number of columns on the desktop;
display information in the form of separate windows (when calling a navigation command, you need to hold down the Shift key).

If sections are used, then when you call a command in the navigation panel, the corresponding list is displayed in the work area, replacing the previous contents of the work area.

Customizing the appearance of a managed form by a developer

The developer can influence the arrangement of elements with various settings. It can determine the order of elements, specify their width and height, and also use:

commands of the form itself;
global commands used throughout the configuration;
parameterizable commands that will open other forms based on the specific data of the current form.

Figure (change of 1C form by developer)

[collapse]

When developing Form 1C you must:

In the form editor, include the necessary details and commands in the form;
create form elements that display them, determine the order of the elements, specify the width and height (if necessary);
arrange elements into groups (if necessary).

Use role-based visibility settings in form elements (viewing and editing details by , custom visibility of form fields by role, using commands by role) in the case of a large number of roles in the configuration (from several dozen). Instead, the following approaches should be followed:
- when there are strong differences in the appearance and functionality of the form depending on the presence of certain roles for the user – develop separate forms, specialized for a specific set of user rights;
- with minor differences - perform permission checks in code. It should be borne in mind that programmatic visibility control can reduce the speed of opening the form, which must be taken into account when choosing between the proposed approaches.
Use role-based visibility settings in the configuration command interface, the main section command interface, and the start page work area. Instead, you should set permissions on sections of the command interface and objects included in the command interface or workspace. This makes the behavior of the managed interface more predictable for the user, and also makes it easier to investigate errors.

For more detailed information on working with forms, see the course “Working with forms in 1C:Enterprise 8.3”, http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=161.

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

Introduction

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

In 2008, a new version of the 1C platform: Enterprise 8.2 (hereinafter referred to as the Managed Application) became available, which completely changes the entire layer of work with the interface. This includes the command interface, forms, and the window system. At the same time, not only does the model for developing the user interface in the configuration change, but also a new architecture for separating functionality between the client application and the server is proposed.
The managed application supports the following types of clients:

Thick client (normal and managed launch mode)
Thin client
Web client

The managed application uses forms built on new technology. They're called Managed Forms. To ease the transition, previous forms (the so-called Regular forms) are also supported, but their functionality is not developed and they are only available in the thick client launch mode.
The main differences of managed forms for a developer:

Declarative, not “pixel by pixel” description of the structure. The specific placement of elements is performed automatically by the system when the form is displayed.
All functionality of the form is described as details And teams. Details are the data that the form works with, and commands are the actions to be performed.
The form runs on both the server and the client.
In the client context, almost all application types are unavailable, and accordingly it is impossible to change the data in the infobase.
For each method or form variable, it must be specified compilation directive, defining the execution location (client or server) and access to the form context.

Let's list the directives for compiling form methods:

&OnClient
&On server
&OnServerWithout Context
&OnClientOnServerWithout Context

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

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

Let's define the problem

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

Let's look at the code structure (form module) in several forms of the same standard configuration and try to find patterns.
By structure we mean sections of code (most often these are comment blocks) allocated by the developer to group methods and compilation directives for these methods.
Example 1:
Section of event handlers Method - on the client Method - on the server Method - on the client Section of service procedures and functions Auxiliary input control functions
Example 2:
Service procedures and functions Payment documents Values Event handlers
Example 3:
Service procedures on the server Service procedures on the client Service procedures on the server without context Header event handlers Command event handlers
Example 4:
General-purpose procedures Form event handlers Procedures of the “contact information” subsystem
Essentially, the code structure is missing, or to put it mildly, it is similar to what was in Forms 8.1:

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

Why do you need code structure?

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

Why doesn't the existing development standard from 1C help?

Let's look at the principles published on ITS disks and in various “Developer's Guides...” that are recommended when writing a managed form.

Minimize the number of server calls.
Maximum computing on the server.
Non-contextual server calls are faster than contextual ones.
Program with client-server communication in mind.
and so on.

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

Design patterns or generational wisdom

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

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

A word from Martin Fowler, his description of these principles:

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

Examples of templates in the 1C platform

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

In the context of a managed form, there are many “Data Transfer Objects”. You can select systemic And developer-defined.
System ones model an application object on the client, in the form of one or more form data elements. It is impossible to create them without reference to the form details.

DataFormsStructure
DataFormsCollection
DataFormStructureWithCollection
DataShapesTree

Conversion of system data transfer objects to application types and vice versa is performed using the following methods:

ValueInFormData()
FormDataValue()
CopyFormData()
ValueInFormAttributes()
FormAttributesValue()

Often explicit conversion is used when adapting an existing solution. Methods may expect (use features) input parameters, such as ValueTable rather than FormDataCollection, or the method has been defined in the context of an application object and has become unavailable for direct call from the form.
Example 1C v8.1:
// on the client in the context of the form FillUserCache(DepartmentLink)
Example 1C v8.2:
// on the server in the context of the form ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Data transfer objects, the structure of which is determined by the developer, are a small subset of the types available on both the client and the server. Most often, the following are used as parameters and results of methods of a “coarsened” interface:

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

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

Structuring the code

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

Clear separation of client and server code. Let’s not forget that at the time of execution these are two interacting processes, each of which has significantly different available functionality.
Clear identification of the remote access interface, which server methods can be called from the client and which cannot? The names of remote interface methods begin with the prefix "Server". This allows you to immediately see the transfer of control to the server while reading the code, and simplifies the use of contextual help. Note that the official recommendation (ITS) suggests naming methods with postfixes, for example, ChangeOrderStatusOnServer(). However, we repeat that not all server methods can be called from the client, and therefore logical accessibility is more important, rather than compilation location. Therefore, with the prefix “Server” we mark only the methods available to the client; let’s call the example method ServerChangeOrderStatus().
Readability. A matter of taste, we accept the order when the module begins with the procedures for creating a form on the server and remote access methods.
Maintainability. There must be a clear location for adding new code. An important point is that method templates automatically created by the configurator are added to the end of the module. Since event handlers for form elements are most often automatically created, the corresponding block is located last, so as not to drag each handler to another place in the module.

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

Graphical option – clearly shows the main flow of execution.
The text option is an example of a template design for quickly inserting a structure into a new form module.

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

Default functionality

In 1C:Enterprise you don’t have to create forms for presenting and processing data objects. In this case, when executing commands to open forms, the system will automatically create the required form on the fly. The generated form will have default functionality and presentation. What determines the presentation and functionality of a form?
The standard presentation and functionality of a form is determined by the Managed Form interface object (for example, the ability of the form to be closed) and the form extension (for example, the ability to write form data to the infobase).
A form extension is additional properties, methods, parameters and commands that appear on the Form object when the main attribute is assigned to it.

ATTENTION!
Only one attribute can be selected as the main one
from the form details.

It is important to understand that:

the additional functionality provided is included in the Managed Form object, that is, it becomes an integral part of it
the composition of additional features is determined by the type of the main form attribute, that is, the type of data the form is intended for editing.

Extensions can also be present on form elements. As with the form itself, the composition of the extension, that is, additional properties, methods, etc., of a form element is determined by the type of attribute with which the element is associated.
If it is necessary to implement a non-standard data presentation or non-standard functionality, the developer can independently create a form in the configurator. The form editor is used to create forms. Using this editor, the developer creates the necessary set of details and commands for the form, as well as the form elements with which they are displayed.

Form commands

To get acquainted with the form commands, let’s create another form for the Goods Consumption document. From the context menu of the Forms node of this document, select Add.

Adding a Subform

As a result, the form designer window will open. In the designer window, select the form type – Document Form, check the Assign form as main checkbox and set the name MainForm. Click the Finish button.

Form Design Window

1C8: Form designer window

As a result of the designer's work, a document form is created; this form is assigned as the main one, that is, it is used by default for working with the document. After the designer completes the created form, the form editor window will open.

Form editor with automatically created document form

NOTE
In the form editor, the main form details are highlighted in bold.

If you open the Goods Consumption document in 1C:Enterprise mode, we we will see that the form we created is used to work with the document.

Form for editing the document “Consumption of goods”

Elements that provide access to commands are located in command panels. In our case, the system generated a form command panel and a product table command panel. You can select any of the available commands from the All actions menu of the corresponding command panel. To speed up access to commands, some of them (the most important or frequently used) are presented as buttons directly in the command panels.
What “guides” the system when forming the composition of the uniform teams? Which teams should be in uniform? To answer these questions, you need to remember the main purpose of the form - interactive data processing. Therefore, the form must contain commands that provide the user with the ability to process the form data and the ability to access the data associated with the processed data.

To process form data - standard form commands s

The form must contain commands for processing data and for managing the form. These capabilities are provided by standard local form commands. In the form editor they are presented on the tab Standard commands command editor.

Standard form commands in the editor and interface

1C8: Standard form commands in the editor and interface

These commands are provided by the form and the form extension. The composition of the commands provided by the form is standard and does not depend on the form data - these are the commands:

Reference
Change form...
Close
Save settings...
Restore settings...

The composition of commands provided by the extension depends on the type of the main form attribute. In our case, the main attribute of the form is assigned to the Object attribute with the DocumentObject.ProductConsumption data type (see figure above). The extension corresponding to this data type provided the commands:

Swipe and close
Write down
Reread
Copy
Mark for deletion
Unmark deletion
Delete
Conduct
Cancellation.

ATTENTION!
It is necessary to distinguish between standard configuration object commands and standard form commands. The former are used in the global command interface and are provided by the configuration object. The latter are used in the form and are provided by the form itself, its extension and extensions of form elements of the Table type.

To facilitate the development of form management algorithms, the standard form commands include the following commands:

No,
Cancel,
Abort,
Skip,
Repeat.

If such a command is added to the form, then when the user selects it, the following actions are performed:

for a form opened in modal mode, the form is closed and a value of the type DialogReturnCode corresponding to the selected command is returned
For a form opened in modeless mode, only the form is closed.

If form elements contain tables, then commands are added to the form's standard local commands to process the data displayed in these elements. At the document Product consumption There is a tabular part, which is represented in the form data by the Products attribute. To display a list of products in the form, use the Products element of the Table type. The standard local commands of the form include commands for processing tabular data - the Products node in the command editor.

Standard table commands in the editor and interface

To work with linked data - global parameterized commands

When processing form data, you may need to view the data associated with the data being processed. This could be, for example, a set of entries in the register of mutual settlements with counterparties, subordinate to the document being processed, or a list of prices for goods sold, etc. It may also be necessary to perform some processing of related data, for example, enter a payment document based on a sales document or print barcodes goods sold, etc.

Access to linked data is provided by global parameterizable navigation commands, and processing of linked data is provided by global parameterizable action commands. In the form editor, they are presented on the Global commands tab of the command editor.

Global parameterizable commands in the editor and interface

These commands are provided by the application solution's global command interface. The composition of commands available in the form depends on the type of parameter of the parameterized command (see. "Arbitrary commands"). Those global parameterized commands are available in the form for which, in the context of the form, you can get the parameter values of the required type.
In the command editor, the source of the parameter for a command is indicated in parentheses after the command. For example, for the command to open a sales register list, the parameter is a link to the document being edited.
If there are several sources for a command on a form, then the command is represented as a tree node, and the list of sources is represented as the elements of this node. Such a command can be included in the form commands with any of the sources (or several instances of the same command with different sources).
To work with application functionality - global independent commands When processing form data, it may be necessary to use application functionality that is not directly related to the data being processed.
For example, when processing document data, we need to perform a search in the data or enter a new price type. Global independent teams will help you perform these operations. In the form editor, they are presented on the Global commands tab of the command editor.

Global independent commands in the editor and interface

Global independent commands are provided by the global command interface. In the command editor, global independent commands are grouped into sections of the global command interface. The command will be available from all sections of the global command interface in which it is included.

Methods for forming team composition

Having become acquainted with the sources of form commands, let's see what options the system provides us with for creating the composition of form commands.

NOTE
There is another source of commands for the form - the developer, who can create arbitrary local commands for the form. We'll talk about these commands a little later (see "If standard commands are missing").

In the most general case, there are three options:

automatic – the composition of the form commands is determined by the system completely automatically
combined – the composition of the form commands is determined automatically by the system, and the developer, using the form editor, corrects it
manual – the composition of the form commands is determined entirely by the developer.

The automatic option is the fastest and least expensive from the point of view of developing an application solution - the system does everything independently. The combination option is probably the most commonly used. With this approach, the developer intervenes in the operation of the system only when the set of commands generated by the system does not provide the required functionality for processing form data. In the vast majority of cases, intervention is expressed in a simple expansion of the composition of the uniform teams. The manual option provides maximum opportunities for managing the composition of form commands and their placement. However, it requires the developer to perform a significant amount of painstaking work.

The platform contains a large number of mechanisms that facilitate the implementation process and provide greater opportunities for customizing the application solution. What in other systems has to be done by adding or rewriting program code, in 1C:Enterprise 8 can be done with a few mouse clicks. Sometimes even right in the user mode. Without modifying the application solution itself, without changing its program code.

As a rule, an application solution contains all the roles necessary for full operation. However, there may be special requirements for a particular implementation. The implementer can create new roles to meet these needs. The most convenient way to do this is by copying and changing the roles already existing in the application solution.

Setting up the section panel

You can change the composition of the section panel in the Configurator in 1C:Enterprise mode.

Setting up the home page

The composition of the forms located on the initial page can be changed in the Configurator with details by role, or individually for one or several users in 1C:Enterprise mode.

Setting up the command interface of the main section

You can change the composition of the teams displayed in the main section in the Configurator with details by role.

Setting up partition command interfaces

The composition of commands displayed in a particular section of the application solution can be changed in the Configurator with detail by role. At the same time, it is possible to configure both all sections at once (the "All subsystems" editor) and each section separately (the command interface editor).

Setting up forms