In the last lesson we looked at it 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 are the future of 1C. They differ from regular 1C 8.2 forms in that they are generated automatically 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 conventional 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 puzzled by the fact that it is impossible to influence the 1C 8.2 form at all with the mouse.

You cannot change the 1C 8.2 form, you cannot move an element, you cannot even view the field properties 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 controlled 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 (a new concept in 1C 8.2, may look like buttons or menu items)
• Groups (for combining details and commands).

Accordingly, the settings for these elements are not in the properties of the fields, but in the properties of these setting 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 possibilities, but are unusual for those who have been working with 1C for a long time.

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

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

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

Arbitrary menu items 1C All actions

Depending on whether this 1C 8.1 form belongs to one or another, the menu is filled with items that allow you to manage this object. For example, if this 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 Configure 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 out, then the second command is new.

As you have already noticed, there are no selection buttons on the list command panel anymore. Instead, a Find button appeared, the operation of which (as well as the currently disabled positioning of the cursor in the list when typing) has some complaints.

The functionality of the Find button is of course not comparable to selections, but they haven’t gone away!
They are now located in the Customize List menu item. Selection can now be done by any field, and in addition to it, you can do sorting and conditional formatting in the same way as you can do in ACS reports.

Item Change menu shape 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 regular forms 1C

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

To do this, you need to 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

Addition new form 1C 8.2 is produced 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 installed 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, which will immediately open - you can select the type forms.

The designer will prompt you to select the type of form - element form, list form. Here you can add or remove command panels on the form. Most often these settings are left as is, by default.

A form opens, filled out by default - all the details of the 1C object that exist have been added to it. You can tick the specific list of required fields on the second tab of the designer.

The form editor consists of three sections.

• In the upper left corner there is a list of form elements. It consists of fields, commands and groups that allow you to combine elements. 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 details and object details (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 the form module. In addition to specifying which function will be called, you can assign a representation - for example, a picture, as well as the dependence of visibility on the functional option.

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

You can not only drag and drop object/form attributes into the list of form elements (fields), but also simply add them (Add or Ins button). In particular, you can create a new form object – 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 this is a way of grouping fields both vertically and horizontally. The group name can be removed in the properties.

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

Unneeded form elements are removed by deleting 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 using groups (horizontal). The width and height are set in the properties of the form element.

The properties of the form element have been significantly expanded and contain many useful things - such as controls appearance(select 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 (responses to user actions) are now divided into two types. Old – as before, they are indicated in the properties of the form and fields (for example, OnChange and OnOpening the form). New ones have become commands and are used for menu items and buttons.

We all know that the 1C company had many different versions of the 1C platform, we will now be interested in some of them latest versions at the time of writing this article, these are versions 1C 8.2 and 1C 8.3. If you have had to work in both of these versions, then you most likely noticed differences in the interfaces of these versions, for users they differ only in appearance. Essentially a choice regular or managed application tells the system which forms to display to run, regular or controlled, as well as which application client will be used by default, thick or thin. For more detailed information on clients, read the article “What are thick and thin clients in 1C, as well as their differences.”

Regular 1C application (regular forms, regular interface, version 1C 8.2)

In 1C 8.2 it is possible to work only with regular forms, in regular application mode. The image below shows the database in the “regular 1C application” operating mode (regular forms).

Managed 1C application (managed forms, managed interface, version 1C 8.3)

On the 1C 8.3 platform we can work with both regular forms (in compatibility mode) and managed ones. Moreover managed forms have two types of display, this is standard and taxi. An example of a 1C 8.3 configuration with standard managed forms is shown below, and after it the “Taxi” interface is shown.

What is the difference between a regular and managed 1C application?

As we have already found out a regular application and a managed application are these types of launching a 1C program. Moreover, depending on the value of the 1C launch type ( regular or managed application), a specific interface will be loaded by default ( regular or managed forms), hence there are so many synonyms for this concept. We would like to note that the differences in the interfaces are quite significant; the managed interface has been completely redesigned. In principle, these are all the differences that ordinary users of the 1C program see. As for programmers, the managed interface requires writing modified code, because development is already carried out in 1C 8.3, and not in 1C 8.2, hence all the ensuing consequences. The code must also be divided into client and server; this is indicated using the appropriate directives in the configurator.

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 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...";
EndProcedure
&OnClient
Procedure Connectable_DisplayHistory(Command)
// command actions
EndProcedure

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 (“DirectoryLink. 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 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
EndProcedure

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.

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 what is it for? A 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, and the information necessary for the user is also displayed on the form.

The main task of a developer of any form (managed or regular) 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.

Issues of working with managed forms in particular and with a managed application in general are discussed in detail in the book “Development Fundamentals in 1C: Taxi. Managed Application Development in 12 Steps". This book will be a real help for those who are just starting to get acquainted with managed application development.

The book “Basics of Development in 1C: Taxi” is perfect 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);

Promo code for a 15% discount - 48PVXHeYu

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 easily and quickly 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 a clear and in simple language- for a beginner.
6. The book is sent to email in PDF format. Can be opened on any device!

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.

Klyuev V.V.

http://prof1c.kklab.ru

WORKING WITH SWITCHES

Please take into account all users of the site service - I post materials in the Beginners section!!!

8.2 Managed forms

While studying the behavior of managed forms, programmers or interface developers are faced with the question of where the switches are in managed forms and how to add them to the form. It’s a small thing, but it’s unpleasant that a lot of 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 question, or choose any typical one.
Go to the group containing directories, and for the experiment add new directory. I would like to note that the configuration must have the main launch mode - Managed Application.

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

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

So, the controlled form has been created, now let’s work with the form and find where the switch is located.
Here is our form, and on it we see our props, but in the form of a flag

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

Apparently, the type of control on the form depends on the data type, let’s go back 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 whether the View of the control has been added to its properties - - - And hurrah, we see the view there - Switch Field.

Now look at the form, what we see:

We see - 3 default values, 3 switches, but we need two of them, go again to the properties of the attribute, and look at the “Number of columns” properties there

For 2 - set the Number of columns - 2.

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

8.2 Regular forms.

Boring with switches in usual forms.
There are such moments, and they do happen) when you need to modify some ready-made form, which already has 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 not time for programming the 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 UPP - it definitely exists. We once needed to add switches to it so that slightly different wiring would be drawn for accounting. What is the problem, it would seem that we must, we must, we’ll do it. But this form already has 2 radio buttons.

This is what the form looks like in which we need to add more switches

On the Advanced tab, we would like to place two more radio buttons. So, feel free to add the first action new element control in 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 element - Switch, add Switch2 in the table with the number and description of switches, set Switch1 first in the group and press OK. Place the created controls on the form. We update the database configuration (F7) and run it for debugging.

When executing (when creating a new document in 1C:Enterprise mode), we see that no matter how much we try to click on Switch2, nothing happens. The elements don't work as they should. There is one trick here.
Return to the configurator. Select the menu item Form -> Set traversal order... (it is important that the form is open on the screen)

In order for our Switches to work, you must break the automatic order and agree to a manual one. And put it in the form so that our switches go one after another in order.

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

Additionally - video (without sound, so everything is clear)