1c group important commands. How to place commands in the command bar of a form? Enter the user's name and say hello to him

When switching to a managed interface, the logic of working with some objects that have been familiar since 7.7 has changed. In a classic interface for user interaction, the programmer designed a form, specified data entry fields, buttons, labels and other elements for interacting with users. Then I chose which form events the object should respond to and wrote an event handler. Everything is logical and understandable; the managed interface now includes the concept of a command. The command launches a certain algorithm, a set of actions that the programmer prescribes in the command module. You can call a command from a managed form, but what the control element that will call the command will look like depends on where the programmer drags the command and into which group of elements he places it.

I think we can say that in 8.1, and even in 7.7, the concept was as follows: the design determines the logic of the form, in the managed interface the logic of the work was placed at the head of the table, the formation of the appearance of the form was transferred to the shoulders of the 1c engine. Thus, the visual design of the element that will launch the command for execution depends on where the programmer dragged the command

As you can see, this can be a “3D button”, a flat button on the toolbar, or a drop-down menu item.

But if you look at the screenshot, you can see that in addition to our “Team1”, the form has buttons “Submit and close”, and in the menu our team was lost in many others that we did not program or create. These are standard 1c commands; they are found in forms, directories, documents and other 1c objects. Some commands are common, some are specific only to a certain type of object.

Commands can be in 3 places in the configuration:

Form (managed) commands are in the form module

Commands for a specific configuration object are located in the corresponding branch

Commands that are not tied to specific configuration objects are general commands that are located in the General branch - general commands (who would have thought).

As in ordinary procedures and functions, 1c commands can be passed values for processing. The value that is passed is indicated in the corresponding field of the command properties:

Where the command will be displayed is indicated in the “Group” field. For example, if we specify as shown in the screenshot, then the command will appear in the system like this:

When I first encountered the command interface, for a long time I could not understand why the document I created was not displayed in the interface of the subsystem I specified, despite the fact that the managed forms were written and all the rights were set. The reason for this was the “Use standard commands” checkbox from the “Commands” tab. Don't forget about her.

The 1C:Enterprise 8 technology platform is used to automate a wide range of management and accounting tasks at a wide variety of enterprises. With such a wide range of applications, situations may naturally arise where the functionality of standard commands is not enough.
To implement additional functionality, the built-in 1C:Enterprise language is used. This functionality is mainly implemented in event handlers. However, there is also a need to provide users with the ability to interactively access part of the implemented functions from the interface.

To solve these problems in 1C:Enterprise it is possible to create a custom team. In configuration, arbitrary commands are represented by a new configuration object Team. The Command configuration object is intended for implementing non-standard functions in an application solution with the ability to use standard mechanisms for enabling the implemented functionality
to the command interface.
The technology platform does not limit in any way the composition of arbitrary commands and the functions they implement. Everything is determined by the requirements for a specific application solution. When creating an arbitrary command, the developer must set its properties, which determine the rules for including the command in the interface, and write program code that defines the actions performed by the command. This is how arbitrary commands differ from standard ones. For the latter, both the properties and the actions performed are defined by the platform itself.
In the configuration, arbitrary commands can be implemented either as independent objects - general commands, or as subordinate to other objects.

General arbitrary commands allow you to implement non-standard functionality that is generally related to the application solution. In this case, an arbitrary command is created as an independent configuration object belonging to the class General commands.

Arbitrary general commands

For example, let's look at how to make and configure all the properties of the command “Set up a barcode scanner”. Trade enterprises often need to automate the process of registering goods sold. Barcode scanners are used for this. However, the technology platform does not “know” anything about these devices and does not have the means to work with them. Therefore, to work with a barcode scanner, you need to connect a special program - a driver. To connect such a driver, a general custom command is implemented: Install barcode scanner. By setting certain values for the properties of this command, the developer ensured its availability to users.

Custom general command “Configure scanner”

