1c make the form element required. Programmatically Adding and Modifying Managed Form Elements

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

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.

And Data Transfer Object to code structuring, managed form in 1C 8.2 environment.

Introduction

In 2008, a new version of the 1C: Enterprise 8.2 platform became available (hereinafter referred to as the Managed Application), which completely changes the entire layer of working with the interface. This includes the command interface, and forms, and the window system. This not only changes the user interface development model in the configuration, but also proposes a new architecture for the separation of functionality between the client application and the server.
A managed application supports the following types of clients:

• Thick Client (Normal and Managed Launch Mode)
• Thin client
• Web client

• Declarative, not "by pixels" description of the structure. The specific placement of elements is done automatically by the system when the form is displayed.
• All functionality of the form is described in the form details and commands. Details are the data that the form works with, and commands are the actions performed.
• The form is executed both on the server and on the client.
• In the context of the client, almost all application types are not available, and accordingly it is impossible to change the data in the infobase.
• For each method or form variable, it must be specified compilation directive A that specifies whether the execution location (client or server) and access to the form's context.

• &AtClient
• &On server
• &OnServerWithoutContext
• &At the ClientAt the ServerWithoutContext

All further discussions will be about the right side of the illustration, about how to structure the module code and what principles will allow you to implement effective client-server interaction.

Let's define the problem

Consider the code structure (form module) in several forms of the same typical configuration and try to find patterns.
Under the structure, we mean sections of code (most often these are comment blocks) allocated by the developer for grouping methods and directives for compiling these methods.
Example 1:
Event handler section Method - on the client Method - on the server Method - on the client Section of service procedures and functions Input control auxiliary functions
Example 2:
Service procedures and functions Payment documents Valuables Event handlers
Example 3:
Service procedures on the server Service procedures on the client Service procedures on the server without context Header event handlers Command event handlers
Example 4:
General-purpose procedures Form event handlers Procedures of the "contact information" subsystem
In fact, the code structure is missing, or to put it mildly, it is similar to what was in forms 8.1:

• Non-informative words "General, Service, Auxiliary."
• Timid attempts to separate client and server methods.
• Often methods are grouped by interface elements "Working with tabular part Products, Contact information".
• Arbitrary arrangement of methods and code groups. For example, Event Handlers may be at the top in one form, at the bottom in another, not highlighted at all in a third, and so on.
• And let's not forget that this is all within the same configuration.
• Yes, there are configurations in which the words “General, Service, Auxiliary” are always in the same places, but ...

Why do you need a code structure?

• Simplification of maintenance.
• Simplify learning.
• Fixing general/important/successful principles.
• …your option

Why does the existing development standard from 1C not help?

• Minimize the number of server calls.
• Maximum computing on the server.
• Non-context server calls are faster than context calls.
• Program with client-server interaction in mind.
• etc.

Design patterns or generational wisdom

• Remote Facade(hereinafter Remote Access Interface)
• Data Transfer Object(hereinafter referred to as Data Transfer Object)

• … each object potentially intended for remote access must have low granularity interface, which will minimize the number of calls required to perform a particular procedure. … Instead of requesting an invoice and all of its points separately, it is necessary to read and update all points of the invoice in one call. This affects the entire structure of the object...Remember: the remote access interface does not contain domain logic.
• ... if I were a caring mother, I would definitely tell my child: “Never write data transfer objects!” In most cases, data migration objects are nothing more than bloated fieldset… The value of this disgusting monster lies solely in the possibility transmit multiple items of information over the network in one call- a technique that is of great importance for distributed systems.

Examples of templates in the 1C platform

In the context of a managed form, a set of "Data Transfer Objects". Can be distinguished systemic and developer-defined.
System ones model an application object on the client, in the form of one or more form data elements. You cannot create them outside of binding to the form details.

• DataFormsStructure
• DataFormsCollection
• DataFormStructureCollection
• DataFormsTree

• ValueVDataForm()
• FormDataToValue()
• CopyFormData()
• ValueVFormProps()
• FormAttributeToValue()

Data migration objects, whose structure is defined by the developer, are a small subset of the types available on both the client and the server. Most often, as parameters and results of methods of a "coarse" interface, the following are used:

• Primitive types (string, number, boolean)
• Structure
• Conformity
• array
• Links to application objects (unique identifier and text representation)

Structuring the code

• Clear separation of client and server code. Let's not forget that at the time of execution these are two interacting processes, in each of which the available functionality differs significantly.
• A clear selection of the remote access interface, which server methods can be called from the client, and which cannot? The names of the remote interface methods begin with the prefix "Server". This allows you to immediately see the transition of control to the server when reading the code, and simplifies the use of contextual hints. Note that the official recommendation (ITS) suggests naming methods with postfixes, such as ChangeOrderStatusOnServer(). However, to reiterate, not all server methods can be called from the client, and so logical accessibility is more important than compilation location. Therefore, with the “Server” prefix, we mark only the methods available to the client, the example method will be called ServerChangeOrderStatus().
• Readability. A matter of taste, we accept the order when the module begins with the procedures for creating a form on the server and remote access methods.
• Maintainability. The place to add new code must be clearly defined. An important point, the method stubs automatically created by the configurator are added to the end of the module. Since form element event handlers are most often created automatically, the corresponding block is placed last so as not to drag each handler to another place in the module.

