In this article, we will get acquainted with the main aspects of working with a managed form in 1C 8.3. What is a form and why is it needed? The form is the main object through which the user interacts with the program. That is, using the form, the user enters information into the program, as well as the information necessary for the user is displayed on the form.

The main task of a developer of any form (managed or conventional) is to provide the user with a convenient mechanism for interacting with the program.

The 1C platform has the ability to generate any form of an object, but usually, when developing application solutions, programmers configure the forms themselves.

The issues of working with managed forms in particular and with a managed application as a whole are discussed in detail in the book “Fundamentals of Development in 1C: Taxi. Developing a Managed Application in 12 Steps. This book will be a real help to those who are just getting started with managed application development.

The book "Fundamentals of Development in 1C: Taxi" is perfect for those who have already started programming and are experiencing certain difficulties with this topic and those who have been programming for a long time, but have never worked with 1C managed forms

1. No complex technical terms;
2. Over 600 pages of practical material;
3. Each example is accompanied by a picture (screenshot);

Promo code for a 15% discount - 48PVXHeYu

Sometimes it seems that learning a programming language in 1C is difficult and difficult. In fact, programming in 1C is easy. My books will help you easily and quickly master programming in 1C: and "Fundamentals 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 picture (screenshot).
4. Collection of tasks for home study.
5. The book is written in clear and simple language - for a beginner.
6. The book is sent by e-mail in PDF format. Can be opened on any device!

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

can be paid manually:

Yandex.Money — 410012882996301
Web Money - R955262494655

Join my groups.

Forms in 1C:Enterprise are designed to display and edit the information contained in the database. Forms can belong to specific configuration objects or exist separately from them and be used by the entire application solution as a whole.

For example, a guide Nomenclature may have several forms that will be used for specific purposes - editing a directory element, displaying a list, etc.:

Along with this, there may be general forms that do not belong to specific configuration objects - general forms.

Basic forms

Each configuration object can be used to perform certain standard actions. For example, for any directory, you may need to display a list of its elements, display individual elements of the directory, display a group of the directory, select elements and groups of elements from the directory. For any document, the list of such actions will be much smaller: viewing the list of documents, selecting from the list of documents, and viewing a single document.

To ensure the performance of such standard actions with the data of the objects of the applied solution, for each of them there is a set of basic forms that will be used when performing the corresponding actions. The main one can be assigned to any of the forms subordinate to this object. For example, the directory Nomenclature the following main forms may exist:

And the document Receipt of goods and services the composition of the main forms will be different:

Thus, if the user wants to see the directory list Nomenclature or a list of documents Receipt of goods and services, the system will open the corresponding form assigned as the list form for these objects.

Auto-generated forms

An important feature of the 1C:Enterprise 8 system is the mechanism of auto-generated forms. This mechanism frees the developer from having to create all possible forms for each of the configuration objects. It is enough for the developer to add a new configuration object, and the system itself will generate the necessary forms at the right moments of the user's work to display the information contained in this object.

Thus, the developer needs to create his own forms of application solution objects only if they must have differences (different design or specific behavior) from the forms automatically generated by the system.

Linking Form to Data

The fact that the form belongs to one or another configuration object does not determine the composition of the data that is displayed in the form. That the form belongs to, for example, a directory Nomenclature, allows you to assign it to one of the main forms for this directory, but does not determine in any way what kind of data this form will display, and what its behavior will be.

In order to link the form with the data, the form attributes are used, which indicate the list of data displayed by the form. All forms, by themselves, have the same behavior, no matter what data they display. However, one of the form attributes can be set as the primary form attribute (it is highlighted in bold), in which case the standard behavior of the form and its properties will be supplemented depending on the type of the primary form attribute:

For example, if a document is assigned as the main attribute of the form Receipt of goods and services, then when the form is closed, the system will ask for confirmation of recording and posting this document. If, say, a reference book is assigned as the main attribute of the form Nomenclature, then there will be no such confirmation request when closing the form.

Form structure

The main feature of the forms is that they are not drawn by the developer in detail, “by pixels”. A form in a configuration is a logical description of the composition of a form. And the specific placement of elements is performed by the system automatically when the form is displayed.

The part of the form that is displayed (visible to the user) is described as a tree containing form elements.

Elements can be input fields, checkboxes, radio buttons, buttons, etc. In addition, an element can be a group of other elements. A group can be represented as a panel with a frame, a panel with pages (tabs), a page itself, a command panel. In addition, an element can be a table that also includes elements (columns). The element structure describes how the form will look like.