The functions for working with the scanner are common to the entire application solution, that is, they do not relate to any specific configuration object, so an arbitrary command is implemented as a general one.
The command performs an action - connects a driver to the application solution to work with a barcode scanner. Therefore, it is located in the action bar of the main application window.

Another common task is obtaining hard copies of electronic documents. The composition of documents and their structure are determined by the application task being automated. Naturally, it is impossible to provide for all the variety of documents and options for their printed forms in the platform. In order to “teach” a document to “transfer” itself to paper, you can use an arbitrary command.
In the demo database to obtain a printed form of the document Product consumption subordinate team created Printing Invoice

Arbitrary subordinate command “Print invoice”

Command property values Group And Command parameter type determined the location of the command in the command interface - the Print menu of the command panel of the document form, and the procedure in the built-in language ensured the formation of a printed form of a specific document, a link to which is passed in the command parameter.
Another, rather specific use case for arbitrary commands is to extend or override the standard functionality of a standard command. Such tasks arise, for example, due to the requirement to reduce the number of manual operations or change the standard behavior of objects.
For example, our database implements a processing object Administrative service. The command for opening the main form had to be placed in the navigation panel, and the form itself had to be opened in the work area of the main application window. But the standard functionality of this object differs from the required one - the command to open the form is located in the action bar, and the form opens in a new auxiliary window.
To ensure the required functionality, the Use standard commands property has been removed from the processing - standard commands do not suit us.

Disabling the use of standard commands

Access to processing is provided by an arbitrary subordinate command Administrative service, which is set to be located in the Normal group of the navigation bar of the main application window. As a result of selecting this command, a processing form is displayed in the work area of the main window.
There are many similar problems in specific application solutions, and arbitrary commands are the most suitable for solving them.

Arbitrary subordinate command “Administrative service”

Features of accommodation
A feature of arbitrary commands, compared to standard ones, is the need to describe their default location in the command interface. The location of an arbitrary command is specified by the developer when configuring the application solution.

The default location in the command interface for arbitrary commands is determined by:

category and group assigned to the team

the command’s belonging to the configuration subsystem (for independent commands) and the type of command parameter (for parameterizable commands).

ATTENTION!
Command property Group must be filled out. Otherwise, an error will occur when updating the database configuration and the update will fail.

When choosing a group for a command, you should pay attention to the need to pass parameters to the command and the actions that the command performs. As a general criterion, it can be suggested to adhere to the same rules that are used for standard commands.

If a command does not require parameters for its execution, then select a group for it with the category Navigation panel or with the categoryAction bars.

If a command requires passing a parameter for its execution, then for it you must select a group with the Form Navigation Panel category or the Form Command Panel category.

For commands, the execution of which leads to changes in the information displayed in the work area of the same window, you should select a category Navigation bar for independent teams or Form navigation bar for parameterizable commands.

For commands the execution of which leads to changes in data in the infobase, you should select a category Action bar for independent teams or Form command panel for parameterizable commands. It is also recommended to select this category for commands that will lead to the opening of a new window to display selection forms, report forms, and processing forms.

To include a common independent command in a particular section of the command interface, you must indicate its affiliation with the corresponding subsystems. Including a command in subsystems is done by checking it in the Composition of required subsystems property.

It is impossible to directly include a subordinate command in the subsystem. Therefore, subordinate independent commands are automatically included in the command interface of those subsystems in which the command's owning object is included.
But parameterizable arbitrary commands, both general and subordinate, are included in the command interface differently. This is due to the fact that the command can only obtain the actual value of its parameter from the form data. This is why parameterizable commands can only be placed in the form's navigation bar or in the form's command bar. Moreover, this value must have a data type that is valid for the parameter. The list of allowed parameter types is set in the property Command parameter type

The list of allowed parameter types for a parameterized command is determined by its “Command Parameter Type” property

