Main Widget |
||||||||||||||||||||||
To configure the main widget, the | tab and the tab of the mask are used.||||||||||||||||||||||
![]() |
Select |
|||||||||||||||||||||
The opened mask includes the following default configuration settings for relations and entities: Relations:
Entities:
|
||||||||||||||||||||||
In the Change Management configuration there's
a principal difference between the main widget configuration settings for
relations and entities. The item-item relation (BOM) and the item as an entity are used as an example in the following description. |
||||||||||||||||||||||
Entity |
||||||||||||||||||||||
![]() |
||||||||||||||||||||||
In the | tab of the mask only the change operation entry will be used for the generation of the main widget. In the column all possible change operations are listed. Only the "Replace 1:1-all" and the "Replace 1:n-all" are supported by monster masks for entities. This entry will be used to generate the menu for change operations during the specification of a change operation. Internally the change operation is mapped to a normal "Replace" operation where initially all existing locations are shown.||||||||||||||||||||||
![]() |
Entities do not have entries in the | tab!|||||||||||||||||||||
Relation |
||||||||||||||||||||||
In the | tab of the mask the form for the main widget, the lists for the sub widgets and the triggers are described.||||||||||||||||||||||
![]() |
||||||||||||||||||||||
The following entries have to exist in the columns of the
|
||||||||||||||||||||||
![]() |
||||||||||||||||||||||
The following entries have to exist in the tab:
|
||||||||||||||||||||||
![]() |
You must not use invisible fields for the field assignments! | |||||||||||||||||||||
Avoiding misrepresentation of the data in the main widget |
||||||||||||||||||||||
To avoid the misrepresentation of the data with simultaneous aggregate
and refine list in one widget, the ORIGIN-widget and the QUERY-widget
are opened virtually in the background. The entries for the ORIGIN-widget
and the result of the query are shown in calculatory fields in the foreground.
The "Query Form Parameter" and the "Origin Form Parameter" inside the tab of the configuration are just the names of the lists which will be opened invisibly in the background as virtual widgets. They contain the data that is shown in the visible query and origin widget. |
||||||||||||||||||||||
|
||||||||||||||||||||||
Further entries in the configuration are not anymore as relevant as before.
It will work also without any entry in the
|
||||||||||||||||||||||
Positioning the Sub-Widgets |
||||||||||||||||||||||
If you have an item-item relation, one item is
the so called parent and another one the so called child item. You can view
the relation from 2 different sides:
1. The aggregate view: You ask at this view, who is the parent of this
relation. DataView has since ever the limitation that you can not combine both views in one form. One of the reasons for the name monster mask and their complex handling is that the mask combines both views. This was only possible by using calculatoric visible masks with a connection to a virtually opened real mask in the background. The query widget and the origin widget are calculatoric widgets which are synchronized during runtime with their virtual widgets in the background. The only 'real' widget is the new widget, which is in edit mode. The calculatoric sub-widgets are: |
||||||||||||||||||||||
Query Form: |
||||||||||||||||||||||
|
||||||||||||||||||||||
Origin form: | ||||||||||||||||||||||
|
||||||||||||||||||||||
In case you want to position the monster mask sub-widgets you have to open the corresponding calculatoric sub-widget and change its ROW and/or COLUMN value. | ||||||||||||||||||||||
New widget - special handling for entries like *** in fields with a menu |
||||||||||||||||||||||
![]() |
Please use xchg_cch_chk_men instead of cch_chk_men. Xchg_cch_chk_men ignores entries like *** which are used as default entry for unchanged relation fields in the edited new widget of the so-called monster mask! | |||||||||||||||||||||
New widget - special handling for entries in the relation fields in the first row |
||||||||||||||||||||||
For all replace operations and the modify operation, the relation fields (visible or invisible) are initially set to the value "***". Without a change, the entries from the parent data set will be used. Existing field defaults will overwrite the "***" value, except the relation field is in the filter and has no query condition (empty). Furthermore, the possible entries of other tables (not the main table and not the join table) are cleaned during specifying the operation. | ||||||||||||||||||||||
In case of re-specifying the operation, additionally the previously changed field values (dirty fields) are also overwriting the"***" values. | ||||||||||||||||||||||
New widget - special handling for position number fields in the following rows |
||||||||||||||||||||||
In case of a Replace 1:n and a Replace 1:n all operation the value of the position number field is always set to "***" because the real position numbers must be calculated separately for every corresponding parent record. | ||||||||||||||||||||||
The Location Filter |
||||||||||||||||||||||
Because the NEW-widget is in edit mode, no other sub-widget of the monster mask can be accessed. To enable the user to query for locations, a modal filter widget is supported. By pressing the Filter button the widget is opened. Empty filter fields automatically lead to a "***" value in the corresponding fields of the new widget. The field access of the filter fields can be configured in the change management configuration settings. In the Relation Field Access tab you can set the field access to the following values:
|
||||||||||||||||||||||
The Location Filter widget |
||||||||||||||||||||||
The location filter widget is opened by the userexit xchg_sup_qry_wdg which has by default the form EDB-CHG-QRY-CFR as parameter. The userexit to open the location filter is placed inside the no-select menus of the corresponding main forms ( | ). There are several possibilities to set up the filter form:||||||||||||||||||||||
Default: | ||||||||||||||||||||||
By default the location filter form EDB-CHG-QRY-CFR is empty. Just the basic entity T_CENTRAL.COMPARE as kind of dummy entity for calculatoric fields is inside the field assignments. During the opening of the filter form, the field assignments of the corresponding operation are used to fill the form (see | ). Such a field assignment maps a calculatoric field with a real existing field. The calculatoric fields are copied into the filter form one above each other. The size of the form increases automatically, if necessary.||||||||||||||||||||||
![]() |
||||||||||||||||||||||
The same fields are placed into the main widget of the monster mask (see monster mask picture below).The start location inside the main widget is defined by the row and column of the invisible EDB-CHG-QUERY-DUMMY. The calculatoric fields are necessary because the filter widget fields as well as the fields in the main widget should show the query values which can be combined with logic operators, not the real existing entries. | ||||||||||||||||||||||
![]() |
||||||||||||||||||||||
Customizing: | ||||||||||||||||||||||
Basically, it is possible to customize everything. It is also possible to mix customizing with the automatic generation (see default case), but the customizer should know that the generation algorithm is a simple one. Customizing is always used prior to the default what can quickly lead to conflicts with the automatic generation algorithm. The result may look weird. Therefore, the following is recommended: if you customize, it's better to customize the filter as well as the main widget of the monster mask. | ||||||||||||||||||||||
The following description will show the customizing on the already existing masks and fields. The customizer can always create everything on his/her own and add additional fields and use them instead of the existing ones. Just one thing is absolutely necessary: the fields used in the location filter MUST be visible inside all sub-widgets of the monster mask. | ||||||||||||||||||||||
As an example, the changes for a customized location filter for the Replace 1:1 BOM operation is shown: | ||||||||||||||||||||||
|
||||||||||||||||||||||
![]() |
||||||||||||||||||||||
The size of the location filter widget is still generated automatically. Also the position of the buttons. The result looks like this: | ||||||||||||||||||||||
![]() |
||||||||||||||||||||||
![]() |
You must not use invisible fields for the field assignments! | |||||||||||||||||||||
Empty Field Assignments: | ||||||||||||||||||||||
In case even the default entries of the change management configuration are not available, the visible significant fields of the underlying relation are taken as default and will be generated in the location filter. The names for the calculatoric fields are the real field names where the dot (.) is replaced by hash (#). | ||||||||||||||||||||||
Example: T_MASTER_DAT.POS_NO -> T_MASTER_DAT#POS_NO. | ||||||||||||||||||||||
In case of our example it would be the item-item relation and the view STR, so the visible significant fields of EDB-ART-STR-ALI are taken. | ||||||||||||||||||||||
Using the Location Filter |
||||||||||||||||||||||
The handling for strings with white spaces of the monster mask filter widget corresponds to the standard DataView handling in query mode. String field values with white spaces will be set automatically between apostrophes to avoid error messages due of too many parameters. | ||||||||||||||||||||||
Example: | ||||||||||||||||||||||
This is my string is automatically changed to 'This is my string'. | ||||||||||||||||||||||
In case you add apostrophes by yourself the filter will recognize them and not add them a second time. An exception is if additional logical operators are used (|=OR,&=AND). | ||||||||||||||||||||||
When writing This string | that, the following error message appears: | ||||||||||||||||||||||
Please insert just one search item or connect them with logical operators ! | ||||||||||||||||||||||
This error message appears because DataView in this case is not able to decide if 'This string | that' or 'This string' | that is meant. |