home » Sport » Switches, regular application, managed forms. Switches, regular application, managed forms 1c problems with managed forms

Switches, regular application, managed forms. Switches, regular application, managed forms 1c problems with managed forms

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

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

Introduction

Let's start with a short description of the concept of "managed form" and related concepts of the 1C platform. Platform connoisseurs may want to skip this section.

In 2008, a new version of the 1C platform: Enterprise 8.2 (hereinafter referred to as the Managed Application) became available, which completely changes the entire layer of work with the interface. This includes the command interface, forms, and the window system. At the same time, not only does the model for developing the user interface in the configuration change, but also a new architecture for separating functionality between the client application and the server is proposed.
The managed application supports the following types of clients:

Thick client (normal and managed launch mode)
Thin client
Web client

The managed application uses forms built on new technology. They're called Managed Forms. To ease the transition, previous forms (the so-called Regular forms) are also supported, but their functionality is not developed and they are only available in the thick client launch mode.
The main differences of managed forms for a developer:

Declarative, not “pixel by pixel” description of the structure. The specific placement of elements is performed automatically by the system when the form is displayed.
All functionality of the form is described as details And teams. Details are the data that the form works with, and commands are the actions to be performed.
The form runs on both the server and the client.
In the client context, almost all application types are unavailable, and accordingly it is impossible to change the data in the infobase.
For each method or form variable, it must be specified compilation directive, defining the execution location (client or server) and access to the form context.

Let's list the directives for compiling form methods:

&OnClient
&On server
&OnServerWithout Context
&OnClientOnServerWithout Context

Let us illustrate the above. The screenshot shows an example of a managed form and its module in development mode. Find the declarative description, props, compilation directives, etc.

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

Several years have passed since the new version of the 1C platform is actively used and many solutions (configurations) have been released by both 1C and its many partners.
During this time, have developers developed a common understanding of the principles of client-server interaction when creating forms, and has the approach to implementing software modules changed in the new architectural realities?

Let's look at the code structure (form module) in several forms of the same standard configuration and try to find patterns.
By structure we mean sections of code (most often these are comment blocks) allocated by the developer to group methods and compilation directives for these methods.
Example 1:
Section of event handlers Method - on the client Method - on the server Method - on the client Section of service procedures and functions Auxiliary input control functions
Example 2:
Service procedures and functions Payment documents Values 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
Essentially, 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.
Methods are often grouped by interface elements “Working with the 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, etc.
And let's not forget that this is all within one configuration.
Yes, there are configurations in which the words “General, Service, Auxiliary” are always in the same places but...

Why do you need code structure?

Simplification of maintenance.
Simplify learning.
Recording general/important/successful principles.
...your option

Why doesn't the existing development standard from 1C help?

Let's look at the principles published on ITS disks and in various “Developer's Guides...” that are recommended when writing a managed form.

Minimize the number of server calls.
Maximum computing on the server.
Non-contextual server calls are faster than contextual ones.
Program with client-server communication in mind.
and so on.

These are slogans that are absolutely true, but how to implement them? How to minimize the number of calls, what does it mean to program in client-server mode?

Design patterns or generational wisdom

Client-server interaction has been used in various software technologies for decades. The answer to the questions outlined in the previous section has long been known and is summarized in two basic principles.

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

A word from Martin Fowler, his description of these principles:

… Each object potentially intended for remote access must have low granularity interface, which will minimize the number of calls required to perform a specific procedure. ... Instead of requesting an invoice and all its items separately, you need to read and update all invoice items in one request. This affects the entire structure of the object...Remember: 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 transfer objects are nothing more than bloated field set... The value of this disgusting monster lies solely in the possibility transmit multiple pieces 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

The application programming interface available to the developer when developing a managed form contains many examples of these principles.
For example, the OpenForm() method, a typical “rough” interface.
OpeningParameters = New Structure("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3); Form = OpenForm(FormName, OpeningParameters);
Compare with the style adopted in v8.1.
Form = GetForm(FormName); Form.Parameter1 = Value1; Form.Parameter2 = Value2; Form.Open();

In the context of a managed form, there are many “Data Transfer Objects”. You can select systemic And developer-defined.
System ones model an application object on the client, in the form of one or more form data elements. It is impossible to create them without reference to the form details.

DataFormsStructure
DataFormsCollection
DataFormStructureWithCollection
DataShapesTree

Conversion of system data transfer objects to application types and vice versa is performed using the following methods:

ValueInFormData()
FormDataValue()
CopyFormData()
ValueInFormAttributes()
FormAttributesValue()

Often explicit conversion is used when adapting an existing solution. Methods may expect (use features) input parameters, such as ValueTable rather than FormDataCollection, or the method has been defined in the context of an application object and has become unavailable for direct call from the form.
Example 1C v8.1:
// on the client in the context of the form FillUserCache(DepartmentLink)
Example 1C v8.2:
// on the server in the context of the form ProcessingObject = Form AttributesValue("Object"); ProcessingObject.FillUserCache(DepartmentRef); ValueВFormAttributes(ProcessingObject, "Object");

Data transfer objects, the structure of which is determined by the developer, are a small subset of the types available on both the client and the server. Most often, the following are used as parameters and results of methods of a “coarsened” interface:

Primitive types (string, number, boolean)
Structure
Correspondence
Array
Links to application objects (unique identifier and text representation)

Example: the method accepts a list of orders to change status and returns a description of the errors to the client.
&OnServerWithoutContext Function ServerChangeOrderStatus(Orders, NewStatus) Errors = New Match(); // [order][error description] For Each Order From Orders Cycle StartTransaction(); Try DocOb = Order.GetObject(); …. other actions, possible not only with the order... Exception CancelTransaction(); Errors.Insert(Order, ErrorDescription()); EndAttempt; EndCycle; Return Error; EndFunction // ServerChangeOrderStatus()

Structuring the code

The main goals that the managed form module should reflect and approaches to the solution.

Clear separation of client and server code. Let’s not forget that at the time of execution these are two interacting processes, each of which has significantly different available functionality.
Clear identification of the remote access interface, which server methods can be called from the client and which cannot? The names of remote interface methods begin with the prefix "Server". This allows you to immediately see the transfer of control to the server while reading the code, and simplifies the use of contextual help. Note that the official recommendation (ITS) suggests naming methods with postfixes, for example, ChangeOrderStatusOnServer(). However, we repeat that not all server methods can be called from the client, and therefore logical accessibility is more important, rather than compilation location. Therefore, with the prefix “Server” we mark only the methods available to the client; let’s call the example method 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. There must be a clear location for adding new code. An important point is that method templates automatically created by the configurator are added to the end of the module. Since event handlers for form elements are most often automatically created, the corresponding block is located last, so as not to drag each handler to another place in the module.

Below is the basic structure of the module that implements the listed goals.

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 When Created on the Server (Failure, StandardProcessing) //Insert the contents of the handler End of Procedure //******* REMOTE ACCESS INTERFACE ******* //******* BUSINESS LOGIC ON THE SERVER ******* ///////// //////////////////////////////////////////////// //////////////////// // COMMON METHODS OF CLIENT AND SERVER ////////////////////// //////////////////////////////////////////////// //////// // ON THE CLIENT //******* BUSINESS LOGIC ON THE CLIENT ******* //******* TEAM ******* //******* CLIENT EVENTS ******* /////////////////////////////// /////////////////////////////////////////////// / / MAIN PROGRAM OPERATORS

Basic forms

Each configuration object can be used to perform some standard actions. For example, for any directory you may need to display a list of its elements, display individual elements of the directory, display a group of the directory, select elements and groups of elements from the directory. For any document, the list of such actions will be much smaller: viewing a list of documents, selecting from a list of documents, and viewing a separate document.

To ensure that such standard actions are performed with the data of application solution objects, for each of them there is a set of basic forms that will be used when performing the corresponding actions. Any of the forms subordinate to this object can be assigned as the main one. For example, in the directory Nomenclature The following basic forms may exist:

And the document Receipt of goods and services the composition of the main forms will be different:

Thus, if the user wants to view the directory list Nomenclature or list of documents Receipt of goods and services, the system will open the corresponding form designated as the list form for these objects.

Auto-generated forms

An important feature of the 1C:Enterprise 8 system is the mechanism of auto-generated forms. This mechanism frees the developer from having to create all possible forms for each configuration object. The developer just needs to add a new configuration object, and the system itself will generate, at the right moments in the user’s work, the necessary forms to display the information contained in this object.

Thus, the developer needs to create his own forms of application solution objects only if they must have differences (different design or specific behavior) from the forms automatically generated by the system.

Linking a form to data

Whether a form belongs to a particular configuration object does not determine the composition of the data that is displayed in the form. The fact that the form belongs, for example, to a directory Nomenclature, allows you to assign it as one of the main forms for this directory, but does not in any way determine what data this form will display and what its behavior will be.

In order to associate a form with data, form details are used, which indicate the list of data displayed by the form. All forms, themselves, have the same behavior, regardless of what data they display. However, one of the form attributes can be designated as the main attribute for it (it is highlighted in bold), in which case the standard behavior of the form and its properties will be supplemented depending on what type the main form attribute has:

For example, if a document is assigned as the main form attribute Receipt of goods and services, then when closing the form, the system will request confirmation of recording and posting this document. If you assign, say, a directory as the main attribute of the form Nomenclature, then such a confirmation request will not appear when closing the form.

Form structure

The main feature of the forms is that they are not drawn by the developer in detail, “pixel by pixel”. A form in a configuration is a logical description of the form's composition. And the specific placement of elements is performed automatically by the system when the form is displayed.

The displayed part of the form (visible to the user) is described as a tree containing form elements.

Elements can be input fields, check boxes, radio buttons, buttons, etc. Additionally, an element can be a group that includes other elements. A group can be represented as a panel with a frame, a panel with pages (bookmarks), a page itself, or a command panel. In addition, the element can be a table, which also includes elements (columns). The element structure describes how the form will look.

All functionality of the form is described in the form of details and commands. Details are the data that the form works with, and commands are the actions to be performed. Thus, the developer in the form editor must include the necessary details and commands in the form, create form elements that display them and, if necessary, arrange elements into groups.

Based on this logical description, the system automatically generates the appearance of the form for display to the user. In this case, the system takes into account various properties of the displayed data (for example, type) in order to arrange the form elements as conveniently as possible for the user.

The developer can influence the arrangement of elements with various settings. It can determine the order of elements, specify the desired width and height. However, this is just some additional information to help the system display the form.

In forms, the developer can use not only the commands of the form itself, but also global commands used in the command interface of the entire configuration. In addition, it is possible to create parameterizable commands that will open other forms taking into account the specific data of the current form. For example, this could be calling a report on balances at the warehouse that is currently selected in the invoice form.

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 writing this article, these are versions 1C 8.2 and 1C 8.3. If you have had to work in both of these versions, then you most likely noticed differences in the interfaces of these versions, for users they differ only in appearance. Essentially a 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 detailed information on clients, read the article “What are thick and thin clients in 1C, as well as their differences.”

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

In 1C 8.2 it is possible to work only with regular forms, in regular application mode. The image below shows the database in the “regular 1C application” operating mode (regular forms).

Managed 1C application (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. Moreover managed forms have two types of display, this is 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 managed 1C application?

As we have already found out a regular application and a managed application are these types of launching a 1C program. Moreover, depending on the value of the 1C launch type ( regular or managed application), a 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, these are 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 carried out 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 corresponding directives in the configurator.

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.