Switches, regular application, managed forms. Programmatically adding and changing elements of managed forms Switch in 1s 8.3 managed forms

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 add a new directory to experiment. 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 properties of the form, 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 ordinary 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 entries for accounting would be drawn. 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 the first step is to boldly add a new control element to the place we need and 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)

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 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...";
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 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
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 processing with examples of programmatic searching and changing details, commands and elements of a managed form.

I read many forums, and nowhere did I see an intelligible description of working with the “Switch”. So I decided to write it myself.

In MY opinion, the most common mistake is the misconception about the “Switch”. When you place several “Switches”, for example 3, on a form, many people believe that in the program logic these are 3 different objects that influence each other. But, in fact, the program perceives all 3 “Switches” as one object. And choosing one of them changes the state of this object. Let's look at an example.

1. Create three radio buttons on the form. For convenience, we will not change the names.
2. Highlight Switch1. In its properties, in the “BASIC” section, check the first in group box. “VALUE TYPE” select a number. (Next we’ll look at why exactly the number). The length can be set to one, but this does not provide any special functionality.
3. Select “Switch2” in the “SELECTED VALUE” column and put 1.
4. Select “Switch3” in the “SELECTED VALUE” column and put 2.
Essentially, with actions 3 and 4, you set a flag that will change when you select the corresponding “Switch”. In “Switch1” the default “SELECTED VALUE” is zero.
5. Check whether the switches are in the “WALKING ORDER” in order. (for example: 13,14,15)(Fig. 1). a continuous order of traversal by switch is required. The auto-bypass order is enabled (positions are numbered 13, 15, 20) (Fig. 2) in this case, the switches under each other will not work. You should remove the use of auto-order from the form and, if necessary, manually specify the order.

How to set the traversal order for details. While in the form, in the "Dialog" menu, you need to uncheck the "Automatic traversal order" checkbox. After this, you can either use “Dialog” -> “Setting the traversal order”, or “Dialog” -> “Travel order”. The second method seems to me to be the most convenient. With this method, a picture appears for each prop with the prop number. All you have to do is click on the numbers, selecting the details in the order you need.

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

6. Select “Switch1” and write the procedure we need for it.
For example:

EF=FormElements; If Switch1=0 Then EF.Payment Status.Value = "Unpaid"; OtherwiseIf Switch1=1 Then EF.Payment Status.Value = "Partially paid"; OtherwiseIf Switch1=2 Then EF.Payment Status.Value = "Paid"; endIf;

7. Press F7. Press F5. Let's see everything is working, we're great. And the big BOSS gives us a bonus.

EXPLANATION FOR THE CODE

Why is there "Switch1" everywhere? Since it has already been said, the program perceives all three elements as one, and since “Switch1” is the first in the group, then the program perceives it as the entire element. If you make “Switch2” the main one in the group, then the correctness check will need to be carried out according to "Switch2".
Well, where does "0", "1", "2" come from? We set those values that the object takes when switching “Switches” in paragraphs 3 and 4.

AFTERWORD:

This code is given as an example of working with switches. In my opinion, this is more clear and understandable. But it’s worth mentioning that in “Value Type” you can immediately select what you need - a predefined value from a directory, an enumeration, for example, or a string value. That is, in the above example, it was possible to immediately assign the switches as values not 0,1,2, but immediately “Unpaid”, “Partially paid”, “Paid”. And then the code will be reduced to one line:

Form Elements.Payment Status.Value = Switch1;

The result will be the same.

//////////////////////////////////////////////////////////////////////////////////////////

Switches in controlled forms (UF) have been made more intuitive.

When creating a Switch, you need to remember the duo Attributes, Form Element.
First of all, you need to create Form Attributes. You set the type of the attribute to what values your switch will accept. I chose the String type. Here you have two options: if you created an Object attribute, then the value accepted by your switch will be saved in the database, if you simply add to the list of form details, then the result accepted by your switch will not be saved.

Next, drag and drop the Attributes we need into Form Elements. When creating a form element, the element in the "View" properties will have the type "Input Field". Select "Field switch" from the list. As a result, you will get a form something like this:

We fill in the title of the Form Element, color, font, location and other beauties to your taste.
There is an item in the properties of the form element. “Selection List” - in it you enter the Values that your switch will take when selecting one or another item. In my example, I added lines with the values “Record”, “Cancel Post”, “Post”.

After this, your switch is ready for use.

Depending on whether your switch is an Object attribute or a Form attribute, you use the following code to get the value stored in it:

SwitchFormElementFormElement // access directly if this is an attribute of the Object form.SwitchInsideDB // access through the Object element. to your details.

1C are created automatically by the system when using the application solution. They are the basis for presenting (displaying) information in the 1C:Enterprise system.

Structure of form 1C

Form B is a logical description of the composition of the form. elements describes what the form will look like. The placement of form elements is performed automatically by the system when it is displayed.

The displayed part of the form (visible to the user) is described as a tree that includes form elements (see the figure below, the “Form elements” field):

group including other elements,
input fields,
checkboxes,
switches,
buttons,
tables that include column elements, etc.

"Elements of 1C form"

[collapse]

A group of form elements can be represented as

panel with frame,
panel with pages (bookmarks),
the page itself,
command panel.

All functionality of the form is described as follows:

details (data the form works with);
commands (actions performed).

Customizing the appearance of a managed form

Customizing the appearance of a managed form by the user

The appearance of a managed form can be customized at the user level. For this feature, in the form actions there is a command “More” - “Change form” (managing only those form elements that are defined at the development stage or according to standard rules for form autogeneration).

"More" - "Change shape"

Command "More" - "Change shape":

After clicking “Change form”, the 1C form settings window is displayed:

[collapse]

In addition, in user mode it is possible to:

change the order of forms, move them from one column to another (if the desktop is organized in two columns), but you cannot change the number of columns on the desktop;
display information in the form of separate windows (when calling a navigation command, you need to hold down the Shift key).

If sections are used, then when you call a command in the navigation panel, the corresponding list is displayed in the work area, replacing the previous contents of the work area.

Customizing the appearance of a managed form by a developer

The developer can influence the arrangement of elements with various settings. It can determine the order of elements, specify their width and height, and also use:

commands of the form itself;
global commands used throughout the configuration;
parameterizable commands that will open other forms based on the specific data of the current form.

Figure (change of 1C form by developer)

[collapse]

When developing Form 1C you must:

In the form editor, include the necessary details and commands in the form;
create form elements that display them, determine the order of the elements, specify the width and height (if necessary);
arrange elements into groups (if necessary).

Use role-based visibility settings in form elements (viewing and editing details by , custom visibility of form fields by role, using commands by role) in the case of a large number of roles in the configuration (from several dozen). Instead, the following approaches should be followed:
- when there are strong differences in the appearance and functionality of the form depending on the presence of certain roles for the user – develop separate forms, specialized for a specific set of user rights;
- with minor differences - perform permission checks in code. It should be borne in mind that programmatic visibility control can reduce the speed of opening the form, which must be taken into account when choosing between the proposed approaches.
Use role-based visibility settings in the configuration command interface, the main section command interface, and the start page work area. Instead, you should set permissions on sections of the command interface and objects included in the command interface or workspace. This makes the behavior of the managed interface more predictable for the user, and also makes it easier to investigate errors.

For more detailed information on working with forms, see the course “Working with forms in 1C:Enterprise 8.3”, http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=161.