1c add form details. Managed form details (1Cv8). Features of working with a value tree

Form details

A set of form details describes the composition of the data that is displayed, edited or stored in the form. At the same time, the form details themselves do not provide the ability to display and edit data. Form elements (see the “Form Elements” section of this chapter) associated with form details are used for display and editing. The set of all form details will be called form data.

Important! It must be remembered that, unlike regular forms, all data in a managed form must be described in the form of details. It is not allowed to use form module variables as data sources for form elements.

It is possible to assign Basic form details, i.e., attributes that will determine the standard functionality of the form (form extension). It should be remembered that a form can only have one main attribute.

Form extension– these are additional properties, methods and form parameters of the ManagedForm object, characteristic of the object that is the main element of the form.

During the form development process, you can explicitly set the ability to view and edit specific form details, in terms of roles, using the View and Edit properties (for more details, see the “Role-based form settings” section of the “Editors” chapter). In addition, the availability of a particular attribute in the form itself can be configured using functional options (more details about functional options can be found in the chapter “Configuration Interface Management”).

Form attribute property Saved data is a sign that an interactive change in the details will lead to an attempt to block the form data for editing, as well as to the automatic setting of the form modification flag.

Data types available in a managed form

A managed form also differs from a regular form in the types of data it works with. If the normal form works with most of the types that 1C:Enterprise provides (including the types DirectoryObject, DocumentObject, etc.), then in the managed form the following categories of types can be distinguished:

• types that are directly used in the form are those types that exist on the side of the thin and Web client (for example, Number, DirectoryLink.Products, GraphicScheme, TabularDocument);

• types that will be converted to special data types—managed form data types. Such types are displayed in the list of form details in parentheses, for example (DirectoryObject.Products);

• dynamic list (for more details, see the “Dynamic List” section of this chapter).

Converting Application Objects to Form Data

Some application types (such as DirectoryObject, etc.) do not exist on the thin and Web client side (see the Managed Application Concept chapter for more details). Therefore, to represent such application types in the form, the platform has introduced special data types designed to work in managed forms. This feature of a managed application makes it necessary to convert application objects to form data (and vice versa).

The following data types are used:

• Form DataStructure – contains a set of properties of an arbitrary type. Properties can be other structures, collections, or structures with collections. This type is represented, for example, in the form DirectoryObject.

• A FormDataCollection is a list of typed values, similar to an array. A collection element is accessed by index or identifier. Access by ID may not be available in some cases. This is due to the type of application object that is represented by this collection. The identifier can be any integer. This type is represented, for example, in the form of a tabular part.

• Form DataStructureWithCollection is an object that is represented as a structure and a collection at the same time. It can be treated like any of these entities. This type represents, for example, a set of records in a form.

• Form DataTree – an object designed to store hierarchical data.

An application object is represented by either one or more form data elements. In general, the hierarchy and composition of form data depend on the complexity and interconnection of application objects of the managed form.

For example, a document containing a tabular part will be represented by an object of the FormDataStructure type (the document itself), to which an object of the FormDataCollection type (tabular part of the document) is subordinated.

Important! When developing a configuration, it is important to remember that application objects are available only on the server, while form data objects can be used on both the server and the client.

Passing data between the client and server parts of a managed form

In fact, we can say that form data is a unified representation of data from various application objects with which the form works uniformly and which are present on both the server and the client. That is, the form contains some “projection” of application object data in the form of its own data types and performs conversion between them if necessary. However, if the configuration developer implements his own data processing algorithm, then he must perform data conversion (from specialized types to application types and vice versa) independently.

When editing form details in a specialized editor (for more details, see the “Form Details” section of the “Editors” chapter), it is possible to influence the transfer of data between the client and the server while the form is running. The column of the details editor is used for this. Always use. The effect of this property differs for three types of attributes:

• For an attribute subordinate to a dynamic list (dynamic list column):
  • property is enabled – the attribute is always read from the database and included in the form data;
  • property is disabled - the attribute is read from the database and included in the form data only when there is a currently visible form element associated with the attribute or its subordinate attribute.

• For props subordinate to the movement collection:
  • property is enabled – document movements are read from the database and will be present in the form data;
  • property is disabled - document movements will not be read from the database and will not be included in the form data (if there is no form element that references document movements).

