Flexible management of accessibility properties of controls in the usual forms 1C: Enterprise 8.x

Probably one of the most difficult and boring tasks in designing a common form in 1C: Enterprise is managing the availability of elements depending on a particular data set. I have met a lot of solutions: from a procedure like InstallVisibilityAvailability () with the inclusion of all the rules for controls in it, to completely randomly scattered throughout the code calls to these properties.

I admit honestly, I also tried various methods, but at one point I came to a very convenient and logical (I think), which will be described in this post.

It all started with the fact that the search for a solution for this problem prompted me to an article from the “Development Methods” entitled “Organization of access control in the form”. The key point in the article is that access control focuses on the SetAccess () procedure alone. And if you need to change the state of the controls, only this procedure is called. The procedure itself does not deal with the definition of access, but works with data from lists that are formed by the following functions:

(); (); (); (); 

That is, the accessibility conditions themselves are set in these functions, and the Install Access () procedure already assigns these predefined values ​​to the corresponding properties of controls.
')
I divided the code into three parts. The first is the methods that make changes to the values ​​of the accessibility properties of form elements. Delivered them to the general module. Let's call it conditionally Access Control. Below is the code that is placed in it. I tried to comment on obscure parts of the code as much as possible.


For example, we have a tabular Goods field, in which there is a DiscountByDiscount column. The column is visible only when the discount card is affixed to the document, i.e. Props Discount Card is filled. Accordingly, the condition of the visibility control list for the Discount By Discount Map column is as follows:

The second part when are the functions that are responsible for the formation of lists of accessibility. They are located directly in the form and are exported. I moved a bit away from the 1C standard and replaced the Get List method with the Visibility () method on the Get List and Manage Editing Text (). It just seems to me that this is more convenient and more logical. Below is a code template with these functions:


And finally, the third part is the SetAccess () procedure, which is also located in the form module. We call this procedure anywhere in the code of our form to override the availability of form elements.

 //////////////////////////////////////////////////////////////////////////////// //       () .();  

To make it clearer and clearer, let's consider the following example. Suppose we have a form. On it is located the CashSale checkbox (boolean), the PunchingFiscalCheck checkbox (boolean), the DiscountMap input field (link to the DiscountCards reference book), the Comment input field (line) and the Goods table. All are associated with the same details. The table field has a column named Discount By Discount Map (number). In addition, there is a command panel Main Actions of the Form, on which is placed the button Punch Chek. We define some conditions:

1. If the Cash Sales check box is checked, the Punch Fiscal Check check box is visible and the Discount Card field is available for input.
2. If the PunchFiscalCheck box is checked, the PunchCheck button is available.
3. If the DiscountMap field is filled, then the Discount column on the DiscountMap of the tabular Goods and input field is visible. The comment field is editable.

Then, for our example, the list definition functions will take the following form:


Now it is enough to call the procedure of the InstallAccess () form, and we will get the state of the elements that we specified.

I want to highlight the next moment. You can add paths to form elements in lists. For example, for the above example with the Products table, the element name is defined as “Products. Columns. Discount by Discount Map”. Or the path to the button Punch Chek. You can use multiple attachments, such as "Name of the Command Panel. Buttons. Name of the Sub menu. Buttons. Name of the Buttons."

The proposed option is not final. You can make many small additions, such as indications, which lists to process and which not. But it already depends on the developer’s point needs.

Thanks for attention.