Managed form details (1Cv8). Programmatically adding and changing elements of managed forms Adding attributes to a managed form

The 1C:Enterprise platform allows you to programmatically add and change elements of a managed form. Let's figure out why this might be needed.

Software modification of the form may be required in several cases:

• When finalizing standard configurations to facilitate the subsequent update procedure. In this case, only the form module will be changed. Modules are much easier to update than forms.
• When implementing some common algorithms. For example, in the “Prohibition of editing object details” subsystem, a button can be created programmatically for all objects connected to the subsystem to enable the ability to edit details.
• When implementing some specific algorithms. For example, in the Nomenclature directory, fields are created for editing additional details.

In a managed form, you can programmatically add, change, and delete:

• requisites;
• local teams;
• elements.

All of these operations are possible only on the server.

Programmatic reshaping has limitations:

• You can only delete programmatically added details/commands/elements. You cannot programmatically delete objects created in the configurator.
• You cannot assign an attribute as the main one.

Changing form commands

To manage the composition of commands for an object ManagedForm there is a collection Teams

Add (< ИмяКоманды >)

Quantity ()

Find (< ИмяКоманды >)

Delete (< Команда >)

The Teams collection is available on both the client and server. You can change the collection (Add() and Delete() methods) only on the server. You can search for and get the number of elements (the Find () and Count () methods) both on the client and on the server.

As an example of working with form commands, let’s create a new ChangeHistory command with the heading “ChangeHistory...”, which will call the handler DisplayHistory(). Creation occurs when the form is opened.

&On server
Procedure WhenCreatingOnServer(Failure, StandardProcessing)
Team = Teams. Add( "History of Changes");
Team . Action = ;
Team . Title = "History of changes...";
End of Procedure
&OnClient
Procedure Connectable_DisplayHistory(Command)
// command actions
End of Procedure

The command handler must be located on a form and have a &OnClient compilation directive.

Changing form details

Reading the composition of the form details is performed by the function Get Details(< Путь >) returning an array of type FormAttributes. The function parameter specifies the path to the parent attribute (as a string). If the parameter is omitted or an empty string is specified, the top-level details are returned.

Changing the details is done using the method Change Details(<Added details>, <Removable Details>) object ManagedForm. To parameters Added details And Removable Details Arrays with elements of the Form Attributes type are transmitted.

Attention!

The process of changing the composition of details is quite resource-intensive. The form is actually being recreated. In this regard, work with form details is performed in batch mode.

Let's create a new form attribute with the name Buyer:

AddedDetails = New Array;
Added Details. Add(New Form Attributes(“Buyer”, New Type Description (“Directory Link. Counterparties”), “Client”));

// Changes in the composition of details
);

Changing form elements

To control the composition of elements of an object ManagedForm there is a collection Elements. The collection has several methods:

Insert (< Имя>, < ТипЭлемента>, < Родитель>, < Элемент >)

Add (< Имя>, < ТипЭлемента>, < Родитель >)

Quantity ()

Find (< Имя >)

Move(< Элемент>, < Родитель>, < МестоРасположения >)

Delete (< Элемент >)

The Items collection is available on both the client and server. Modify a collection (Insert methods () , Add () , Move () and Delete () ) are only available on the server. You can search for and get the number of elements (the Find () and Count () methods) both on the client and on the server. Collection elements can be:

• FormGroup;
• FormTable;
• FormField;
• Form Button.

You can programmatically assign event handlers to form elements. The method is intended for these purposes SetAction(< ИмяСобытия>, < Действие >) .

Let's look at some of the most common examples in practice of working with commands, details and form elements.

Adding a command and its associated button:

// Create a command
Team = Teams. Add( "History of Changes");
Team . Action = "Plug-in_DisplayHistory"; // The form must contain a procedure with the specified name
Team . Heading = "History of changes...";
// Create a button and associate it with a command
Element = Items. Add( "History of Changes", Type("FormButton" ));
Element.CommandName = "History of Changes";

Adding an attribute and the associated input field:

// Description of the added details
AddedDetails = New Array;
Added Details. Add(New Form Props (“Buyer”, New Type Description ( "DirectoryLink. Counterparties"), "Client" ));
// Changing the composition of details
ChangeDetails(Added Details);
// Creating an input field and connecting to the attribute
Element = Items. Add("Buyer" , Type("FormField" ));
Element . View = FormFieldView. Entry field;
Element . PathToData= "Buyer" ;