By comparing the composition of the types specified in the command property with the types of form details, the system decides whether to include the command in one form or another.

A parameterizable arbitrary command is included in the form only when the form has at least one attribute with a type included in the allowed ones. When checking, details that are subordinate to the main form details are also taken into account. The composition of the checked subordinate details is limited to the first level of subordination.
Let's return to solving our problem of separating the functionality for working with prices into a separate subsystem. In addition to setting prices, we will also need the ability to print price tags for goods. In this case, it is necessary to implement two modes:

printing price tags for all products for all existing species prices,
printing price tags for all goods according to one type of price.

Standard configuration object commands cannot provide us with these capabilities. Therefore, we need to implement additional functionality. For this we will use arbitrary commands.

General independent team
At first glance, the functionality of printing all price tags should expand the capabilities of the Products directory. However, this configuration object describes many infobase data objects. If we implement the command as a subordinate command to the directory, then we will “teach” each of the data objects to print price tags for all products. And this is already unnecessary. The data object must be responsible only for itself. Therefore, the team will be common.
To add an arbitrary general command, use the Add item in the context menu of the General commands node of the configuration tree.

As a result, a general command will be added, and a properties window and a window for editing the command module will open for it.

Properties and module of the general arbitrary command

In the Basic property group, set the values of the command properties:

Name– “Print Price Lists of Products”;

Synonym– leave the automatically generated synonym;

A comment– we won’t fill it out.

The next step is to select a team category and group for its default placement. Our team does not require parameters for its execution - it is independent. The team performs actions to process data stored in the information base in order to obtain a set of price tags, and does not change the context of solving any problem. Therefore, we will set the category to Action Bar for the command. In which group will it appear? The most logical thing to do is to place her in a group Service.
Therefore, for the Group property, open a window with a list of groups and select the element p Action panel.Service.

NOTE
Pay attention to the properties Command parameter type, Parameter usage mode and and changes data– they are not available for filling. Properties are intended to describe the command being parameterized and become available only when selecting a group with the Form Navigation Bar or Form Command Bar categories.

Specifying the location of a custom general command

The team we have created is independent. Therefore, it is necessary to determine in which sections of the command interface it will be available. The command should be available in the same sections in which you can perform price management actions.
In our case, the created team must belong to three subsystems - Pricing, Prices, Enterprise. Thus, we need to edit the Composition of three subsystems property.
To reduce the number of actions performed, select Advanced from the context menu of the created command. As a result, a window will open in which, on the Subsystems tab, you can specify all the subsystems to which the command belongs

Including an arbitrary general command in subsystems

Our command is available to users with the Administrator role due to the installed role property Set rights for new objects. We are required to ensure its availability for the Pricing Manager role.
As with other configuration objects, availability can be configured for a general team in the role editing window.
Or you can - in the already open Advanced window on the Rights tab. In the Roles list, select the custom role and in the Rights list set the View right for the created team

Setting up team availability for the Pricing Manager role

Setting up command visibility by role for an arbitrary independent command is done in the same way as setting up for standard commands - in the command interface editor.
Our command should be visible by default to a user with the Pricing Manager role, and it should be hidden from a user with the Administrator role. To do this, in the command interface editor of the Pricing subsystem, uncheck the general visibility checkbox in the columnVisibility. This will ensure that the team is invisible to all roles, including newly created ones. And for the Pricing Manager role, we will explicitly check the box in the corresponding column.
Let's save the configuration, launch the application as the Price Manager user and select the Price Management section.

Setting the visibility of a custom general command

In the command interface, the Print product price tags command is available in the Price Management section (by indicating membership in the Pricing subsystem). The command is placed in the Tools group of the action panel (by specifying the appropriate value for the Group property).

Thus, for an arbitrary general independent command:

The default placement in the command interface is determined by the value of the Group property;
inclusion in a command interface section is determined by membership in the corresponding subsystem;
Availability for the user is determined by the value of the View right.

