Skip to Content

So I’ve been developing WD4A for a while now. But the language still manages to surprise me occasionally.

To put it mildly, if I were to meet an SAP employee tomorrow and he/she where to explain to me that Web Dynpro was coded and designed without any sensible project management at all – I would believe them in an instant.

A minor example: Visibility.

You would think visibility is a simple proposition – something is visible or it isn’t, right? But trying to recreate the thought processes going around SAP at that point in time I arrive at this:


Visibility – Screams for a boolean really.

Wait… ABAP doesn’t believe in something as fundamental as real booleans. (More here: ABAP Keyword Documentation.)

Doesn’t matter, lets use WDY_BOOLEAN instead, we don’t care about wasting 16 bits where one would suffice – this isn’t assembler after all.

Noooo, X and Blank is too simple, lets use a NUMC2 – so that we can have a hundred different types of visibility!

What values are you proposing?

’00 – Visibility.blank’, ’01 – Visibility.none’, ’02 – Visibility.visible’.

Sounds complicated…

Your’re right – lets create a domain (WDUI_VISIBILITY) and lets hide blank from the users.

I have a better idea – why don’t we permit both. But don’t tell anyone!

Hey guys – so when we develop EHP6, how about we create a new ENUM with reshuffled values and use blank = 2 and none = 3. (Note: And of course use Integers and not NUMC.)

High Fives all around!



How else could you possibly arrive at this:

View Element Tab – Visibility is a ‘boolean’ – SAP Library – Web Dynpro for ABAP

All other UI Elements I know of – Visibility is of type NUMC2 (WDUI_VISIBILITY) – SAP Library – layout Category. Which has two values in its domain – none and visible! (Which happen to be 01 and 02 – which is weird enough as it is.)


But – when using coding – you can use blank!


Public Section:

Line 15:

       BLANK TYPE WDY_UIE_LIBRARY_ENUM_TYPE VALUE ’00’, ” Visibility.blank
       NONE TYPE WDY_UIE_LIBRARY_ENUM_TYPE VALUE ’01’, ” Visibility.none
       VISIBLE TYPE WDY_UIE_LIBRARY_ENUM_TYPE VALUE ’02’, ” Visibility.visible

That’s obviously not good enough so here it is – everything reshuffled:

Interface: IFUR_NW7

Interface Section:

Line 188:

   constants VISIBILITY_ENUM type I value 0. “#EC NOTEXT
   constants VISIBILITY_VISIBLE type I value 1. “#EC NOTEXT
   constants VISIBILITY_BLANK type I value 2. “#EC NOTEXT
   constants VISIBILITY_NONE type I value 3. “#EC NOTEXT

Ok ok – that is only mildly crazy. I can live with that. After all nobody seems to use those new visibility values…

But what drives me up the wall completely is this:

If I now bind the attribute ‘visible’ of any View Element in the View Designer to the Context I can bind it to an Attribute of type WDY_BOOLEAN. Or to an Attribute of type WDUI_VISIBILITY (NUMC2 will do). Why is that? Because some clever soul at SAP decided to code something like this:

  *   >> Property: Get UIELEMENT-VISIBILITY
     if wd_link_to_action->ip_visible = abap_true.
       ifur_nw7_link~visibility = wd_link_to_action->pl_visible.
     elseif wd_link_to_action->bp_visible is bound.
       get_attribute_internal( exporting i_binding = wd_link_to_action->bp_visible
         importing e_value = _vis ).
       case _vis.
         when abap_true.
           ifur_nw7_link~visibility = cl_wd_uielement=>e_visiblevisible.
         when abap_false.
           ifur_nw7_link~visibility = cl_wd_uielement=>e_visiblenone.
         when cl_wd_uielement=>e_visiblenone or cl_wd_uielement=>e_visiblevisible
           or c_visibility_blank.
           ifur_nw7_link~visibility = _vis.
         when others.
             textid  = cx_wdr_adapter_exception=>unknown_value_for_property
             adapter = me
             p2      = _vis
             p1      = ‘visible’ ).                          “#EC NOTEXT
       ifur_nw7_link~visibility = wd_link_to_action->vl_visible.
*   >> enumeration with custom coding CORE/VISIBILITY => VISIBILITY

For those of you that do not want to read code – basically we check if the attribute is boolean first. Then we check if it is of type NUMC2. (Oh yeah – notice how blank and none amount to exactly the same here.)

But sometimes, just sometimes that will not work. Why? Because some other soul (here is me getting into the sensible project management bit) has decided to code the following:

  *   >> Property: Get TIMED_TRIGGER-WD_VISIBLE
     if wd_timed_trigger->ip_visible = abap_true.
       mv_wd_visible = wd_timed_trigger->pl_visible.
     elseif wd_timed_trigger->bp_visible is bound.
       get_attribute_internal( exporting i_binding = wd_timed_trigger->bp_visible
         importing e_value = mv_wd_visible ).
       mv_wd_visible = wd_timed_trigger->vl_visible.

So when reading the Context it will crash if the attribute is of type WDY_BOOLEAN. (MV_WD_VISIBLE is defined to be of type WDUI_VISIBILITY).

Both of these coding excerpts are from the implementation of if_nw7_view_element_adapter~set_content (or for those of you on older SAP Releases try

if_wdr_view_element_adapter~set_content). But they both do something slightly different.

Which means something very logical which I have to do for Tabs (visibility is boolean) might work for other UI Elements. But sometimes it will crash.

tl;dr; The visibility of a Web Dynpro UI Element can sometime be controlled using boolean context values. Sometimes doing exactly the same will cause a dump. Oh the insanity…

update: My first version had something about insane simians in it. As I did not want to be rude to SAP developers who – when actually spoken to – seem to be a nice bunch, I replaced those comments with something possibly more realistic.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply