Switches, regular application, managed forms. Radio buttons, regular application, managed forms Design patterns or generational wisdom

The main problem is that over 10-15 years a lot of code has already been compiled for ordinary forms. Nobody wants to rewrite all this on the client-server + a lot of people are trained to work with the interface. The mandatory transition to BP 3.0 starting next year is creating panic in the minds of developers and accountants. The feedback will be very unpleasant. In addition, the bar for entering the profession is rising, programming is more difficult, and standard ones have become even more difficult. What is the cost of the new algorithm in standard documents? UV looks great when you have 2-3 buttons on documents, UV is great for working on mobile devices, but only 0.01% of companies use it. You will have to switch if 1C doesn’t 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, have only experienced negative things from controlled forms so far, here are some more disadvantages of the innovation:

Nothing? Well, I came across this a couple of times, for example, writing and attaching an external printing form to the ZUP conf, processing there is a whole epic, full of instructions on the Internet and pages of code should.
on a thick client there is one procedure with parameters i.e. development is a matter of minutes.
and the brakes are thin visible to the naked eye
As for being able to prepare manageable forms - this is art for art's sake, but what is the practical point, 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 1c offers in UV is completely UG…. maybe in a couple of years 1c will make a breakthrough, but now she is just 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 is like transferring from a truck to a plane!
There are more problems for everyone, users are shocked by the new interface (not everyone admits it, but they are much more stupid about smaller things), half of the programmers have become unsuitable for professionalism, it has become harder for the average specialist to find a job and how to produce a quality product. And the coolest marketing theme of UV is that they soar everywhere that the transition occurs with a simple update, but everyone forgets that from the beginning you need to catch up with the latest releases! But in principle I like the idea!
I don’t know, my experience shows the opposite. Where the booms in strict forms have been hitting automatically for several years now, in the new UV standard ones every month it starts “why, where is 1C now after updating this button and why now it doesn’t work,” which, you see, does not add speed.
- there is more code
- the code has become more complex
— modification of standard ones is much more difficult
- the users to whom I gave UT11 did not find any advantages compared to 10.x
— but they found some slowdowns and a lack of some functions such as search (for some reason they wanted forward-backward search and not selection)
My opinion is that the sacrifices are too big for the sake of the web client and tablets. Moreover, 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 provide an increase in performance and scalability, while at the same time the costs include an increase in coding.
However, not everyone experienced an increase, hence the disappointment. And at the same time, everyone was bent on coding costs.
P.S. Actually, I like the controlled ones, I calmly draw on them. But the typical ones have become perverted.
At home (normal computer) I conduct my drinking according to individual entrepreneurs.
8.3, BP3, checkered. The main impression is that I don’t work, but wait all the time. hemorrhoidal response. The SALT for the account is formed as simply astonishing - it seems like an account card for the year in a mega-holding.
UT11 is a wild brake, horror and generally a nightmare.
UT10 flies compared to UT11.
Regarding UV - bugs have been infested for years, everything is crooked, columns never fit on one screen, stretching is terrible in many cases.
And I can still list a lot of minuses, but I probably won’t say anything about the pluses. They simply don't exist.
Firms specifically ended up with these forms, because development costs more, there were no specials and there are no normal ones.

There are few advantages, but of course they exist...

pros:

The answer has been there for a long time, what the UP gave:

cross platform client

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

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 commands;
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 have a collection Teams

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

Quantity ()

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

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

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

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

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

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

Changing form details

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

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

Attention!

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

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

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

// Changes in the composition of details
);

Changing form elements

To control the composition of elements of an object ManagedForm have 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 = ViewFormFields. Entry field;
Element . PathToData= "Buyer" ;

Assigning an event handler to a form element:

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

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.

No complex technical terms;
Over 600 pages of practical material;
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 “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 picture (screenshot).
Collection of tasks for home study.
The book is written in clear and simple language - for a beginner.
The book is sent by 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.

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 a 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 capabilities, 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

Adding a new 1C 8.2 form 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 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 form element properties have been significantly expanded and contain many useful things - both appearance control (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.