Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

Drag and Drop does not work properly

Former Member
0 Likes
1,540

Hi,

I am using class CL_LIST_TREE_MODEL and try to get events DROP,DROP_GET_FLAVOR and DROP_COMPLETE.

None of them works (the event is not called).

although, the event DRAG is triggered.

The problem appears in version 710 of sap gui only. In the 640 version it's all fine.

Did someone had the same problem?

Thanks, Noa.

Hi,

I am using class CL_LIST_TREE_MODEL and try to get events DROP,DROP_GET_FLAVOR and DROP_COMPLETE.

None of them works (the event is not called).

although, the event DRAG is triggered.

The problem appears in version 710 of sap gui only. In the 640 version it's all fine.

Did someone had the same problem?

Thanks, Noa.

2 REPLIES 2
Read only

MarcinPciak
Active Contributor
0 Likes
833
Part1

Just as a short guide for people who struggle with the same issue (which I faced too). I did a bit investigation and here comes the conclusion:

For class CL_LIST_TREE_MODEL in order events DROP , DROP_COMPLETE be triggered the object reference drag_drop_object (which comes as parameter to DRAG event handler) must not be initial, that is you have to pass some valid object to drag_drop_object-object , i.e.


METHOD handle_drag.
    DATA drag_object TYPE REF TO lcl_my_dragdrop_object.
    create object drag_object.
    "...
    drag_drop_object->object = drag_object.
ENDMETHOD.                

As for event DROP_GET_FLAVOR it is more complicated. In order we can drag and drop objects (here nodes of a tree) we need to create behaviours for each node determining how nodes can interact (move/copy/none) i.e. we have such tree


-- 'Root'
  |
  -- 'Report1'
       |
      -- 'Field1'
      -- 'Field2'
 -- 'Report2'
      |
     -- 'Field1'
     -- 'Field2'

We want to be able to move/copy Fields b/w Reports . For this we defined Field node behaviours


  CALL METHOD go_behaviour_field->add
      EXPORTING
        flavor          = 'MOVE_FIELD'
        dragsrc         = 'X'
        droptarget      = ''
        effect          = cl_dragdrop=>move.

  CALL METHOD go_behaviour_field->add
      EXPORTING
        flavor          = 'COPY_FIELD'
        dragsrc         = 'X'
        droptarget      = ''
        effect          = cl_dragdrop=>copy.

And Report behaviour


 CALL METHOD go_behaviour_rep->add
      EXPORTING
        flavor          = 'MOVE_FIELD'
        dragsrc         = ''
        droptarget      = 'X'
        effect          = cl_dragdrop=>move.

    CALL METHOD go_behaviour_rep->add
      EXPORTING
        flavor          = 'COPY_FIELD'
        dragsrc         = ''
        droptarget      = 'X'
        effect          = cl_dragdrop=>copy.

This seems to define two behaviours and two flavors for these two nodes, that is they can interact in two ways. Doing so, however, doesn't trigger event DROP_GET_FLAVOR where we could determine whether user wants to copy or move a node.

I made system debug on method CL_GUI_CFW=>HANDLE_DRAGDROP_EVENT and it seems that we are able to choose from different flavors only if they are defined for same effect , either cl_dragdrop=>copy or cl_dragdrop=>move with same dragscr and droptarget values for both behaviours. In other words, you will have to have such behaviours defined for both nodes


 CALL METHOD go_behaviour_rep->add
      EXPORTING
        flavor          = 'MOVE_FIELD1'
        ...
        effect          = cl_dragdrop=>move.   "same effect as below

    CALL METHOD go_behaviour_rep->add
      EXPORTING
        flavor          = 'MOVE_FIELD2'
        ...
        effect          = cl_dragdrop=>move. "same effect as above

Edited by: Marcin Pciak on Mar 2, 2012 12:23 PM

Read only

0 Likes
833
Part2

Only then, the aforementioned event will get triggered. For me this is strange beacuse I think that:

- one behaviour is a way of how nodes can interact, using the same effect for both behaviours is like defining two variables for the same purpose

- I can't figure out a case where this would be useful - in event DROP_GET_FLAVOR we choose b/w operation MOVE or MOVE ? Initially I though this might be required in order to determine whether we move Report node to Field node or vice versa so the definitions would look like


"for Report node
  CALL METHOD go_behaviour_rep->add   "we drag REPORT to FIELD
      EXPORTING
        flavor          = 'MOVE_FIELD1'
        dragsrc         = 'X'
        droptarget      = ''
        effect          = cl_dragdrop=>move.

  CALL METHOD go_behaviour_rep->add  "we drop FIELD to REPORT
      EXPORTING
        flavor          = 'MOVE_FIELD2'
        dragsrc         = ''
        droptarget      = 'X'
        effect          = cl_dragdrop=>move.

"for Field node
  CALL METHOD go_behaviour_field->add   "we drop REPORT to FIELD
      EXPORTING
        flavor          = 'MOVE_FIELD1'
        dragsrc         = ''
        droptarget      = 'X'
        effect          = cl_dragdrop=>move.

  CALL METHOD go_behaviour_field->add  "we drag FIELD to REPORT
      EXPORTING
        flavor          = 'MOVE_FIELD2'
        dragsrc         = 'X'
        droptarget      = ''
        effect          = cl_dragdrop=>move.

...but it seems that above combination is not threated as two flavours but only as two behaviours and the event still doesn't get triggered. So the conclusion here is that only flavour parameter here must be different in order we define two flavours. So the behaviours need to have only different description but same effect. That doens't make sense to me

- this means we need another pair of behaviours to define COPY operation for each node

Having this "small" digression in mind, I am asking you guys, what the hack we need this event DROP_GET_FLAVOR for?

Regards

Marcin