Assigning an event handler to a form element:

ItemCustomer. SetAction("When it changes" , "Connected_BuyerOnChange");

&OnClient
Procedure Connected_BuyerOnChange(Element)
// Event actions
End of Procedure

Attention!

Procedures that are set as event handlers from code using the method SetAction(), it is recommended to set the Connectable_ prefix.

Attention!

You can download processing with examples of programmatic searching and changing details, commands and elements of a managed form.

Form details

A set of form details describes the composition of the data that is displayed, edited or stored in the form. At the same time, the form details themselves do not provide the ability to display and edit data. Form elements (see the “Form Elements” section of this chapter) associated with form details are used for display and editing. The set of all form details will be called form data.

Important! It must be remembered that, unlike regular forms, all data in a managed form must be described in the form of details. It is not allowed to use form module variables as data sources for form elements.

It is possible to assign Basic form details, i.e., attributes that will determine the standard functionality of the form (form extension). It should be remembered that a form can only have one main attribute.

Form extension– these are additional properties, methods and form parameters of the ManagedForm object, characteristic of the object that is the main element of the form.

During the form development process, you can explicitly set the ability to view and edit specific form details, in terms of roles, using the View and Edit properties (for more details, see the “Role-based form settings” section of the “Editors” chapter). In addition, the availability of a particular attribute in the form itself can be configured using functional options (more details about functional options can be found in the chapter “Configuration Interface Management”).

Form attribute property Saved data is a sign that an interactive change in the details will lead to an attempt to block the form data for editing, as well as to the automatic setting of the form modification flag.

Data types available in a managed form

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

• types that are directly used in the form are those types that exist on the side of the thin and Web client (for example, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);

• types that will be converted to special data types—managed form data types. Such types are displayed in the list of form details in parentheses, for example (DirectoryObject.Products);

• dynamic list (for more details, see the “Dynamic List” section of this chapter).

Converting Application Objects to Form Data

Some application types (such as DirectoryObject, etc.) do not exist on the thin and Web client side (see the Managed Application Concept chapter for more details). Therefore, to represent such application types in the form, the platform has introduced special data types designed to work in managed forms. This feature of a managed application makes it necessary to convert application objects to form data (and vice versa).

The following data types are used:

• Form DataStructure – contains a set of properties of an arbitrary type. Properties can be other structures, collections, or structures with collections. This type is represented, for example, in the form DirectoryObject.

• A FormDataCollection is a list of typed values, similar to an array. A collection element is accessed by index or identifier. Access by ID may not be available in some cases. This is due to the type of application object that is represented by this collection. The identifier can be any integer. This type is represented, for example, in the form of a tabular part.

• Form DataStructureWithCollection is an object that is represented as a structure and a collection at the same time. It can be treated like any of these entities. This type represents, for example, a set of records in a form.

• Form DataTree – an object designed to store hierarchical data.

An application object is represented by either one or more form data elements. In general, the hierarchy and composition of form data depend on the complexity and interconnection of application objects of the managed form.

For example, a document containing a tabular part will be represented by an object of the FormDataStructure type (the document itself), to which an object of the FormDataCollection type (tabular part of the document) is subordinated.

Important! When developing a configuration, it is important to remember that application objects are available only on the server, while form data objects can be used on both the server and the client.

Passing data between the client and server parts of a managed form

In fact, we can say that form data is a unified representation of data from various application objects with which the form works uniformly and which are present on both the server and the client. That is, the form contains some “projection” of application object data in the form of its own data types and performs conversion between them if necessary. However, if the configuration developer implements his own data processing algorithm, then he must perform data conversion (from specialized types to application types and vice versa) independently.

When editing form details in a specialized editor (for more details, see the “Form Details” section of the “Editors” chapter), it is possible to influence the transfer of data between the client and the server while the form is running. The column of the details editor is used for this. Always use. The effect of this property differs for three types of attributes:

• For an attribute subordinate to a dynamic list (dynamic list column):
  • property is enabled – the attribute is always read from the database and included in the form data;
  • property is disabled - the attribute is read from the database and included in the form data only when there is a currently visible form element associated with the attribute or its subordinate attribute.