All functionality of the form is described in the form of details and commands. Details are the data that the form works with, and commands are the actions performed. Thus, the developer in the form editor must include the necessary details and commands in the form, create the form elements that display them, and, if necessary, arrange the elements into groups.

Based on this logical description, the system automatically generates the appearance of the form for display to the user. At the same time, the system takes into account various properties of the displayed data (for example, type) in order to arrange the form elements as conveniently as possible for the user.

The developer can influence the arrangement of elements with various settings. It can determine the order of the elements, indicate the desired width and height. However, this is just some additional information to help the system display the form.

In forms, the developer can use not only the commands of the form itself, but also global commands used in the command interface of the entire configuration. In addition, the ability to create parameterizable commands that will open other forms, taking into account the specific data of the current form, has been implemented. For example, it can be a call to a report on balances in the warehouse that is currently selected in the invoice form.

In the last lesson, we considered for a regular (fat) client. In platform version 1C 8.2. They use new screen forms 1C 8.2. They are called managed forms 1C 8.2.

Managed forms 1C 8.2 is the future of 1C. They differ from ordinary 1C 8.2 forms in that they are automatically generated by the system based on special settings (“regular” forms are simply drawn by the programmer at will).

The differences in the development of managed forms 1C 8.2 from the usual ones are significant. Therefore, we have gathered today to separately discuss the creation and modification of managed forms 1C 8.2.

Managed forms 1C 8.2

If you have been developing 1C configurations before, when you open the 1C 8.2 managed form editor, you will immediately be confused by the fact that it is impossible to influence the 1C 8.2 form with the mouse at all.

You cannot change the 1C 8.2 form, you cannot move the element, you cannot even view the properties of the field as before - by double-clicking the field on the 1C 8.2 form.

Now the basis for developing the 1C 8.2 form is not binding fields to coordinates on the form, but special settings. The system automatically generates a managed form 1C 8.2 based on these settings.

The settings consist of a list of 1C 8.2 form elements located in the editor in the upper left corner. The elements of form 1C 8.2 include:

• Requisites
• Commands (new concept 1C 8.2, may look like buttons or menu items)
• Groups (to combine details and commands).

Accordingly, the settings of these elements are not in the properties of the fields, but in the properties of these settings elements (right-click menu, Properties item).

How managed forms 1C 8.2 work

Working with managed forms 1C 8.2 is different for the user. They have more features, but are unusual for those who have been working with 1C for a long time.

First of all, the location of the usual elements on the form 1C 8.2 differs. The command bar is always at the top.

The left side of the command bar is customizable. It usually contains such typical buttons as Record and Post.

The right side of the command panel is the new standard menu of the 1C form All actions. This menu allows you to manage the 1C 8.2 form as you wish, similar to how the settings in the ACS report allow you to significantly change the appearance of the report.

Arbitrary menu items 1C All actions

Depending on whether this form 1C 8.1 belongs to one or another, the menu is filled with items that allow you to manage this object. For example, if it is a directory list form, then there will be commands such as Create or Edit.

Item Customize menu list 1C All actions

If there is a list on the 1C 8.2 form, then the menu has the command Set up list and Display list.
If the Output List command is already familiar to you - it allows you to save any list in 1C in Excel / print it, then the second command is new.

As you have already noticed, there are no more selection buttons on the lists command bar. Instead, the Find button appeared, to which work (as well as to the now disabled positioning of the cursor in the list when typing) - there are complaints.

The functionality of the Find button, of course, is not comparable to the selections, but they have not disappeared anywhere!
They are now under the Customize List menu item. Selection can now be done by any field, and in addition to it, sorting and conditional formatting can be done in the same way as it can be done in SKD reports.

Item Change menu form 1C All actions

The Change form item allows you to similarly change not only the list on the 1C 8.2 form, but also the 1C 8.2 form itself.

The user can independently enable or disable the visibility of fields on the 1C 8.2 form, width and height, activation of the default field when opening, etc.

Using managed forms 1C 8.2 and conventional forms 1C

By default, regular 1C forms are used in configurations for a thick (regular) 1C client, and managed forms are used in configurations for a thin and web 1C client. However, both forms of 1C can be used in any configuration, including simultaneously.

To do this, you must also enter the configuration properties (the top element in the configuration window).

In the configuration properties in 1C 8.2, two new checkboxes have appeared that allow you to enable non-standard use of 1C forms.

Creating Managed Forms 8.2

