1Ci Support Help Center home page
Submit a request
Sign in
  1. 1Ci Support
  2. 1C:Enterprise Platform Training Course - Junior Application Developer Level
  3. Module 4. UX/UI basics

Episode 2. The Field element

  • Module 4. UX/UI basics
    • Overview
    • Episode 1. UX/UI basics
    • Episode 2. The Field element
    • Episode 3. Formatted document
    • Episode 4. HTML document field
    • Episode 5. Form command interface
    • Episode 6. Conditional appearance
    • Episode 7. Dynamic lists
    • Episode 8. Functional options
    • Episode 9. Talking to a user from code

<< Prev   Next >>

So, there might be form elements that are visible to a user but not connected to any attribute and therefore, to any data in the database. They may have an empty DataPath property or don’t have it at all. There also might exist form attributes that are not connected to any form element and therefore, invisible to a user. But more often than not, we use connected element-attribute pairs when we want a user to see and edit some database data. This is what we use a Field form element for.

The most natural way of establishing the connection between an attribute and an element looks like this. I’m just dragging the attribute I want to show on the form and dropping it to the elements list. What the Platform did here is it automatically added a new element of the Field type. Why field? Because this is how we display and edit a single attribute value in 1C:Enterprise - we use fields. Every single element in this list is a field, as you can see. At the same time, all these fields look and work quite differently.

The Description is a string field I can type in like this, the Product type is a drop-down list with enumeration values, and these three fields down here show drop-downs with recently used values, allow adding a new value at the spot, or open the catalog choice form like this. How come the same element behaves that differently for different attributes? Well, there are some settings as always - same old, same old.

First of all, the Field element cannot live without the DataPath property being set. I mean, I can add a Field element with an empty DataPath but it will have no idea what it’s doing here and won’t even show up on the form. As soon as the Field element is connected to some attribute, it jumps on board and displays itself on the form. It also starts offering a bunch of functionality and appearance options, depending on the data type of the attribute it’s connected to.

First of all, there are types. Each of these is carefully honed for a very specific type of attribute data. So when you drop an attribute to the element list, the Platform gives it the best-fit-for-the-job type. But if you want to fill out the Description using Radio buttons for whatever reason, the Platform won’t try to stop you. A form element connected to a reference-type attribute cannot be typed in by a user manually. Its value needs to be chosen from a list.

Like this ProductType attribute, for example, which can accept only ProductTypes enumeration values. Therefore, this kind of element has only these three options. There are only two values in this enumeration, so it’s perfectly logical to use radio buttons. Radio button field type requires a fixed list of values to choose from, so I’m going to the ChoiceList setting and clicking Fill. Looks like I can add any number of other values to the list, but this is not the case. I can use only values the enumeration contains. I can delete some values, though, if I don’t need all of them in here. I can also select between these two appearances. And this is how the Tumbler looks like.

As for the CatalogRef type attributes like these three guys here, their values cannot be selected from the fixed list, so the elements representing them on the form feature a different kind of a drop-down. It shows the recently chosen values, allows me to add a new catalog item on the fly, open the selected item and edit it, or open the full catalog items list in a separate window like this. So, choosing the correct Field element type and setting up its main properties (which can be delegated to the Platform) covers all typical needs when it comes to displaying and editing attributes.

But, of course, we can set up the Field element in almost any way imaginable if we so desire. For example, this is our service buttons arsenal. Let me show you some of them. This is the drop-down list button we’ve seen already. This is the choice list button we usually use to open the full list of values to choose from. We also have the Clear button to delete the current value, the Spin button to increase or decrease a numerical field value, the Open button to open the item currently selected, and so on. After we added these buttons, we can handle their events and customize their behavior in any way we like. This is how we use the Field element.

<< Prev   Next >>

© 2020-2022 1C INTERNATIONAL LLC www.1Ci.com Support policy