• Other form details:
  • property is enabled – the attribute will be present in the form data, regardless of whether or not there is at least one form element that is associated with the attribute or its subordinate attribute;
  • property is disabled - the attribute will be present in the form data only if there is a form element associated with the attribute or its subordinate attribute. Unlike dynamic list attributes, the visibility of the element associated with the attribute does not matter here.

Note. It should be remembered that the property set on the parent attribute affects all subordinate attributes. For example, if the Use property is always cleared for the tabular part of the document, then the system considers that this property is also cleared for all subordinate details (despite the actual state of the property).

Methods for converting application object data into form data

To convert application objects into form data and back, there is a set of global methods:

• ValueInFormData(),
• FormDataInValue(),
• CopyFormData().

Important! Methods that work with application objects are available only in server procedures. The method for copying values ​​between form data is available on the server and on the client, since it does not require application objects as parameters.

When converting form data into an application object, you need to consider their compatibility.

• ValueInFormData() – converts an application type object into form data;
• FormDataInValue() – converts form data into an application type object;
• CopyFormData() – copies form data that has a compatible structure. Returns True if the copy was successful, or False if the object structure is incompatible.

Note. When performing standard actions (opening a form, executing a standard Write command, etc.) of a form with the main details, the conversion is performed automatically.

Let's give an example of how to use data transformation in your own algorithms.

&OnServerProcedure When CreateOnServer(Failure, StandardProcessing)

ObjectProduct = Directories.Products.FindByName("Coffeepot").GetObject(); ValueInFormData(ObjectItem, Object);

End of Procedure

&OnClient Procedure Write()

WriteOnServer();

End of Procedure

&OnServer Procedure WriteOnServer()

ObjectProduct = FormDataValue(Object, Type("DirectoryObject.Products")); ObjectItem.Write();

End of Procedure

The ManagedForm object also has methods available on the server:

• ValueВFormAttribute() – converts an application type object into the specified form attribute.
• FormAttributeVValue() – converts a form data attribute into an object of an application type.

Using these methods is usually more convenient, since they have, for example, information about the type of form attribute. In addition, the Form AttributesValue() method sets the correspondence between the form data and the object, which is used when generating messages. You can read more about this in the chapter “Service navigation capabilities”.

Let's give an example of using these methods.

&OnServer Procedure RecalculateOnServer()

// Converts the Object attribute into an application object. Document = Form AttributesValue("Object"); // Performs recalculation using the method defined in the document module. Document.Recalculate(); // Converts the application object back to a prop. ValueВFormAttributes(Document, “Object”);

End of Procedure

Software interface

FormDataTree

• FindById
• GetItems

Description:

Designed to model a tree in managed form data.

This object can be serialized to/from XDTO. The XDTO type corresponding to a given object is defined in the namespace. XDTO type name:

GetItems

Syntax:

GetItems()

Return value:

Type: Form DataCollection of Tree Elements.

Description:

Gets a collection of top-level tree elements.

Availability: client, server, thin client, web client.

FindById

Syntax:

FindById(<Идентификатор>)

Options:

<Идентификатор>(required)

Type: Number. Tree element identifier.

Return value:

Type:FormDataTreeElement.

Description:

Gets a collection element by ID.

Availability: client, server, thin client, web client.

FormDataTreeItem

Properties:

<Имя свойства> (<Имя свойства>)

• GetId (GetId)
• GetParent
• GetItems
• Property

Description:

Form data tree element.

FormDataTreeItemCollection

Collection elements: DataFormTreeElement

For an object, it is possible to traverse the collection using the operator For each... From... Loop. The traversal selects the elements of the collection. It is possible to access a collection element using the [...] operator. The index of the element is passed as an argument.

• Insert
• Add
• Index (IndexOf)
• Count
• Clear
• Get
• Move
• Delete

Description:

Collection of wood elements.

Availability: client, server, thin client, web client.

See also:

• FormDataTreeElement, GetElements method
• DataFormTree, method GetItems

Features of working with a value tree

Tree update

There is a problem falls platforms when updating the tree.

If any node in the tree has been expanded and a subordinate node has been selected, then when updating the tree with the function ValueInFormData the platform falls.