We created a team. How can you tell the user what actions an arbitrary command performs? The answer is obvious - describe the purpose of the command in the documentation for the application solution. You can also describe the purpose of the command in the built-in online help. To work with help information, the properties of the general command from the group are intended reference Information(rice.

Reference information for an arbitrary general command

However, searching for a description of a command in the documentation or built-in help is a lengthy process. You can help the user quickly remember the purpose of a command by choosing a speaking representation for it. An arbitrary general command in the command interface is represented by its Synonym property. Now the command is represented by text “Printing price tags for goods”, and this presentation is quite informative. But in the future we will add another command for printing price tags to the application solution - by type of price. Therefore, it is worth considering a command representation that will tell the user which option for printing price tags will be executed. Let's say it will be “Print of all price tags”.
Another way to remind the user of the purpose of a command is to use the Tooltip property. The text set in this property appears in a tooltip when you hover the mouse over the command. For the Tooltip property, set the text “Printing price tags for all goods at all types of prices”. As a result of changing the values of the Synonym and Tooltip properties, the command view
in the command interface has changed.

Changed command representation, tooltip, help

On this moment We created the command, configured its location, accessibility, and presentation. All we have to do is implement the functionality of the team, that is, the actions that the team should perform. To define the actions to be performed, the developer needs to implement the procedure in an embedded language. The procedure must be located in a command module, which can be accessed through the Open Properties hyperlinkCommand module.

The 1C form usually has several fields for entering data, as well as buttons for form control and various service actions. For example, for automatic filling or verification.

In order to place a button on a form, earlier, in version 8.1, you had to:

Drag a button to the panel
Add a function - buttons
In this function, write code in 1C language that will perform the required actions.

In order for the user to launch them, these actions have a visual representation on the form. What it will be depends on which group of form elements you drag the command into.

For example, if you simply drag it onto a form, there will be a button, if into a command panel group, then it will be a command panel button (flat), or you can drag it to a menu, then it will be a menu item.

The command can be used as regular form, and in the managed (command) interface 1C.

Standard 1C commands

But we also know actions that do not need to be programmed in the 1C language, since they are already available in the 1C platform. For example, for directories, standard actions are the ability to create an element. For the directory form - the ability to write, and for a document - to post. Are these also actions?

Yes, and now they are called standard 1C commands. Directories, documents, forms and others have their own standard 1C commands.

Standard 1C commands can be disabled for a specific one by checking the “Use standard 1C commands” checkbox in 1C on the “1C Commands” tab.

1C team owner

1C commands are located in the sub-branch of their owner. For example, Directories/Counterparties/1C Teams.

There are also 1C teams that do not have an owner, since they are shared. Such 1C commands are not tied to objects and are located in the General/General 1C commands branch.

1C command parameters

In the configurations in reference books and documents there was a “Go” menu with which you could magically go to related 1C objects.

For example, for the Counterparties directory, the legal and physical addresses are stored in the associated Contact Data register. To go to it, you had to select the menu in the form of the counterparty(s) - Go/Contact details.

That is, for some actions, not only the fact of launching the action is required, but also a parameter that determines for which object these actions need to be performed - for example, for which counterparty to display contact information.

In the properties of the 1C command it is possible to specify:

1C command parameter type – type of 1C object that will be used as a parameter, for example, the Contractors directory
Mode of use parameters – you need one value or a list (array).

To place a command on a form, you can specify in the 1C command properties the command interface group where it should be located.

Or simply drag the command to the list of form elements.

Custom groups
In the section Rules for placing global teams, we talked about the fact that teams are located in standard groups and that, if necessary, the developer can expand the standard composition of groups. Configuration objects are used for this Team group, located in the branch Are common configuration tree.
An arbitrary group of commands is used to logically group together commands that perform similar actions.
For example, a custom group of Print commands has been created, designed to combine commands that generate various printed forms.

Custom group of commands “Print”

As with other configuration objects, the Command Group object has universal properties defined Name, Synonym, Comment.
To determine the location of the group, use the property Category.

Let's include a custom command for printing price tags by price type in the Print group. To do this, in the Group property of our subordinate command, set an arbitrary group to Form Command Panel.Print.

In addition, set the Display property to Auto

Including a custom command in a custom group

Now in the list form and the form of the Price Types directory element, the command to print price tags is no longer located in the Important group, but in the Print group.

NOTE
In the command panel of the form, buttons display commands from the Important group. The commands of the remaining groups are displayed as submenus.

To form a group view in the command interface, properties are used Synonym, Display, Hint and Picture.
Property Synonym contains text representing a custom group in the command interface. For the synonym, set the value “Print forms”.
Property Display contains an option to display a group of commands. For display, leave the option Auto.
The Tooltip property contains the text of the tooltip that appears when the cursor hovers briefly over the command. For the hint, set the value to “Receive printed forms”.
The Picture property contains a picture that will represent the group in the interface. For the image, set (similar to an arbitrary command) the value Seal.
As a result of our settings, the presentation of the command group has changed - it is represented by the assigned image and text specified in the property Synonym.

Setting up the presentation of a custom group of commands

Among the features of the Command Group object, it should be noted that rights are not assigned to it, membership in subsystems and dependence on functional options are not determined. An arbitrary group will be presented in the command user interface only if at least one of the commands included in the group is available in it.
Otherwise, the group is not included in the command interface. In our application, access to the Price Types directory is also allowed for the Sales Manager role. But for this role, the View right for an arbitrary subordinate command has been reset.

Any command is not available to roles with the View property reset.

As a result of this configuration of rights, the arbitrary group of commands Print for the sales manager turned out to be empty, and it is not represented in the command panel of the list form of the Price types directory.

In 1C Enterprise 8.2, the appearance of the form is determined by the location and properties of the elements in the tree of form elements. Based on these properties, the system itself “draws” the form, in particular, the command panel of the form.
Any group of buttons ( command panel, submenu, group of buttons, context menu) is filled in according to the same rules:

first come the buttons provided by the command source with which this group is associated;
then comes a fragment of the command interface, if the command source implies its inclusion;
then there are custom commands added to this group;
then there is a submenu All actions(for command panel only);
and at the end there is a button Reference if it was provided by the command source.

Let's consider the simplest option, when two commands are created in the form of a directory element and placed in the command panel of the form.

As a result, in 1C:Enterprise mode, the location of buttons corresponding to the created commands Team1, Team2 corresponds to the algorithm described above: in the command panel of the form and in the submenu All actions first are the commands provided by the command source - the element form
directory (for example, Save and close), then the commands created
developer ( Team1, Team2), and then the commands Change form And Reference.

There are several ways to interfere with the command layout process.

1. You can separate user-created commands from other commands with a separator. To do this, you need to create a group like this in the command panel Button group and transfer these commands to it.

2. You can place some developer commands at the beginning of a group of commands.
To do this, you need to cancel the command source for the group (for the context menu and automatic command bar, you need to turn off the checkbox Autofill), then add your button to the group, after it add a group of the form Button group and install this group command source- For example, Form.

As a result, in 1C:Enterprise mode, the command panel forms and submenus All actions will have the following form.

3. You can move the auto-fill buttons. To do this, you need to place in the command bar or context menu tree a button associated with the same command that is filled in from the data source (for example, Delete, Change and etc.). Automatically, such a button will not be placed among the standard commands and, thus, you can move the standard
team to another location. As a result, the form's command bar and submenus All actions will have the following form.

To command icon Delete was displayed in the command panel of the form, you need to set the property of this button OnlyInAllActions in meaning No.

There is no option to change the order of the buttons provided by the command source.
If such a need arises, you need to cancel the source from the group of commands and completely fill the group manually.