listbox drop event bug

[littlesphaeroid]

I have two (multicolumn) listboxes. I can drag and drop between them. but when I create a drop Event for one of the listboxes, the drop does not work. I have attached a VI showing htis problem. You can drag form the first listbox tot he second, but not to the third. note this is because the third has a drop event enabled. 

I thought I could work around this my using the mouseup event on the target listbox, but mouseup only works on a control when mousedown happened on that control (or so it seems).

I was so happy to find this capability native to recent versions of Labview, but now I"m unsure of how to take action on a successful drop in my state machine.

[.aCe.]

Hello littlesphaeroid,

This is not a bug, you are overriding the default behaviour by having an event on the block diagram. So you will need to handle the items manually. Use the Drag Starting? event to determine the data to move and drop to add the items to your list.

This example does what you want to do:

https://decibel.ni.com/content/docs/DOC-19895

There are some forum posts too:

http://forums.ni.com/t5/LabVIEW/drag-and-drop-from-Multicolumn-listbox-to-another-Multicolumn/m-p/10...

http://forums.ni.com/t5/LabVIEW/Drag-and-Drop-Listbox-Help/m-p/2419954#M746878

Hope this helps.

[littlesphaeroid]

Thanks for your help, but I'm afraid you are wrong.  As you can see, there is a terminal to accept the drop in the event frame.  This means, with other events, to allow the default behavior of the event to take place. Wiring a false here would override the default behaviour, but this is not what I want. What I want is to put an item in my state machine queue on the drop event. In this case, the items should drop and appear in the new list, and then I can act on the new lsit values. If this were not the expected actions, then why would be have an accept criterion? This is why this is a bug.

The trouble with coding around this is that it takes a LOT of code to get the default beahviour (copy, paste, drag, drop...). I know, becuase I've coded this up before, and it's ugly, and it doens't work as well as the default behaviour that we now have in recent versions of LV. Going backwards is not on my menu this week.

What I'll do is figure out a workaround, such and using another event, such as stop dragging, but that's going to be a pain too, since I only care about the drop a particular control I can just check if the list has changed... it'll be easy enough.

[arevh]

Hello,

If you need to detect if there was drop event, maybe you can use Value change event instead. In any case if you drop to the listbox, its value will be changed.

Thanks,

Arev

CTO | RAFA Solutions

[littlesphaeroid]

Great, you're right, the value does change on drop. But this reveals ANOTHER BUG! The new value indicated in the Event strucutre indicates the drop position, but the actual value of the control will not be set to this value. The next drop will indicate an old value of empty array, even though the new value from the previous drop was not that value. This is clearly a bug!

So, two bugs, one post. 

Weird.

[.aCe.]

---

@littlesphaeroid wrote:

Thanks for your help, but I'm afraid you are wrong.  As you can see, there is a terminal to accept the drop in the event frame.  This means, with other events, to allow the default behavior of the event to take place. Wiring a false here would override the default behaviour, but this is not what I want. What I want is to put an item in my state machine queue on the drop event. In this case, the items should drop and appear in the new list, and then I can act on the new lsit values. If this were not the expected actions, then why would be have an accept criterion? This is why this is a bug.

---

Sorry to disappoint you but I am not wrong.

The 'Accepted?' terminal is a provision to discard any invalid / wrong type / unexpected data being dropped. It's not to allow / override default behaviour as you describe.

Please read this post from Jeff P of NI (who I think implemented this feature):

http://forums.ni.com/t5/LabVIEW/Tree-Control-Drag-Drop-in-LabVIEW-8/m-p/305701#M158970

Spoiler

Certain drag/drop user events override built-in LabVIEW drag/drop behaviors.

More specifically:

* If you register for "Drag Source Update" on a drag source, LV will no longer do its built-in behavior for updating the drag source. Instead, LV leaves that entirely up to you.

* If you register for "Drop" on a drag target, LV will no longer do its built-in behavior for updating the target. Instead, LV leaves that entirely up to you.

This sample VI has registered for "Drop", and so at run time step 2 doesn't happen. If you register for the "Drop" event, you have to implement that Drop behavior yourself, in G.

---

@littlesphaeroid wrote:

The trouble with coding around this is that it takes a LOT of code to get the default beahviour (copy, paste, drag, drop...). I know, becuase I've coded this up before, and it's ugly, and it doens't work as well as the default behaviour that we now have in recent versions of LV. Going backwards is not on my menu this week.

---

I agree it is extra coding but I don't think its a lot of coding for the flexibility and data validation it offers! You just have to implement 'Drag Starting?' event on the source control, store the Drag Data. Implement 'Drag Enter' and 'Drop' on the target.

There are examples that ship with LabVIEW such as this:

examples\Structures\Event Structure\Drag and Drop - Passing Custom Drag Data.vi 

Hope this helps.

aCe

CLA, CTA

[littlesphaeroid]

Great, this is helpful and I appreciate your comments. I was able to get the same result using the value change event on the dropped-on listbox. Perhaps you can explain why the value changes on drop (to no selection), and why the new value offered in the event is incorrect (shows dropped position).

[arevh]

I can't see any bugs with the values. Any time you drop a new item in the listbox it returns its value in the listbox, i.e. position. The value of the listbox is the position of the selected cell and any new dropped item becomes selected, returning its value.

Thanks,

Arev

CTO | RAFA Solutions

[Hooovahh]

Everyone seems to have an issue with this, me being one of them.

http://forums.ni.com/t5/LabVIEW/Why-Does-Adding-an-Event-Change-Drag-And-Drop-Functionality/m-p/3217...

The event looks like a filter event, with an Accepted terminal on the right which should behave like all other Discard? terminals telling LabVIEW to do it's thing, or I'll do it.  This apparently was not the intended use, I suggest it should be, or another provision made so it could be.  Of course since drag and drop hasn't changed much over the last 9-10 years I doubt much will change now.

Implementing drag and drop in a way that is intuitive to the user in LabVIEW is a pain, and generally means re-writing all of the drag and drop code on your own.  This means lots of code you now have to maintain that you didn't think you would have to because LabVIEW supports drag and drop right?Adding drag and drop manually isn't too big of a deal, but then there are all the edge cases that you want to support that maybe you didn't realize you would need to write code to handle.  Then there are some cases were getting the default behavior means coding yourself into a corner.  Like having the drag over function showing where it will be dropped if the user let go, which only works right if you avoid doing certain events.

This is a bigger topic, and one that from what I've seen, developers have just been living with the limitations (or increased development).

[littlesphaeroid]

Hooovah: You are right. I thought about this more and I still inssist it's a bug. What alse could "accepted?" mean than to accept the default action of the drop?