The interface extensibility features discussed so far refer only to internal POS controls. If you need to add a new control that should be manageable, you can use the layout management extensibility mechanism. The mechanism allows you to register new control types and determine which of their properties should be manageable. Apart from that, it is also possible to add management options to the properties of already existing controls or hide such options.

How to hide editable properties

Hiding a property removes it from the layout management view. Users with access to the layout management options will not be able to edit such a property. A control whose property is hidden will have its value set as a default value defined in styles. However, if a default value has been defined in the ModernUI.xaml file, it will be ignored (differences occurring when defining default values have been described in the chapter Setting default values for manageable properties in How to manage the layout and its elements).

It is possible to hide specific properties of a particular control that has been uniquely identified with a LayoutId. The method hiding properties is DisablePropertiesForLayoutElement, contained within the PropertiesManager class. The method’s parameters are:

• layoutId (string) – it is the identifier of a control whose property is to be hidden
• properties (params DependencyProperty[]) – one or several properties to be hidden for a given control

PropertiesManager.Instance.DisablePropertiesForLayoutElement("NewSalesDocument", TileButton.ImageKeyProperty);

PropertiesManager.Instance.DisablePropertiesForLayoutElement("AcceptButton", FrameworkElement.HeightProperty);

How to add new editable properties

If an existing or entirely new control has its own defined properties and you want these properties to be editable as part of the layout management options, you need to register them. You can do it in one of the two ways, depending on whether the property is to be visible only for a particular control in a specific location or globally for all instances of this control.

In the first case (registration of the control in a specific location only), use the AddPropertiesForLayoutElement method as part of the PropertiesManager class. The method’s parameters are:

• layoutId (string) – it is the unique identifier of the control (Layout Id),
• properties (params DependencyProperty[]) – these are the properties of the control that are to be manageable

In the second case (global registration in all control locations), use the RegisterControlProperties method as part of the PropertiesManager class. The method’s parameters are:

• controlType (type) – it is the control’s type
• properties (params DependencyProperty[]) – these are the properties that are to be visible for the control of a selected type
• baseTypeProperties (Type) – it is the type of a base control from which previously registered properties will be retrieved to be used for registering the properties of the desired control

How to handle attributes

POS application supports single-value attributes synchronized from the ERP system. Supported attribute types are: text, number, directory, logic value, list, and date. To synchronize a given attribute on the POS workstation, it is required to select the Preview and/or Edition parameters in the Comarch POS section of this attribute in Comarch ERP Standard (you can access this section by going to [Configuration] → [Attributes] and selecting an appropriate attribute). Attributes can be presented as list columns (datagrid control) or as controls (generated depending on the attribute class, e.g. TextBox for a text attribute or a ComboBox for a directory attribute).

How to add a new attribute to an existing view in POS

Each view in POS application that supports the use of attributes is directly associated with a particular object of the ERP system. For instance, the Customers view presents attributes as list columns. It can only show attributes and attribute values that have been assigned to the Customer/Vendor object in the ERP system. In the case of the receipt view, the list (datagrid) presents attributes associated only with the Receipt Item (R) object, while attributes presented as controls in the bottom right corner of the screen are associated with the Receipt (R) object.

Below, you will find the list of views supporting attributes, along with associated objects of the ERP system.

To transfer an attribute to POS application, select the Preview and/or Edition parameters in the Comarch POS section. The Preview option allows attributes to be handled in the read-only mode in POS application. In turn, selecting the Edition option enables you to change attribute values and synchronize such changes with the ERP system after saving them. Next, you need to associate a given attribute with an object supported in POS (see table above). Once you adjust and synchronize their settings, new attributes will be displayed in an appropriate view in POS application, allowing you to manage them as part of interface configuration.

For instance, you add a new attribute X of the Text type and select the Edition parameter for it in the Comarch POS section. Next, you need to associate it with the Customer/Vendor object in the ERP system. After synchronizing data, you run POS application and open the configuration of the Add Customer view. Once there, you select an appropriate container (CustomerItemsContainer) allowing you to present attributes, drag the new X attribute from the list on the right-hand side to the view and drop it in a selected location.

How to add a new attribute to a new view

You may also handle attributes in custom views created as part of an extension. Attributes can be presented as dynamically generated list columns (DataGrid control) or as independent controls (the control type will depend on the attribute type).

Attributes displayed as columns on a DataGrid list

To implement attributes on lists as dynamically generated columns, first of all implement the IAttributable interface for the data entity. It provides three properties that are necessary to properly handle attributes on lists. The first two properties – Id and ObjectType – must be set in accordance with the entity. Id is the entity’s identifier, while ObjectType is its type. The third property Attributes is a dictionary that will need to be filled in upon the asynchronous transfer of list data. To fill in this dictionary, use the FillAttributesForList method contained in the IAttributesService service. Before dictionary data can be displayed, the list must first generate additional columns. To make it possible, upon the first data transfer (IsInitialization=true), it is necessary to set the AttributeClasses property included in the AsyncDataGridCollection class. To set the property, use the GetAttributesClasses method from the IAttributesService service. The method takes two parameters: the first allows you to determine which attributes should be presented on a given list, while the second filters which attributes for given groups should be visible. If the second parameter is null, all attributes from the groups selected in the first parameter will be retrieved. You should perform the implementation in such a way as to allow attribute filtering to be manageable in the view design mode. Therefore, in the DesignViewModel of a given view, call the method with the second parameter set as null. It will make it possible to get all attributes and generate all possible columns (hidden by default). In turn, in the view’s ViewModel, define the VisibleAttributesClassesList property as part of the second parameter; the property will contain the list of attributes set in the design mode. The FillAttributesForList method fills in the Attributes dictionary. It requires defining two parameters. The first parameter is the list of entities (an entity must implement IAttributable), while the second is the list of attribute identifiers, for which each entity must be assigned the values of those attributes. For optimization reasons, not to retrieve too much information, the second parameter should be set by passing the property VisibileAttributesClassesList.

The sorting mechanism is deactivated for columns generated for attributes.

By default, columns generated for attributes are hidden. To display them, it is necessary to implement getting all possible attributes for a given list in the design mode, so that users can select a column and define its visibility and other properties.

If a list is displayed in the read-only mode, attributes are presented as texts. In turn, in the editing mode, they are generated as appropriate controls, depending on the data type. Therefore, for the logic value type it will be CheckBox, for lists and directories it will be ComboBox, and for the other types – TextBox.

See the chapter Trade document view with the handling of attributes in Examples for a full implementation example.

Attributes as independent controls

An alternative way of presenting attributes in created views is their implementation as dynamically generated controls that depend on the attribute type. Such controls will also allow you to change attribute values. The implementation may be divided into three stages. The first stage involves implementing the transfer of attributes and their presentation as controls displayed in a defined container. The second stage is the implementation of the validation of attribute values. Finally, the third stage is the saving of changes made to attribute values. See the chapter Trade document view with the handling of attributes in Examples for an implementation example.