Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
former_member181923
Active Participant
0 Kudos

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

.

2 Comments