• For props subordinate to the movement collection:
  • property is enabled – document movements are read from the database and will be present in the form data;
  • property is disabled - document movements will not be read from the database and will not be included in the form data (if there is no form element that references document movements).

• Other form details:
  • property is enabled – the attribute will be present in the form data, regardless of whether or not there is at least one form element that is associated with the attribute or its subordinate attribute;
  • property is disabled - the attribute will be present in the form data only if there is a form element associated with the attribute or its subordinate attribute. Unlike dynamic list attributes, the visibility of the element associated with the attribute does not matter here.

Note. It should be remembered that the property set on the parent attribute affects all subordinate attributes. For example, if the Use property is always cleared for the tabular part of the document, then the system considers that this property is also cleared for all subordinate details (despite the actual state of the property).

Methods for converting application object data into form data

To convert application objects into form data and back, there is a set of global methods:

• ValueInFormData(),
• FormDataInValue(),
• CopyFormData().

Important! Methods that work with application objects are available only in server procedures. The method for copying values ​​between form data is available on the server and on the client, since it does not require application objects as parameters.

When converting form data into an application object, you need to consider their compatibility.

• ValueInFormData() – converts an application type object into form data;
• FormDataInValue() – converts form data into an application type object;
• CopyFormData() – copies form data that has a compatible structure. Returns True if the copy was successful, or False if the object structure is incompatible.

Note. When performing standard actions (opening a form, executing a standard Write command, etc.) of a form with the main details, the conversion is performed automatically.

Let's give an example of how to use data transformation in your own algorithms.

&OnServerProcedure When CreateOnServer(Failure, StandardProcessing)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData(ObjectItem, Object);

End of Procedure

&OnClient Procedure Write()

WriteOnServer();

End of Procedure

&OnServer Procedure WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

End of Procedure

The ManagedForm object also has methods available on the server:

• ValueВFormAttribute() – converts an application type object into the specified form attribute.
• FormAttributeVValue() – converts a form data attribute into an object of an application type.

Using these methods is usually more convenient, since they have, for example, information about the type of form attribute. In addition, the Form AttributesValue() method sets the correspondence between the form data and the object, which is used when generating messages. You can read more about this in the chapter “Service navigation capabilities”.

Let's give an example of using these methods.

&OnServer Procedure RecalculateOnServer()

// Converts the Object attribute into an application object. Document = Form AttributesValue("Object"); // Performs recalculation using the method defined in the document module. Document.Recalculate(); // Converts the application object back to a prop. ValueВFormAttributes(Document, “Object”);

End of Procedure

Software interface

FormDataTree

• FindById
• GetItems

Description:

Designed to model a tree in managed form data.

This object can be serialized to/from XDTO. The XDTO type corresponding to a given object is defined in the namespace. XDTO type name:

GetItems

Syntax:

GetItems()

Return value:

Type: Form DataCollection of Tree Elements.

Description:

Gets a collection of top-level tree elements.

Availability: client, server, thin client, web client.

FindById

Syntax:

FindById(<Идентификатор>)

Options:

<Идентификатор>(required)

Type: Number. Tree element identifier.

Return value:

Type:FormDataTreeElement.

Description:

Gets a collection element by ID.

Availability: client, server, thin client, web client.

FormDataTreeItem

Properties:

<Имя свойства> (<Имя свойства>)

• GetId (GetId)
• GetParent
• GetItems
• Property

Description:

Form data tree element.

FormDataTreeItemCollection

Collection elements: DataFormTreeElement

For an object, it is possible to traverse the collection using the operator For each... From... Loop. The traversal selects the elements of the collection. It is possible to access a collection element using the [...] operator. The index of the element is passed as an argument.

• Insert
• Add
• Index (IndexOf)
• Count
• Clear
• Get
• Move
• Delete

Description:

Collection of wood elements.

Availability: client, server, thin client, web client.

See also:

• FormDataTreeElement, GetElements method
• DataFormTree, method GetItems

Features of working with a value tree

Tree update

There is a problem falls platforms when updating the tree.

If any node in the tree has been expanded and a subordinate node has been selected, then when updating the tree with the function ValueInFormData the platform falls.

Solution: You need to clear the tree before updating.

