method:
The first row of
mt_ui_prop_def
processed by this "if" is
end_pont_design
. When the
type
(
WDUI_ROAD_MAP_EDGE_DESIGN
) of this property is passed within this "if" to the
describe_by_name
method of the class
cl_abap_typedescr
, this method sets the handle
rtti_attr
to an instance of the class
cl_abap_elemdescr
. And therefore, it is the method
get_ddic_fixed_values
of this method that returns the value-set:
for the property
end_point_design
of
ROAD_MAP
.
Since the global itab
mt_ui_prop_def
is typed as
sorted
on
property_name
in the
public
section of
cl_wdr_all_in_one_uielem
:
. . .
types:
tt_ui_prop_def_srt type sorted table of wdy_ui_prop_def with unique key library_name definition_name property_name.
. . .
class-data MT_UI_PROP_DEF type TT_UI_PROP_DEF_SRT read-only .
. . .
"SELECTED_STEP" is the next RoadMap property for which we expect to see a value-set assigned in the above "if".
But we don't - instead we see the assignment of a value-set to the property "START_POINT_DESIGN. (As might be expected, this is is the same value-set as was just assigned to the property END_POINT_DESIGN.)
The reason why the property "SELECTED_STEP is not assigned any value set is because the method rtti_attr->get_ddic_fixed_values raises the exception "1", and therefore no new value-set is created within the "if".
Since we have now seen how the above "if" handles all four properties of ROAD_MAP that we originally found in the metadata table wdy_ui_prop_def, we would not expect to see this "if" handle any other propeties of ROAD_MAP. That is, we would expect that these four properties are the only four properties of ROAD_MAP stored in the global itab mt_ui_prop_def,
But in fact, when we watch this "if" process through the debugger, we find that the global itab mt_ui_prop_def contains rows for three other properties of ROAD_MAP: ENABLED, TOOLTIP, and VISIBLE. And the question therefore is where these three extra rows came from, since they're not in the original table wdy_ui_prop_def.
The answer lies in the init_meta_data method of CL_WDR_ALL_IN_ONE_UIELEM - the method which originally loads metadata from wdy_ui_prop_def into mt_ui_prop_def. This method has the following critical loop within it:
And because
UIELEMENT
is the
SUPER_CLASS
of
ROAD_MAP
in
wdy_ui_elem_def
, the above loop in
init_meta_data
takes the properties of
UIELEMENT
:
and adds them to the properties of
ROAD_MAP
.
Since these three
inherited
properties of
ROAD_MAP
are processed by the
create_settings
method in the same way as
ROAD_MAP
's own properties, only the inherited property
VISIBLE
winds up being assigned a value-set within
create_settings
:
The inherited property
ENABLED
does not get assigned a value-set because its type is
WDY_BOOLEAN
, and the inherited property
TOOLTIP
does not get assigned a value-set because its type is
WDY_MD_TRANSLATABLE_TEXT
.
Well, that's enough for one post. Tomorrow, we'll finish taking
ROAD_MAP
through the rest of
create_settings
and then consider
create_aggregations
.