Drag/Drop Listbox with disable

[Frozen]

It makes it soo much easier to help when the people put in the work before they ask questions and are willing to learn... and sometimes, it is easier to ask and get an answer in a day then spend a week banging your head. 😵

[BrianK75]

Bert,

I cannot open the V5 that you posted. I am working with LV2019 and I believe it was in a newer version.

I was able to see a bit of the snippet you posted.  I assume it was in the DragEnter event case for each time.  It appears that you configured the DragEnter event to only enter the MCL IF the drop was true AND the MCL was enabled. 

I cleaned this schematic up and removed all the naming code.  So, the drop item will not be listed when it is dropped into the MCL (not desirable but this wasn't my original problem). 

I also removed all the Allow Dropping nodes and unneeded items.  Each MCL is enabled or disabled depending on the count.  

I am posting 2 versions of this.  

V6 does not work properly but is shows that while the case structure is capable of enabling and disabling depending upon the count, the event structure will allow drops even to MCLs that are disabled.  I assume this is because the event structure does not recognize what the count is? It is downline of the error line within the same loop so this confuses me as to why the event (which is tied to a particular MCL) would not adhere to the property node set forth on the current loop just prior to execution. 

I would think that the disabled MCLs would still be disabled prior to and during an event.  However, it seems all MCLs reset to enabled once an event starts.  This still seems odd to me and was a very long and tedious lesson to learn.   

V7  is working.  This includes what bot Frozen and BertMcMahan emphasized. It includes moving the desired MCLs enable property node within the DragEnter to allow dropping (or the item to enter the MCL prior to dropping).  This effectively enables the undesired MCLs 

[wiebe@CARYA]

---

@Frozen wrote:

It makes it soo much easier to help when the people put in the work before they ask questions and are willing to learn... and sometimes, it is easier to ask and get an answer in a day then spend a week banging your head. 😵

---

Drag and drop is way too difficult. I can see how looking into it just confuses things.

I don't recall using D&D with listboxes much, but mostly with trees. Listboxes might behave better.

I'd expect that if you implement a Drag Starting? event, and never discard, everything works as before. But it doesn't. In a typical application, this means you now have to keep state you get in the start event, do hit detection manually, and implement a drop event. It's just weird that you get standard D&D for free, but when you want anything different, you're entirely on your own.

[BertMcMahan]

Sorry about the version issue. I've attached it in 2019.

I tried your v7 and it's not cycling through the cases, so it seems like it still needs a little tweak here or there. The code does look much better though.

(BTW: You don't have to have a Timeout case if you don't need a Timeout case).

[BrianK75]

I had to put back in some of my original code.  First was the second while loop.  It is necessary because once a drop is made, the drop T stops the while loop and allows a count increment/decrement to be put onto the shift register line for the next loop.

Second, I had to put back my original enable in the case structure prior to the event.  This causes me to have 2 of the same property node for enabling the same MCL in a row.  Otherwise, it doesn't work.  This adds to my confusion as to why I need to declare enabled initially only to once again declare it during the the dragenter event.  

But...it works now. 

Also, the timeout is in the event structure. it is event 0. 

[BertMcMahan]

I meant you don't need to have a Timeout case. Just delete it, you're not using it for anything. Right now you write to a bunch of property nodes 5 times a second for no reason, so you could save some processor effort.

I also understand what you're doing with the multiple While loops, but it's not a great solution going forward. You only need one loop to do what you're trying to do. You just need to make your disable/enable code conditional. I'd recommend a subVI rather than a Case structure anyway. This would be a great place for an action engine- use one case to load an array of references, and another case to enable one case and disable the rest. Then you could call that subVI anywhere you'd like, and wouldn't have to manually mess with the sequencing.

Did you try my code as-is? It does what I understood you wanted it to do.

[BrianK75]

Actually neither worked (V8 or V5(1)).  Your V5(1) does allow each MCL to be greyed and disabled, however you can still drop to it.  This is because we placed the disable in the DragEnter and not the Drop event. Therefore the disable needs to be in both events in order to work. Also, I noticed that the names concatenated during the pop up when you made it to the second cycle. Both of our versions did this so fixed it with V9.  I also took your idea of preloading the player list.  I am actually reading from a .csv to populate my original project list but this works for this example now.  I also enabled a ItemsNames property node to rid the MCLs of previous drops (the reinitialize to default does not seem to clear/delete MCLs). 

Also, I noticed that you made mention to a bunch or property nodes being enabled in the beginning of my case structure to set the properties for no reason.  It appears that in V5(1), you are doing the same thing, you just relocated them to a case structure within each Drop event.  

I am attaching V9.  This works.  I did not clean up the wiring as this is not the project I was originally working on.  The NFL scenario was just an equivalent routine to my project and easier to get involved with than my company's acronyms and programming  constraints. 

I still go back to my original question of why we have to disable the property multiple times (up to 3 per MCL-initial state/DragEnter/Drop).  If the item is disabled, it should be disabled. An event should accept the state that an indicator/control/list is set to at the beginning of the code and stay in this state until is it changed.   I am sure there is a wonderful reason why we have to tell something to disable 3 times before it fully listens but I must move on to my next learning lesson. Who knows, maybe LabVIEW SW has developed an internal AI and is channeling Bill Clinton to have fun with the definition of "disable".  

[BertMcMahan]

Hah, you're right. You'd need to check the Drop event too.

Also I think we're on a different page about the property nodes; I call it once at the beginning of the program (and never again) but you're calling it every loop. I included the disabling inside the Drop structures. Just a different way to do things.

Regarding concatenating, you're right they stick together; I was just focusing on the Drop behavior.

Regarding disabling: You do NOT have to write to it multiple times. I think you're getting confused at the wording. "Disabled" doesn't mean "Completely locked and you can't change anything". It means "The user can't mess with it". The program can still interact with a control (to change its values or color) and drag/drop still works (as you've noticed). Disabling the control has nothing to do with drag and drop.

The part of your code that's stopping the Drag/Drop from happening is the event structure. The Drag Enter function fires when you enter the space; wiring a False to Accepted? means the cursor indicates an invalid drop location.

When you Drop something, the Drop case always fires. Whether your program does anything with it or not is up to you. When the user unclicks the mouse over the target, the Drop event case is called- but notice this happens after the user has Dropped something. Whether your code chooses to process anything with that drop is up to you, which is why you check for Disabled before doing anything with it. Drop's Accepted terminal tells the Drag source whether or not the Drop worked. If Accepted is True, it fires a Drag Ended event in the control that started the Drag.

If the user cancels the Drag or if the target rejects the Drop (i.e., Accepted = False), the Drag Ended event will fire with a result of "Drop Cancel". If the user Drops and the Drop event returns Accepted = True, then the Drag Ended event will return a result of "Drop Move". If the user holds Control while Dropping, and it's accepted, the Drag Ended event will return a result of Drop Copy.

Right now your table has the Drop behavior of Move Only, meaning it's handling the removal of the item automatically (this is set via the right-click menu). This is due to the MCLB's automatic drag and drop behavior. Start a new VI and run it, you will see you can drag and drop items between MCLB's without any code. That's where the AllowDragging property node comes into play (it handles the automatic stuff). Just letting you know that so you understand why some stuff is automatic (for example, your code doesn't manually remove the item from the Drag Source since it's handled automatically). In other words, if you don't override that behavior with an event structure, there might be some other stuff going on that complicates things.

[BrianK75]

I understand how the event dictates what can and cannot happen in regards to mouse up/down, drag enter and drop. 

Right clicking for the behavior of the drag source and drop lists were done at the beginning of this code to ensure that items came off the master list. The swapping between team lists would not have been an issue no matter the state because if the other team lists were disabled, as in did not function,  or disabled ,as in blocked from user interaction but functioned programmatically,  it would not have allowed the user to transfer players between teams. 

You are correct, concerning where I put the property nodes in the case structure ahead of the event case.  There is no need for them to fire off before every loop and event.  Once before the entering the while loop should be enough and when selection or a drop is accepted, the next enables. I initially tried to enable and disable depending on which team's turn it was. 

I may be mistaken but I do not recall seeing anything the documentation that stated disabled only applies to the front panel.  

I guess the lesson in all this is that disable only applies to the front panel and not programmatically.  The programming still has to manipulate a combination of actions concerning the front panel in order to validate what it can do programmatically.  This still seems like the scenic route. 

If I were to disable a microwave by removing power from it, it doesn't stop anyone from opening the door and placing a some Beenie Weenies in it.  Of course the operator would see that something wasn't working correctly.  Just like I saw this routine wasn't.  But, most users would have seen the clock or power led wasn't on and know it wasn't available for use.  Alas, cold Beenie Weenies it is unless you have a match and a old can of sterno.

Maybe  an OFF/ON that actually programmatically suspends items?  Or next to the disable property, we can add FP or ....disable (kinda).