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, it is provided software creation buttons to enable the ability to edit 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 ()

To 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 ()

To 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"), "Customer" ));
// 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.

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?

It seems that 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 there for the "Number of columns" properties

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 not time 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 much 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, it is necessary to break automatic order and settle for manual. And put in the form so that our switches go - one after the other in order.

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

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

1C are created automatically by the system when using applied solution. They are the basis for the presentation (display) of information in the 1C:Enterprise system.

Form 1C structure

Form in is a logical description of the composition of the form. elements describes how the form will look like. Placement of form elements is performed by the system automatically 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):

• a group that includes other elements,
• input fields,
• flags,
• switches,
• buttons,
• tables that include column elements, etc.

"Elements of form 1C"

[hide]

A group of form elements can be represented as

1. frame panel,
2. panel with pages (bookmarks),
3. actual page,
4. command panel.

The entire functionality of the form is described as:

• details (data with which the form works);
• commands (actions to be performed).

Customizing the Appearance of a Managed Form

Customizing the Appearance of a Managed Form by the User

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

"More" - "Reshape"

Command "More" - "Change shape":

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

[hide]

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 the navigation command, hold down the Shift key).

If sections are used, then when a command is called in the navigation bar, the list corresponding to it is displayed in the workspace, replacing the previous contents of the workspace.

Customizing the Appearance of a Managed Form as a Developer

The developer can influence the arrangement of elements various installations. 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 given the specific data of the current form.

Figure (change form 1C developer)

[hide]

When developing Form 1C, you must:

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

1. Use role-based visibility settings in form elements (viewing and editing attributes by , custom visibility of form fields by roles, use of commands by roles) in case a large number roles in the configuration (from several dozen). Instead, the following approaches should be followed:
   • with 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. At the same time, it should be borne in mind that programmatic visibility control can reduce the speed of opening a form, which must be taken into account when choosing between the proposed approaches.
2. Use role-based visibility settings in the configuration command interface, the main section command interface, and the workspace start page. Instead, you should use the permissions setting on the command interface sections, and the objects included in command interface or to the workspace. This improves the predictability of the behavior of the managed interface for the user, as well as making it easier to troubleshoot errors.

More detailed information for working with forms in the course "Working with forms in 1C:Enterprise 8.3", http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=161.

1. Input field
2. Checkbox
3. Switch

Entry field

As a rule, the input field is associated with the attribute of the object and reflects its data. This is perhaps one of the most common elements, it has several ways to select a value:

Selecting from a list (SelectFromListMode)

Selection from another form (Select button)

Control buttons

The implementation of the above examples does not require significant effort on the part of the developer so. for example, for the list mode, it is necessary to fill the list of the element with values, to select from another form, it is enough just to bind the control element with the data of the dictionary. But for the control buttons, you will need to write more code to handle pressing each button, although it will not be great:

Procedure pvNomenclature SelectionRegulation(Element, Direction, StandardProcessing)
//Select data for the input field
// in this case reference Nomenclature
Request = New Request;
Request.Text=
"CHOOSE
| Nomenclature.Reference As Item
| FROM
| Directory. Nomenclature AS Nomenclature
|ORDER BY
| Nomenclature.Code";
TZNomenclature = Request.Execute().Upload();

//we are looking for the current element of the directory specified in the input field
CurrentElement = TKNomenclature.Find(Element.value);

If CurrentItem = Undefined Then
// if the element is not found then set the index number
// outside the table of values, because the very first element in
// value table has index 0
CurrentIndex = -1;
Otherwise
// if the element is found, get its index
TekIndex = T3Nomenclature.Index(TekElement);
EndIf;

// calculate new index depending on button click
// minus in front of the variable The direction is in order to
// clicking on the top arrow showed the element above
// and therefore with a lower index
NewIndex = CurrentIndex-Direction;

// get the number of elements in the directory
// subtract one because all collections in 8.1 start at 0
Number of Items = TK Nomenclature. Quantity () -1;

If NewIndex< 0 Или НовИндекс >Number of Elements Then
// if the index is outside the table of values ​​when changing
// i.e. its number is greater than the largest index or less than 0 then
// do not change the value and inform the user about it
alert("You have reached the limit of the directory");
Otherwise
// assign a new value, "Product" is the name of the value table column
Element.value = TKNomenclature.Get(NewIndex).Product;
EndIf;

EndProcedure

Checkbox

In most programs, the checkbox is used to display two states: checked, unchecked. In 1s, the checkbox has three states, in the third state the checkbox is displayed - as set and shaded. The three states are available only if the flag data is a number, with the states having the following meanings:

Switch

The switch is used to select one value from a small number of possible (preferably no more than five), while the values ​​\u200b\u200bcannot be combined, For example: suitable for choosing the gender of a person. Another example: let's say a company gives one of 3 discounts for a product, while the discounts are not cumulative:

In this case, the convenience of using radio buttons may lie in the fact that each of them can have some value, which is set in the "Selectable Value" property. And then "5% Discount" can store the value 5 or 0.05.

There are three important things to keep in mind when using radio buttons:

The first radio button must have the "FirstInGroup" property (in this example, it is the "5% Discount" radio button).

Switches related by meaning to one group should go in succession in the setting of the bypass order, without interruption by other form elements. The order of the bypass is set from the menu "Form -> Setting the order of the bypass", for this example it looks like this:

1. The type of the selected value is set by the switch having the "FirstInGroup" property.