• Graphical option - clearly shows the main flow of execution.
• The text option is an example of a template design for quickly inserting a structure into a new form module.

//////////////////////////////////////////////////////////////////////////////// // <(c) Автор="" Date=""/> // <Описание> // // /////////////////////////////////////////////////// ////////////////////////////// // MODULE VARIABLES //////////////// /////////////////////////////////////////////////// ////////////// // ON THE SERVER //******* EVENTS ON THE SERVER ******* &On The Server Procedure On CreationOn The Server(Failure, StandardProcessing) //Insert the contents of the handler EndProcedure //******* REMOTE ACCESS INTERFACE ******* //******* BUSINESS LOGIC ON THE SERVER ******* ///////// /////////////////////////////////////////////////// ///////////////////// // COMMON CLIENT AND SERVER METHODS //////////////////////// /////////////////////////////////////////////////// //////// // ON THE CLIENT //******* BUSINESS LOGIC ON THE CLIENT ******* //******* COMMANDS ******* //******* EVENTS ON THE CLIENT ****** //////////////////////////////// ///////////////////////////////////////////////// / / MAIN PROGRAM OPERATORS

Related questions

• Options for implementing the remote access interface. Asynchrony, granularity...
• caching. 1C made an unfortunate architectural decision, introducing caching only at the level of calling methods of common modules and not providing control options (up-to-date time, reset on demand).
• Implicit server calls. Do not forget about technological features, many "harmless" operations on the client provoke the platform to access the server.

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 to simply 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 setting the order of bypass, without interruption by other form elements. The traversal order is set from the menu "Form -> Traversal order settings", for this example it looks like this:

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

Interface development in 1C consists of two parts - the development of a menu or desktop and the development of 1C screen forms. The windows with which the user works in 1C are called 1C screen forms or simply 1C forms.

Users in the program work with 1C forms. Moreover, users see only 1C forms. Therefore, from the point of view of the convenience of working in the program, this is one of the important elements. At the same time, you can kill more time for developing the 1C form than for programming the most complex algorithm.

A common mistake programmers make is trying to draw everything to their liking. Make the background blue and the captions green. Or yellow on black. Or how he likes it in some other favorite program of his.

Unfortunately, this approach is erroneous, since users are used to working with standard 1C forms, which are the majority in the configuration. Drawing your own bike, marking it with Courier inscriptions like “Copyright Vasya Pupkin” is clearly bad form.

Now we will go through a brief educational program on drawing 1C forms.

What is Forms 1C

Form 1C is a method of presentation to the user. Typically, a form is a series of fields that need to be filled in and a set of buttons (menu commands) to control. Form 1C is available for most 1C objects.

The 1C thick client uses "regular" 1C forms. This means that the programmer simply draws the 1C form with the mouse, just as it is done in Visual Studio and other frameworks.

1C thin client and 1C web client use managed 1C forms. This means that their size, form 1C and the location of the fields on them cannot be changed with the mouse. They are generated automatically based on the settings. We will talk about 1C managed forms in the next lessons.

Most forms of 1C typical configurations in 1C have their own, typical representation, familiar to the user.

How forms 1C work

The logic (order) of the user's work in 1C is as follows:

Thus, the user always works with 1C forms, starting with the 1C list form and moving on to the 1C element form. If the programmer did not draw the forms, then 1C generates the forms by default. They are naturally devoid of ideal beauty and perfection, but they allow them to work.

The automatically generated 1C list form usually contains a minimum of fields (code / name and date / number, respectively). The auto-generated element form usually contains all the fields (requisites) listed from top to bottom.

The task of the 1C form is to open and wait for user actions. In action, react. Thus, event handlers form the basis of the 1C form module. These are functions that are called when the user performs some action on the 1C form.

Where are the forms 1C

In the 1C Enterprise mode, when you select almost any 1C object (reference book, document, report, processing, etc.), you will see a form for this object.

In the configurator, in the configuration window, select the object you need, expand its branch to see the Form 1C sub-branch.

Another option is to open the object editor (twice with the mouse or put the cursor and Enter) and go to the Form 1C tab.

Here is a list of forms 1C. One of the added 1C forms can be added as a default form (1C list form, 1C element form, and so on).

Creation of 1C forms

To add a new 1C form, you need to click the Add button (Ins on the keyboard). To enter an existing one, double-click on it with the mouse.

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

The 1C form opens, filled in by default - 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.

Unnecessary details can be removed. To do this, select one or more fields and press Del.

To move other attributes to the vacated space, select them in the same way and drag them with the mouse.

