Managed form details (1Cv8). Programmatically adding and changing elements of managed forms Programmatically adding an element to a managed form 1c

Form editor used to create and edit object shapes application solution. Object shapes are used by the system to visually display data as the user works.

Any form represents a combination of several components:

elements - objects that determine the visual representation of the form and interact with the user,
command interface - a set of commands displayed in the form;
details - objects whose data the form uses in its work.
commands - actions that are defined in this specific form,
parameters - objects whose values characterize the form itself, are used during its creation and remain constant during the “life” of the form,
module - a program in a built-in language responsible for working with elements and processing events;

The form editor contains several tabs that allow editing of all form components.

In a separate window, at the bottom of the editor, the appearance of the form in 1C:Enterprise mode is displayed.

Editing elements

The form editor allows the developer to use a wide range of options for changing appearance forms - the type that the form will have in 1C:Enterprise mode. Let's list the main ones:

Pages, bookmarks

The form editor allows you to add special elements to the form that help give the form its own recognizable style, make access to data simple and clear, and also fit a large amount of information into a limited area.

The editor allows you to add multiple elements to the form Group - Pages, each of which can contain several elements Group - Page.

For example, a document form may contain one element Group - Pages, to which several elements are subordinated Group - Page with headings Image, Characteristics And Description:

Then in 1C:Enterprise mode it will look like this:

The title of each group - page is displayed on a separate tab. The developer has the opportunity to set the display mode of bookmarks: bottom or top:

For example, bookmarks can be placed at the bottom:

Elements

The editor allows you to add various elements to the form. You can add elements using the add command or by dragging form details into the element tree:

All form elements are represented in the form of a hierarchical structure, the root of which is the form itself. This allows you to quickly navigate to the desired form element:

By placing elements higher/lower in the tree, subordinating them to other elements and setting the properties of group elements, you can set the order in which the user will bypass the form controls when entering and editing data. In 1C:Enterprise mode, form elements will be processed in the order of their hierarchy and in accordance with what type of grouping is selected for groups: vertical or horizontal.

Separators

The delimiters are special elements, with the help of which it is possible to redistribute the space of a form without changing its size. The platform in 1C:Enterprise mode independently adds these elements to the form. The separator has the ability to be "grabbed" by the mouse and moved within the form within its boundaries, taking into account the possibility of the location of other elements and the orientation of the separator:

When you move a separator, all elements associated with the separator will resize or move:

Form module

To edit a form module, the configurator calls the text and module editor. This editor provides the developer with a wide variety of options for creating and modifying module text.

Form details

Editing form details is performed in the list, which allows you to create new details, change existing details and delete unnecessary details. Properties of attributes are set using the properties palette.

If a form has a main attribute that determines the behavior of the form that differs from the standard one, it is highlighted in bold.

Form command interface

The form's command interface is edited in the tree. The main branches of the tree contain commands added to the navigation bar of the window in which the form will be displayed and to the command bar of the form. Within each of these branches, teams are divided into standard groups.

Some of the teams in command interface the platform adds automatically. Along with this, the developer can independently add commands to the command interface by dragging them from the list of form commands or from the list of available global commands. For all commands added to the command interface, the developer can set their visibility to the various roles defined in the configuration.

Form commands

Form commands are edited in the list. The developer has the ability to add, remove form commands and set their properties using the properties palette. Including assigning a procedure to a command that will be executed when the user calls this command.

Bookmarked Standard commands And Global teams the developer is provided with lists of commands generated by the platform and available for use in this form. Their properties cannot be changed, you can only add them to the form.

Using the mouse, the developer can drag and drop a command into the form's command interface. You can also drag a command directly into the element tree if you need, for example, to display this command as a button located on a form.

Form Options

Form parameters are edited in the list. The developer has the ability to add, remove form parameters and set their properties using the properties palette.

The form details ensure its connection with the data. In this case, one (and only one) of the details can be designated as the main one; it may not necessarily be the data type to which we are drawing the form. But the behavior of the form will depend on the data type of the main attribute. In addition to changing the behavior of the form, the context of the form module changes. Along with the methods and properties of the form, the methods and properties of the object, which is the value of the main attribute, become available in it. It is important that forms of the Free Form type do not have basic details. In this case, the form's behavior is determined only by the user's settings. Let's consider questions about the basic details.

Question 10.05 of exam 1C: Platform Professional. What is the main form attribute used for?

Defines the data source for the form as a whole
Defines standard features platform for working the form with data of the type specified in the main attribute
To provide the ability to programmatically access object details from the local form context
Provides visualization of object details on the form dialog
2 and 3 are correct
1 and 2 are correct

The correct answer is number six, see above.

Question 10.06 of exam 1C: Platform Professional. What are the form details needed for?

To describe the content of the data that is displayed, edited, or stored in a form
To display and edit data in a form
1 and 2 are correct

The correct answer is the third - both.

Question 10.07 of exam 1C: Platform Professional. To assign basic attributes to an arbitrary controlled form...

You need to check the "Basic details" checkbox in the properties of the form attributes
you need to fill in the “Data” property of the form by selecting the required form attribute

The correct answer is second:

Question 10.08 of exam 1C: Platform Professional. To assign the main details to an arbitrary regular form...

the form needs to be made the main one, the main details are determined automatically
You need to check the "Basic details" checkbox in the properties of the form attributes
you need to go to the "Edit" menu, "Basic details" and select the desired value
you need to fill in the “Data” property of the form by selecting the required form attribute

The fourth correct answer is:

The main details are highlighted in bold:

Question 10.09 of exam 1C: Platform Professional. If there is one main form attribute, is it possible to add another main attribute?

This is impossible
Possible by appointment corresponding value form attribute properties
It is possible only programmatically, when accessing the "Form" object
This is possible by adding another value to the corresponding form property

The correct answer is the first, there is strictly one main requisite, because the connection with the object must be unambiguous.

Question 10.113 of exam 1C: Platform Professional. Which of the details of the form presented in the figure is the main one?

List of Currency Rates
DirectoryObject
Directory forms do not have basic details
Directory forms have all the basic details

The second correct answer is the one in bold.

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 the “Add” button. After this, a window will open in which you need to select desired type element

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

Managed form element Field

Let's parse the element controlled form 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 determines 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 figures 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 background 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 selection 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”

No complicated technical terms.
Over 700 pages of practical material.
Each task is accompanied by a drawing (screenshot).
A collection of problems for homework.
The book is written in a clear and in 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.

Without complex technical terms;
More than 600 pages of practical material;
Each example is accompanied by a drawing (screenshot);
The book is sent to email V 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.

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, for all objects connected to the subsystem, software creation buttons 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 new team Change History with the title “Change History...”, 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 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 with attributes
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 prefix Connectable_.

Attention!

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

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 it became available a new version platform 1C: Enterprise 8.2 (hereinafter referred to as the Managed Application), 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

A 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 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 is used in various software technologies more than a dozen years. The answer to the questions outlined in the previous section has long been known and is summarized in two basic principles.

Remote Facade(hereinafter Interface remote access)
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 specific 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

Applied software 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()

Explicit conversion is often used in adaptation 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. Important point 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 basic structure 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