From 04:00 PM CDT – 08:00 PM CDT (09:00 PM UTC – 01:00 AM UTC) Tuesday, April 16, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Why Does Adding an Event Change Drag And Drop Functionality

Okay this has bothered me for a while but I just thought it was one of those "Well that's how LabVIEW does it" and I want to make sure that I'm not missing something.

 

I've noticed on many controls that drag and drop works well as long as you only care about the value of the control.  But often I'll want to know how a drag and drop operation went, and then re-arrange other data based on what the user did.  The logical method of doing this is to create events for the various drag and drop operations, and reorder the other data associated with it.  The problem is when you add events to handle the drag and drop, the drag and drop functionality changes, and the built in stuff no longer works the way it did. 

 

Usually for me this means re-writing the drag and drop functionality in LabVIEW to get the features I want.  But I always feel like the native drag and drop gets me 90% the way there, and it takes a decent amount of time to re-write it.  

 

So attached is one such example.  It comes from a post on the forums, but the concept is something I've seen many times.  At the start I register for one of two tree controls to have the Drag Over event, so that you can read where the mouse is over when a drag is taking place, and then determine where the drop will land if the user lets go.  But as soon as you register for a Drag Over on that control, dragging and dropping no longer works.  Why is this?  Is there an easy way to preserve the native LabVIEW drag and drop, but have some of the events for various drag and drop operations?

 

Drag Drop Test.png

Message 1 of 21
(6,299 Views)

I do not have experiences with drag and drop. I can only guess:

Did you control, that you do not trigger several drag and drop events at once and
handle ony one? If yes, you should explicitly drop all non related drag and drop events.

For example if you do an event structure for mouse handling and handle that "mouse enters area event"

and then press the mouse button while you are in that area you generate an "mouse button pressed event".

However if you don't care about the mouse button press you would perhaps not handle that event.

Which leads to creating an event without an event handling structure. As a result

if you handle the event "mouse leaves area" but the event "mouse button pressed" is still in the queue

your even handler for first event will not be called.

Thats perhaps an analougue case to your drag and drop problem.

 

0 Kudos
Message 2 of 21
(6,248 Views)

I know not everyone has 2015, but the snippet above shows one of the two event cases, and the other is Panel Close?  When I was trying to replicate the drag and drop functions I often would add mouse move/enter/leave events but for this example I wanted to simplify it.

 

Literally the only thing this VI does is register for a Drag Over event on one of two controls, tries to guess what the tree would look like if you droped (by using the get parent over and over), and stop the VI if you close the front panel.

 

I guess I should open it up and ask, who does drag and drop, and how do they do it?  I've ran into this issue on just about every drag and drop code I've had so I figured this was common.

0 Kudos
Message 3 of 21
(6,236 Views)

Hello Hoovahh,

I have looked into your question and found that there is a Corrective Action Request previously filed. The CAR is 90595.

 

In the CAR it states that this is the expected behavior for LabVIEW. The reason is if the user registers for a drop target event, the user has to implement the drag and drop behavior them self; LabVIEW will not do the built in behavior any more. This was done for several reasons, most notably, LabVIEW does not know if the user has already performed some drop operation that is inconsistent with built in behavior.

 

Assume that the user already moved the tree item into the tree, for example. Then LabVIEW would end up moving it again resulting in a double move which would not be good.

 

I hope that this helps you out.

Message 4 of 21
(6,166 Views)

@Alex.W wrote:

 

 This was done for several reasons, most notably, LabVIEW does not know if the user has already performed some drop operation that is inconsistent with built in behavior.


Yes it will.  There is the Accepted? output in the event structure case for the drop which I can set to false which would tell LabVIEW not to do the drop and I'll handle it myself.  Or if I put a True to the Accepted? It should tell LabVIEW that I want it to perform the default operation and accept the drop the user just did.  What is the purpose of this event being a filter event, if it isn't for telling LabVIEW to accept the drop?

0 Kudos
Message 5 of 21
(6,147 Views)

Thanks,Let me know this is drag and drop labview behavior.

0 Kudos
Message 6 of 21
(6,103 Views)

Hello Hooovahh,

 

I will look into this a little further. The answer I gave you is from the CAR about event structures and trees, but it does not mention a filter event.

 

I will see why this is the case.

0 Kudos
Message 7 of 21
(6,055 Views)

@Alex.W wrote:

Hello Hooovahh,

 

I will look into this a little further. The answer I gave you is from the CAR about event structures and trees, but it does not mention a filter event.

 

I will see why this is the case.


In my experience, "Why" questions are the hardest to answer but most enlightening.

Please let let us know what you learn.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 8 of 21
(6,022 Views)

Having the same issue, hoping for more information.





Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
0 Kudos
Message 9 of 21
(5,847 Views)

Not to muddy this up a bit but I have a semi related issue that is also bugging me.  Lets say I have some drag and drop operation I'm doing, and behind the scenes there is some other data that needs to go along with the drag and drop.  I want the drag and drop to work like the default behavior does, but when it ends I want to be able to see some of this extra data associated with the operation.

 

The seemingly right way to do it is on the Drag Starting? event, put some data into the Data terminal in the event, then when the drag is over on the Drag Ended, or Drop event, use the Get Drag Drop Data, primitive to read this extra data.  The problem is, as soon as you wire to the Data terminal in the Drag Starting? event, the drag and drop operation behaves differently.  What is with all these drag and drop functions, changing their behavior, when I don't ask them to?  Does no one use drag and drop in LabVIEW?  Or do they try, get frustrated by these types of issues and give up?  This demonstrates how drag and drop operations change their behavior by the act of adding an event, and by wiring to a terminal in an event.  All of my issues would just go away if the drag and drop worked like it does, and after the drag and drop is complete, I have a way of knowing what happened, what was taken from where, and where was it put.  This means what rows of what MCLB went to what rows in what MCLB.  It seems if I add code to try to peek into this, functions change.

 

Attached is an example where you drag from one MCLB to the next.  I want a copy from the left to the right, and a move on the right MCLB.  The way it is now the data will be read on a drop, but the cursor, and drop preview make it look like a drop will not take place.  If you delete the wire on the block diagram the copy and move and preview all work right, but the dropped data isn't available.

0 Kudos
Message 10 of 21
(5,680 Views)