To add new details to the 1C form, click the button on the Data Placement panel (menu Form / Data Placement), check the boxes for the elements you want to add, as well as the checkboxes “Insert labels” and “Place automatically”.

Alternatively, you can simply add a control by clicking the corresponding button on the panel below or by selecting Form/Insert Control from the menu. Double-click on the control (field) with the left mouse button and its properties will open. The "Data" property contains the attribute name. Here it can be changed or assigned.

The control's properties also contain checkboxes to control the appearance of the control. With the help of checkboxes, you can enable and disable the select, drop-down, clear, visibility, and accessibility buttons.

Almost all document forms use bookmarks. A bookmark is added in the same way as another control (see above), only the Panel control must be selected. To add a panel page, right-click on it and select Add Page. Other controls (fields) on the panel pages are simply dragged and dropped.

To resize form 1C, simply move the cursor to the edge of form 1C, press the left mouse button and simply drag the edge of form 1C.

In order for the 1C form to work - i.e. did something in response to user actions - you need to add handler functions. Enter the properties of any element (by double-clicking on it with the left mouse button) or the 1C form itself (similarly on the form header). At the very bottom of the properties window there is an "Events" section. Select a convenient event (for all fields it is usually "OnChange", for the form "OnOpen") and click the magnifying glass button. Its event handler will open.

For buttons, adding is the same. However, in addition to arbitrary handlers, you can choose one of the standard ones for this form (for a reference form, these are some standard actions, for a document form, others). Just select one of the standard actions in the "Action" property or click the cross if you want to make your own handler.

Probably, no algorithms can protect the database from errors that occur when users enter data. The main problems associated with human inattention can be identified in the following list:

• Wrong choice of object;
• Wrong quantity or typo in the name;
• Double elements of directories, their non-uniqueness or re-grading;
• Ignoring the filling of fields that are critical for the correct calculation and smooth operation of the program.

The solution to the last problem is, for the eighth version of the 1C program, checking the completion of the form details.

Completion check for a regular form

When the form is opened by the user, if the launch mode is "Normal application", the elements that must be filled in are highlighted with a red dotted line (Fig. 1).

As can be seen from the above example, the mandatory fields of the document "Sales of goods and services" are "Number" and "Contractor". In this case, the "Number" field is not available for editing. This means that when a document is written to the infobase, it will be automatically filled in in accordance with the numbering rules set for the given organization.

Recording directory elements or posting documents containing unfilled mandatory fields will cause an exception (Fig. 2).

Rice. 2

More detailed information about which particular field is not filled in can be seen in the service message window.

The mark itself, informing about the mandatory filling of the field, is set in the properties of the form element. For this:

1. Open the form in the Configurator;
2. We right-click on the form element, and call the "Properties" window;
3. It is necessary to check the boxes AutoMarkUnfilled and AutoSelectUnfilled in the "Usage" submenu (Fig. 3);

Direct check, as a rule, registers in the module of object.

For directories and non-transferable documents, it is advisable to call the filling check procedure when recording an element. Incompletely completed documents, if they are carried out, can be recorded in the database, and it is better to call the verification procedure before the formation of movements, that is, during the conduct. It is expedient to carry out the check in processings and reports containing mandatory fields directly in the button click processing.

You can check whether the value passed in the field differs from empty (the default value) using the ValueFilled("Value") function. Keep in mind that if the field is of a composite data type, executing this function throws an exception.

Validation in Managed Forms

Features of the platform in the client-server version leave their mark on the filling check.

First you need to understand which procedure follows which when entering an object in this mode of operation.

So, after pressing the button "Record", "OK", "Submit":

1. The procedure "Before writing" on the client is called;
2. The data is transferred to the server and the events registered in the form module on the server occur (here you can run the ProcessingFillCheckOnServer procedure);
3. The form data is transferred to the object module on the server (it becomes possible to launch the standard procedure FillCheckProcessing);
4. The data from the module is returned to the form module on the server, and the BeforeWriteOnServer procedure occurs;
5. The data is returned to the object module, and another BeforeWrite procedure occurs;
6. The object is directly written to the database.

At any point in this schema, you can insert the CheckFill() function. After running through the details, in the properties of which the “Fill check” attribute has the value “Give an error” (Fig. 4), this function, if at least one of them is not filled, will return “False”.

Differences between handlers HandleFillCheck() and ProcessFillCheckOnServer()

In view of the fact that the interface of a managed application can contain both object attributes and directly form attributes, these two procedures are separated. At the same time, they are similar in terms of the parameters that can be passed to the handlers:

1. Refusal (here, after the check, its result is transmitted);
2. CheckedAttributes (data type is an array, if it is not filled in, then all the details for which the properties are set to "Check filling" will be checked, otherwise the details selected programmatically will be processed).

The ProcessingFillingCheckOnServer() procedure allows you to check attributes that are not directly related to the object being edited. Each programmer decides for himself what and to what extent he would like to check.

The ProcessingFillingCheck() procedure checks the basic details.