Adding a new form 1C 8.2 is done in the same way as before - using the Ins button on the keyboard or the Add button. To enter an existing one, double-click on it with the mouse.

By default, the form (regular or managed) that is set in the configuration will be created (see the Main launch mode property in the configuration properties). If you have enabled permission to use both types of forms in the configuration - in the form designer that opens immediately - you can select the type of form.

The constructor will prompt you to choose the type of form - the form of an element, a list. Here you can add or remove command bars on the form. Most often, these settings are left as is, by default.

A form filled by default opens - all the details of the 1C object that are added to it. You can tick off a specific list of required fields on the second tab of the constructor.

The form editor consists of three sections.

• In the upper left corner is a list of form elements. It consists of fields, commands, and groups that allow you to combine items. The list of commands can be viewed separately on the Command Interface tab.
• In the upper right corner there is a list of available form attributes and object attributes (open the cross next to the Object attribute).
• Below is a preview of the resulting form.

You can drag the available details to the left and it will become a form element (a field on the form).

If you need to add a button or menu item - on the right side of the Commands tab, you need to create a new Command. This is a wrapper for a function in a form module. In addition to specifying which function will actually be called, you can assign a representation - for example, a picture, as well as the dependence of visibility on a functional option.

Commands are also dragged to the left. If the parent is a command bar, then it will be a command bar button - otherwise just a button.

In the list of form elements (fields), you can not only drag the attribute of the object/form, but also simply add it (button Add or Ins). In particular, you can create a new form object - a Group.

The group can be a command panel (the cursor must be on the Form line). Then you drag commands into it and they become buttons.

The group can be "regular". Then it's a way to group fields both vertically and horizontally. The name of the group can be removed in the properties.

The group can be a panel (pages). The top added group is a panel, and nested groups of this type are pages. Fields are already being dragged onto the pages.

Unnecessary form elements are removed by deleting the form elements in the list.
The position of the field on the form is determined by the order in the list of elements (vertical) or by groups (horizontal). The width and height are set in the properties of the form element.

Form element properties have been greatly expanded and contain many useful things - both appearance control (choice and clear buttons), and checking default values.

The properties of the form itself, including its dimensions, are set at the root element of the form with the same name Form.

Event handlers (response to user actions) are now divided into two types. Old ones - as before, they are specified in the properties of the form and fields (for example, OnChange and OnOpening the form). New - have become commands and are used for menu items and buttons.

Klyuev V.V.

http://prof1c.kklab.ru

WORKING WITH SWITCHES

I ask you to take into account all users of the site service - I place the materials in the Beginners section !!!

8.2 Managed Forms

While studying the behavior of managed forms, programmers or interface developers face the question - where are the switches in managed forms and how to add them to the form. A trifle, but an unpleasantly much time is spent on such trifles, although this time could be spent on developing and optimizing the algorithm, rather than designing the form.

So, let's create an empty configuration to understand the issue, or choose any typical one.
Go to the group containing directories, and for the experiment add a new directory. I want to note that the configuration must have the main launch mode - Managed application.

So, let's create a new directory and add the props "Props1", with the type "Boolean"

Now go to the Forms tab and add a new form.

So, the managed form is created, now let's work with the form and find all the same where the switch is located.
Here is our form, and on it we see our props, but in the form of a checkbox

So what did we do wrong?
Let's look in the properties of the props to see if there is a switch to the view of the control.
And we see that the Switch Field is not here! (Where did we go wrong?

Apparently, the appearance of the control on the form depends on the data type, let's return to the form properties, namely the details tab and change the properties of our attribute - namely its type "Boolean", to the type "Number".

Now let's go back to the properties of the control and check if the View of the control has been added in its properties - - - And urra, we see the view there - Switch field.

Now look at the form, what we see:

We see - 3 default values, 3 radio buttons, but we need two of them, go again to the properties of the props, and look at the "Number of columns" properties there

For 2 - set Number of columns - 2.

This could stop a tired programmer a little)), but now both he and we know it!

8.2 Common forms.

Nervousness with switches in the usual forms.
There are such moments, and they happen) when you need to modify some ready-made form, in which there are already some switches, and you need to add another switch to this form. This is where some kind of tediousness arises, which takes a lot of time, and time not for programming code - but a waste of time in order to display these switches for the user.

So let's look at an example. There is such a document for adjusting receipts in 1C SCP - it definitely exists. We once needed to add switches to it so that slightly different postings for accounting were drawn. What is the problem, it would seem necessary, then it is necessary, we will do it. But this form already has 2 radio buttons.

This is how the form looks like in which we need to attach more switches

On the advanced tab, we'd like to place two more radio buttons. So the first action is boldly adding a new control to the place we need to insert it.

It would seem that everything is simple. We create a new attribute, with the type - "Number" and insert 2 switches, one of which will be able to write data to the attribute, and the other will not.

Add a new control - Switch, in the table with the number and description of switches, add Switch2, set Switch1 as the first in the group and press ok. We place the created controls on the form. Update the database configuration (F7) and run for debugging.

When executed (when creating a new document in 1C:Enterprise mode), we see that no matter how hard we try to click on Switch2, nothing happens. Elements do not work as they should. There is one feature here.
Return to the configurator. Select the item in the menu Form -> Setting the order of traversal ... (it is important that the form is open on the screen)

In order for our Switches to work, you need to break the automatic order and agree to the manual one. And put in the form so that our switches go - one after the other in order.

OK. Update the configuration and try running.
Great. Everything worked.

Optional - video (no sound, so everything is clear)

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

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

• When finalizing typical configurations to facilitate the subsequent update procedure. In this case, only the form module will be changed. Modules are much easier to update than a form.
• When implementing some general algorithms. For example, in the subsystem "Prohibition of editing the details of objects" for all objects connected to the subsystem, a button is created programmatically to enable the possibility of editing the details.
• When implementing some specific algorithms. For example, fields for editing additional details are created in the Nomenclature reference book.

In a managed form, you can programmatically add, modify, and remove:

• requisites;
• local commands;
• elements.

All these operations are possible only on the server.

Programmatic reshaping has limitations:

• You can only delete programmatically added attributes/commands/elements. You cannot programmatically delete objects created in the configurator.
• It is impossible to assign the attribute as the main one.

Changing form commands

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

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

Quantity ()

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

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

The Commands collection is available on both the client and the server. Modifying the collection (methods Add () and Remove () ) is possible only on the server. You can search and get the number of elements (methods Find () and Quantity () ) 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 title "Change History ...", which will call the handler DisplayHistory() . Creation is performed when the form is opened.

&On server
Procedure OnCreateOnServer(Failure, StandardProcessing)
Team = Commands. Add( "History of Changes");
Team . Action = ;
Team . Title = "History of changes...";
EndProcedure
&AtClient
Procedure Connected_DisplayHistory(Command)
// command actions
EndProcedure

The command handler must be located in the form and have the compilation directive &AtClient .

Changing form details

Reading the composition of the form attributes is performed by the function Get Details(< Путь >) that returns an array of the FormAttributes type. 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 credentials are returned.

Changing the details is performed by the method EditRequisites(<Added Details>, <Removable Details>) object ManagedForm. The options Added Details And Removable Details arrays with elements of the Form Requisite type are passed.

Attention!

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

Let's create a new form attribute named Buyer:

AddedAttributes = New Array;
Added Details. Add(New Form Attribute("Buyer", New TypeDescription ("DirectoryReference.Counterparties"), "Client");

// Changes in the composition of attributes
);

Changing Form Elements

To manage the composition of the elements of an object ManagedForm have a collection Elements. The collection has several methods:

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

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

Quantity ()

Find (< Имя >)

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

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

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

• GroupForm;
• TableForms;
• FormField;
• ButtonForms.

You can programmatically assign event handlers to form elements. For this purpose, the method SetAction(< ИмяСобытия>, < Действие >) .

Let's look at some of the most common practical examples of working with commands, attributes, and form elements.

Adding a command and its associated button:

// Create a team
Team = Commands. Add( "History of Changes");
Team . Action = "Connected_DisplayHistory"; // The form must contain a procedure with the specified name
Team . header = "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 its associated input field:

// Description of the added details
AddedAttributes = New Array;
Added Details. Add(New Form Attribute ("Buyer", New Type Description ( "Reference Link. Counterparties"), "Client" ));
// Changing the composition of attributes
EditAttributes(AddedAttributes);
// Creating an input field and linking to an attribute
Element = Items. Add("Customer" , Type("FormField" ));
Element . View = ViewFormFields. Entry field;
Element . PathToData= "Buyer" ;

Assigning an event handler to a form element:

ItemBuyer. SetAction("When it changes" , "Plug-in_BuyerOnChange");

&AtClient
Procedure Plugin_BuyerOnChange(Element )
// Event actions
EndProcedure

Attention!

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

Attention!

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