Solution: You need to clear the tree before updating.

For example:

&On the Server Procedure ClearTree(elements) For each element from elements Loop ClearTree(element.GetElements()); EndCycle; elements.Clear(); End of Procedure

&On the Server Procedure Fill Concept Tree() dConcepts = srProperties.Build Concept Tree(OnDate, Meta.CurrentIB()); ClearTree(ConceptTree.GetItems()); ValueInFormData(dConcepts, ConceptTree); End of Procedure

&OnClient Procedure OnDateOnChange(Element) Fill ConceptTree(); End of Procedure

How to add additional details to a directory element in 1C Accounting 8.3 (revision 3.0)

It happens that we lack the capabilities already available in 1C. And you don’t always need to contact a programmer. I will tell you about one of these cases in relation to the new 1C: Accounting 8.3 (edition 3.0).

Let us not have enough fields to enter information about our counterparties. And we want to add a new field, which will be called "Status" and have one of three values ​​- "High", "Medium" and "Low". I will tell you below step by step how to add such a field without going into the configurator.

1. Go to the "Administration" section and select "General settings" ():

2. Find and check the “Additional details and information” checkbox if it is not already checked. Click the "Additional details" link:

3. In the left part of the settings window that opens, select “Account”. Click the New button on the toolbar.

4. A window for creating new details for elements of the “Counterparties” directory has opened. Enter "Status" in the Name field. Leave "Additional value" as the value type, although in the future keep in mind that other value types are possible (string, number, date, etc.). But what we need now is the additional value, since we want to provide the user with a limited choice of three options.

5. To create each option, go to the “Values” tab, click the “Create” button there, enter the name of the value (for example, “High”) and click the “Save and close” button.

6. And so on until all three values ​​are created with the names “High”, “Medium” and “Low” as shown in the figure below. Click the "Save and Close" button.

7. As you can see, the Counterparty now has the Status attribute in the list of additional details.

8. Now, if we go to any element of the counterparties directory, we will see at the very bottom of the form a new Status field ( If you don’t see it, expand the “Additional details” group collapsed on the form.):

9. In this field we can substitute one of the three values ​​we created. You can make a selection using this field in the form of a list, it can be displayed in reports, etc.

General details in 1C 8.3 is a platform metadata object that allows you to use one attribute for many configuration objects (directories, documents, charts of accounts, etc.). The object was created mainly to make the developer's work easier and to separate data.

General details were initially implemented in version 1C 7.7, but the developers did not immediately include it in the platform version 8. The mechanism of general details was introduced by 1C developers only in release 8.2.14.

It is very convenient to add general details so as not to change standard objects in the configuration; I often use them along with .

After adding a general attribute, it can be used in queries and displayed on the object form - Outwardly, it is no different from ordinary props.

The only limitation of general details is the inability to use them in .

Let's look at the basic settings and properties of general details that differ from other configuration objects:

Compound— a list of objects to which the general details will be used; the setting is reminiscent of setting up an exchange plan.

Get 267 video lessons on 1C for free:

Auto use— the setting determines whether general props will be used for those objects that have the “Automatic” usage mode specified.

Data separation— we will consider this setting separately.

Separation of data in 1C using common details

Data separation- a mechanism similar to the mechanism. However, the performance of this mechanism is more efficient and it is easier to configure.

The mechanism allows you to configure the display of only elements that the user can see. For example, you can distinguish between all objects (documents, directories, etc.) where a certain organization is installed.

Setting up data separation using general 1C details

To configure the general details, you need to specify the data separation - Divide. Immediately after clicking, the system will offer to create default accounting parameters:

In this case, it will be necessary to specify the session parameters when starting the system; how to do this was described with an example in the article.

This completes the setup - the user will only have access to the information that is specified in the selected session parameters.

Example of using common props

Let's look at setting up general props in 1C 8.3 using the example of a frame configuration and props Organization:

The system has 3 documents where it is necessary to indicate the details of the Organization: these are the Receipt Invoice, the Expenditure Invoice, and the Payroll.

The setup is simple:

1. We create a new General attribute, specify the type - DirectoryLink.Organization.
2. In the composition we arrange for our documents - Use.

That's it, the setup is complete!

Let's see the result:

The system displays general details “as if they were your own”: in requests, in form details, and in other places. This is such magic! 🙂

General requisites 1C 8.3 are not added

The form details ensure its connection with the data. In this case, one (and only one) of the details can be designated as the main one; it may not necessarily be the data type to which we are drawing the form. But the behavior of the form will depend on the data type of the main attribute. In addition to changing the behavior of the form, the context of the form module changes. Along with the methods and properties of the form, the methods and properties of the object, which is the value of the main attribute, become available in it. It is important that forms of the Free Form type do not have basic details. In this case, the form's behavior is determined only by the user's settings. Let's consider questions about the basic details.

Question 10.05 of exam 1C: Platform Professional. What is the main form attribute used for?

1. Defines the data source for the form as a whole
2. Defines the standard capabilities of the platform for working with the form with data of the type specified in the main attribute
3. To provide the ability to programmatically access object details from the local form context
4. Provides visualization of object details on the form dialog
5. 2 and 3 are correct
6. 1 and 2 are correct

The correct answer is number six, see above.

1. To describe the content of the data that is displayed, edited, or stored in a form
2. To display and edit data in a form
3. 1 and 2 are correct

The correct answer is the third - both.

Question 10.07 of exam 1C: Platform Professional. To assign the main attributes to an arbitrary controlled form...

1. You need to check the "Basic details" checkbox in the properties of the form attributes
2. you need to fill in the “Data” property of the form by selecting the required form attribute

The correct answer is second:

1. the form needs to be made the main one, the main details are determined automatically
2. You need to check the "Basic details" checkbox in the properties of the form attributes
3. you need to go to the "Edit" menu, select "Basic details" and select the desired value
4. you need to fill in the “Data” property of the form by selecting the required form attribute

The correct answer is fourth:

The main details are highlighted in bold:

1. This is impossible
2. It is possible by assigning the appropriate value to the form attribute property
3. It is possible only programmatically, when accessing the "Form" object
4. This is possible by adding another value to the corresponding form property

The correct answer is the first, there is strictly one main requisite, because the connection with the object must be unambiguous.

Question 10.113 of exam 1C: Platform Professional. Which of the details of the form presented in the figure is the main one?

1. List of Currency Rates
2. DirectoryObject
3. Directory forms do not have basic details
4. Directory forms have all the basic details

Listed below are the main 1C objects that are used when working with managed forms. Brief code examples are given that demonstrate the traditional use of these objects when writing 1C configurations.

ThisForm

Used in the form module, in procedures&On the Client and &On the Server.

Allows you to access both form elements and details.

The form element is accessed through an object Elements and looks like this:

ThisForm.Elements.VersionNumber.Header = "v."+ProgramVersion;

Accessing attributes that exist on the form occurs like this:

ThisForm.Advertisement Text="Hello, comrades!";

Simplified access to form elements and details

In principle, you don’t have to specify the keyword in the form module ThisForm . You can access form elements and details in a simplified way:

// Form element

Elements.VersionNumber.Header = "v."+ProgramVersion;

// Form details

Advertisement Text="Hello, comrades!";

Features of obtaining form details (important!)

If the form attribute has a simple type - String, Number, Date ... then you can get (set) the value of the attribute simply by name:

Text=ProductName; // Product name is a form attribute

However, in this way it is impossible to obtain details of a “complex” type -Table of Values, Tree of Values . If you try to get an attribute with this type by name, an object of type will be returnedDataFormsCollection.

To get the value of an attribute with a “complex” type, you need to use the functionFormAttributesValue():

CurrentTable=FormAttributesValue("SelectedConstructionObjects");

To set the value of a “complex” attribute, you can use the functionValueInFormAttributes(<Значение>, <ИмяРеквизита>) , both parameters are required.

Functions FormAttributesValue() And ValueInFormProps()available only on the Server.

An object

Strictly speaking, there is no such keyword within the form. Simply, when a form is created, for example, an element form, 1C automatically creates an attribute on the form with the name An object . Through this attribute, the properties of the current object that is being edited on the form are available.

or, more complete notation:

ThisObject

Contains the object itself. Intended for getting an object in an object module or a form module.

Usage: Read only.

Availability: Server, thick client, external connection.