For example:

&On the Server Procedure ClearTree(elements) For each element from elements Loop ClearTree(element.GetElements()); EndCycle; elements.Clear(); End of Procedure

&On the Server Procedure Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); End of Procedure

&OnClient Procedure OnDateOnChange(Element) Fill ConceptTree(); End of Procedure

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

Introduction

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

• 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.

• &OnClient
• &On server
• &OnServerWithout Context
• &OnClientOnServerWithout Context

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

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?

• 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.

Design patterns or generational wisdom

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

• … 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

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

• ValueInFormData()
• FormDataValue()
• CopyFormData()
• ValueInFormProps()
• FormAttributesValue()

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)

Structuring the code

• 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 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 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.

• 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

Related questions

• Remote access interface implementation options. Asynchrony, level of detail...
• Caching. 1C made an unsuccessful architectural decision, introducing caching only at the level of calling methods of common modules and not providing control capabilities (relevance time, reset on demand).
• Implicit server calls. Do not forget about technological features; many “harmless” operations on the client provoke the platform to contact the server.

The form is controlled through various form elements, which are located hierarchically on the tab Elements form designer. The most important element is the form itself, which is located at the top of the hierarchy of elements, and the remaining elements are subordinate to it.

All form elements can be divided into five groups: fields, grouping elements, buttons, decorations and tables. In my articles I will analyze each of the groups. In this article, we will begin to study one of the types of field element - entry field, but before that we’ll learn how to add an element to the form.

Adding elements to a form

This is done quite simply: you need to select the element Form in the Form Design Elements window and click on the “Add” button. After this, a window will open in which you need to select the desired element type

After selection, the desired element will appear in the window Elements.

Managed form element Field

Let's look at a managed form element Field. This element is needed to enter information on the form. And also to display any information. After you add this element to the form, the form element properties palette will open on the right. For now, you should be interested in two properties – DataPath and View.

In the DataPath property, the developer can associate a form element with the desired form attribute. Please note that after the element has been added Entry field on the form it was not displayed on the form itself. This happened because our new element is not associated with . For example, I created several attributes on the processing form with different primitive types and one attribute with a reference type.

Now let’s connect our recently added form element with one of the details; to do this, select the desired attribute from the element’s PathKData property.

After this, the DataPath and View properties will be filled in, and the element itself will be displayed in the form view.

Pay attention to the element property View. This property defines the functionality of the input field. You can select different values ​​for this property.

Depending on the selected value, the functionality will be determined. In the pictures above the selected value is – entry field, i.e. we can enter any values ​​in this input field, and if we select a value label field, then we won’t be able to enter anything.

This property value View Input fields are convenient to select when you just need to show help information to the user.

Now let's add a new form element with type Entry field and connect it with the props DetailsDate through the already familiar to us DataPath property

As you can see, the appearance of the input field has changed, and the possible choice of values ​​for the View property will also change.

Thus, we conclude that the functionality of the input field depends on the type of attribute.

For props with type Boolean The following View property values ​​will be available.

And for attributes with a reference type, other values ​​of the View property will be available.

More detailed work with form elements using practical examples is given in the book “Basics of development in 1C: Taxi. Managed Application Development in 12 Steps".

Sometimes it seems that learning the programming language in 1C is complicated and difficult. In fact, programming in 1C is easy. My books will help you quickly and easily master programming in 1C: and “Basics of development in 1C: Taxi”

Learn programming in 1C with the help of my book “Programming in 1C in 11 steps”

1. No complicated technical terms.
2. Over 700 pages of practical material.
3. Each task is accompanied by a drawing (screenshot).
4. A collection of problems for homework.
5. The book is written in clear and simple language - for a beginner.

This book is suitable for those who have already started programming and are experiencing certain difficulties with this topic and for those who have been programming for a long time, but have never worked with 1C managed forms.

1. Without complex technical terms;
2. More than 600 pages of practical material;
3. Each example is accompanied by a drawing (screenshot);
4. The book is sent by email in PDF format. Can be opened on any device!

Promo code for a 15% discount - 48PVXHeYu

If this lesson helped you solve any problem, you liked it or found it useful, then you can support my project by donating any amount:

You can pay manually:

Yandex.Money - 410012882996301
Web Money - R955262494655

Join my groups.