1c managed forms. Programmatically Adding and Modifying Managed Form Elements

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). forms.

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.

We all know that the 1C company had many different versions of the 1C platform, we will now be interested in one of the latest versions at the time of this writing, these are versions 1C 8.2 and 1C 8.3. If you have had to work in both of these versions, then you are most likely noticed differences in the interfaces of these versions, for users they differ only externally. Essentially, the 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 information on clients, see the article "What is a thick and thin client in 1C, as well as their differences."

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

In 1C 8.2, only work is possible with normal forms, in normal application mode. The image below shows the base in the "regular 1C application" mode of operation (regular forms).

Managed application 1C (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. And managed forms have two types of display, these are 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 a managed 1C application?

As we have already found out a regular application and a managed application are such types of launching a 1C program. Moreover, depending on the value of the type of launch 1C ( regular or managed application), the 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, this is 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 underway 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 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.

The main problem is that for 10-15 years a lot of code has already been inflated for ordinary forms. Nobody wants to rewrite it all on the client-server + a lot of people are trained to work with the interface. The mandatory transition to BP 3.0 from next year creates panic in the minds of developers and accountants. Feedback will be very impartial. In addition, the bar for entering the profession is rising, programming is more difficult, typical ones have become even more difficult. What is the value of the new algorithm for carrying out in standard documents. UV looks great when you have 2-3 buttons on documents, UV is great for working on mobile devices, but 0.01% of companies use it. You will have to switch if 1C does not come up with something new, but it will be long and painful for everyone. And the companies themselves will have to pay the money.

I, too, so far only experience negative from managed forms, here are the other disadvantages of the innovation:

• Nothing? Well, I came across a couple of times, for example, write and attach an external oven form to the conf, processing there is a whole epic, there are a lot of instructions on the internet and code pages should.
  on a thick client, one procedure with parameters i.e. development is a matter of minutes.
  and the brakes are thin to the naked eye
• As for being able to prepare managed forms - this is art for the sake of art, but what is the practical meaning, especially for the file version?
• I sculpted in UV for 3 years, but now I switched back to simple forms, and believe me, this transition was psychologically quite difficult to make, but this is my conscious choice, because what 1s offers on UV is completely UG .... maybe in a couple of years 1c will make a breakthrough, but now she is only looking for the place where to make this breakthrough ...
• UVs in the configurator take much longer to open.
  After that, opening forms in 8.1 - how to transfer to a plane from a truck!
• There is more hemorrhoids for everyone, users are shocked by the new interface (not everyone admits, but they are dumber much more and on smaller details), half of the programmers have become unsuitable for professionals, it has become harder for an average specialist to find a job, and how to produce a quality product. And the coolest marketing theme of UV is that everywhere they soar that the transition is a simple update, only something everyone forgets that from the beginning you need to catch up with the latest releases! But in general, I like the idea!
• I don't know, my practice shows the opposite. Where bukhs in simple forms have been hitting for several years on the machine for several years now, in the new UV standard every month begins “fuck, where is 1C now after updating this button and why it doesn’t work now”, which, you see, does not add speed.
• - more code
  - the code has become more complicated
  - refinement of standard ones - much more difficult
  - users to whom I gave UT11 did not find any advantages compared to 10.x
  - but they found the brakes and the lack of some functions such as search (for some reason, they wanted to search with back and forth and not selection)
  my opinion - too big sacrifices for the sake of the web client and tablets. And personally, I have not yet seen real work with a web client at all, who needs to successfully use remote access
• Client-server bedlam should give performance gains and scalability, while at the cost of increased coding.
  However, not everyone showed an increase, hence the disappointment. And at the same time, everyone was bent on the costs of coding.
  P.S. Actually, I like managed ones, I calmly draw on them. But the typical ones have become perverted.
• At home (normal computer) I conduct my bookkeeping for IP.
  8.3, BP3, in checkers. The main impression is that I do not work, but I wait all the time. hemorrhoid response. SALT on the account is formed as a simple goof - the impression is that the account card for the year in a megaholding.
• UT11 is a wild brake, horror and a nightmare in general.
  UT10 flies compared to UT11.
  Regarding UV - bugs are teeming for years, everything is crooked, columns never fit on one screen, stretching is terrible in many cases.
  And I can still spank a lot of minuses, I probably won’t say anything from the pros. They simply don't exist.
  Firms specifically hit with these forms, since development costs more, there were no specials and there are no normal ones.

There are few advantages, but they certainly exist ...

pros:

there is an answer for a long time, which was given by the UE:

cross platform client

• work on bad communication lines
• the ability to work through a browser (without installing a client)