TABLE, MultiNoLead (0..n), TreeByKeyTableColumn, Collapse: Keep selections

[Former Member]

WDA, WD ABAP

Hi all,

Background:

I created a view with context cardinality 0..n, UI element TABLE, and selection as MultiNoLead. I addition, I established a tree via column type TreeByKeyTableColumn.

I do not use a SUPPLY method for my context node, but solely locate within WDDOMODIFYVIEW. Within this view, my application creates a simple tree that simply consists of two levels.

Let's assume, in a given example there exists one level 1 node with three subordinated level 2 nodes (IS_LEAF = X). Further, I yet expanded the level 1 node and in the resulting tree I selected two of its three subordinated level 2 nodes

Action:

I collapse the level 1 node.

What's going on:

The collapse action incorporates a round trip and the first thing I do in WDDOMODIFYVIEW (especially before a BIND_TABLE action) is to retrieve the context node and to get the selected elements:

...

data:

lr_node type ref to if_wd_context_node,

lt_elem type wdr_context_element_set.

• Get node

lr_node = wd_context->get_child_node( name = `INCLOG_TABLE` ).

• Get current selections

lt_elem = lr_node->get_selected_elements( ).

...

Problem:

The two selected (but about to be hidden) level 2 elements do not (better: no longer) show up in table LT_ELEM and I thus cannot re-select them after a BIND_TABLE via if_wd_context_element->set_selected( abap_true ). I want to do this to keep these level 2 selections if I re-expand the level 1 node.

Question:

How can collapsed sub-nodes keep their NoLead-selection?

Thanks in advance & best regards,

Michael

[Former Member · Accepted solution]

Hi Phil,

Thanks for your reply!

I think my final question was somehow misleading as you are totally right, I have to call

<i> if_wd_context_element->set_selected( abap_true ).</i>

after my call of BIND_TABLE to re-select the nodes once selected by user interaction.

However, to be able to do I have to grap these once selected nodes BEFORE my call of BIND_TABLE within WDDOMODIFYVIEW. And this is the point where my problem arises: Selected sub-nodes (level 2) do no longer show up in the result of

<i> if_wd_context_node->get_selected_elements( ).</i>

when I collapse their superior node (level 1).

On the other hand, non-lead selections do not force a round trip, and I hence do not know whether a sub-node that was once selected is still selected at point in time 'Collapse' or not. I can hence not store an OLD selection state from the previous round trip and compare it with the NEW selection state of the current round trip.

Thanks again in advance & best regards,

Michael

[Former Member · Accepted solution]

Hi Michael,

to solve selection issues, you can optionally turn off the standard selection button

and ADD an extra checkbox column.

I have used this in the case of a tree table to manage mass tree arm selections and to manage the selections as requried.

The standard selection button was suppressed in my case.

My checkbox used roundtrips.

But checkboxes no roundtrips and a separate button next to table

would also work.

Perhaps a fully managed field is bettered suited to your requirement.

Obviously we can see only a small part of the requirement, so Im not sure if this is a good solution for you.

Good luck

Phil

[Former Member]

Hi Phil,

Thanks for your input!

Incorporating a self-administered checkbox column has the disadvantage that I cannot use the standard service methods like GET_SELECTED_ELEMENTS (Context node) or SET_SELECTION (Context element), but - indeed - I have much mor degrees of freedom to treat my selections/selection behaviour. I will try that out and think to get it work somehow.

Thanks & best regards,

Michael

P.S. But I still wonder why the standard selection column invalidates the selection of a collapsed node that was selected before the collapse action? If you like I can offline (this is, besides this thread) show the scenario directly within the system.

[Former Member]

Hi Micheal,

use the if_wd_context_element->set_selected method for each element you wish to

be considered selected.

Pre-req:

Both the node and the table properties need to be appropriately set to handle multi selection.

regards

phil.