disabling native ring drop down

[Chris_Co]

Does anyone know how to disable the native drop down menu for ring controls and enum controls. I have it working (disabled) when I use the filter event and discard the mouse down event. I pop up my own drop down in a sub VI in this event and this works perfectly. However, when I try to obtain the mouse down event for this control via a supervisory loop, I cannot discard the mouse down event as it seems to discard all events that are configured for this. I though a timer in the event case would give me enough time to receive the event in the supervisory loop, but alas no good came of it (never fires). Maybe I should describe it a little better:

I have two event nodes that are set up to trigger on a mouse down event. The first is filtered to remove the current LabVIEW droplist. The second loop is top run my code for my own drop down. This works flawlessly for each control type I want (string, numeric) except when labVIEW runs special background code for the dropdown. Why does LabVIEW destroy the mouse down for all event nodes if only one is filtered. I can use mouse up event and it works perfectly although I need the mouse down for the additional functionality I have already coded and works. I have a way around this but I WANT this to work this way for various reasons. I do not want additional code in the event loop like a queue or messaging construct to handle this. It would defeat the purpose of my experiment (of which I am sorry I cannot be more explicit in the details).

Why does my code need to be inside the event node in order for it to work? If there are two event nodes registered for the same event, they both should receive them regardless if one of them filters it out. right??

Thanks in advance

Chrisco

[0utlaw]

Hi Chris

Short answer: No, two event structures pointing to the same event will not always trigger.  You should never use two event structures targeting the same event - they might both receive the event, or just one.  Not a good situation.

Longer answer: refer to this KnowledgeBase:

KnowledgeBase 2P5ENOFP: Can I Use Multiple Event Structures To Handle The Same Event In LabVIEW?

http://digital.ni.com/public.nsf/allkb/0C0E611DF8F5B6F086256C2C0072085E

It sounds like there's probably a way to do what you're looking for, but I don't think two event structures is the way to go about it.

Regards,

[JÞB · Accepted solution]

From an obscure place in the LabVIEW Help file:

For filter events, LabVIEW sends the event sequentially to each Event structure configured for the event. The order in which LabVIEW sends the filter event to each Event structure depends on the order in which you register the events. Each Event structure must complete the filter event case before LabVIEW can notify the next Event structure. If an Event structure case changes any of the event data, LabVIEW passes the changed data to subsequent Event structures in the chain. If an Event structure in the chain discards the event, LabVIEW does not pass the event to any Event structures remaining in the chain. LabVIEW completes processing the user action that triggered the event only after all configured Event structures handle the event without discarding it.

So, you run the vi with the filtering event loop before running the vi with the non-filtering event loop, the filter event would register first (Events register when a vi containing static events is run).   Changing the code to register both events as filter events and making no mods in the first event loop should allow you to act first then filter second.

[Chris_Co]

Jeff,

Your suggestion to make the supervisory loop the filter was the answer since there no longer is a need to put an event in the producer loop (filtered out already) works like a charm. I think the issue was my understandin of registering for the filter mouse down on the producer loop actually enqueues the mouse down event (no filter) of the second loop. I though these were two seperate events when in fact they are not. Thank you Jeff for your awesomeness.

Tom L,

I thank you for your time in answering. Unfortunately, there is no way you can convince me that events are not a good way to handle one to many messages (they are not my preferred method) but I understand that they work fantastically. I used these before moving on the the queue messaging. The document you referenced points out a situation where a programmer was using events as program flow. It does not matter which messaging system you use, it is poor practice to use messaging to perform program flow. If you do not believe me you might want to check out Veristand and how it handles shutdowns and shuch. Events are an acceptable way to handle many things provided you do not use them for timing or dataflow. I have even added responses to the events sucessfully, but even then this was not to be used as dataflow.

BTW, it does work with both events, it is just that i do not want both. I did not think to have the supervisory loop have filters, but thanks to jeff works like a charm.

ChrisCo

[0utlaw]

Good to know, and nice find Jeff!  I could have sworn that this came up at one of the LV sessions this last NI week and at that time it was mentioned that which of the two events would fire first (or even whether both would fire) was indeterminate and this scenario should be avoided at all costs.  I may be misremembering, though- sometimes the sessions start to bleed together.

Regards. 

[JÞB]

---

@0utlaw wrote:

Good to know, and nice find Jeff!  I could have sworn that this came up at one of the LV sessions this last NI week and at that time it was mentioned that which of the two events would fire first (or even whether both would fire) was indeterminate and this scenario should be avoided at all costs.  I may be misremembering, though- sometimes the sessions start to bleed together.

Regards. 

---

The situation should not be avoided at ALL costs but, you need to have some arcane knowledge of LabVIEW Trivia before attempting to code this type of application. 

Without the new event viewer (New feature of LabVIEW 2013) I would not have even mentioned that this was possible since, - well its darned hard to "Guess" what events are firing when and with what mods. 

A Quick request to posters:  If you have a few moments and can whip up an example of this it would fit nicely on the "Micro-Nuggets thread"

[Chris_Co]

I coded a small example of what is happenning. Unfortunately, i do not have 2013 so I will have to go on guessing. I do however disagree with

" LabVIEW completes processing the user action that triggered the event only after all configured Event structures handle the event without discarding it."

If you put timers in the supervisor loop, it does not affect the top loop timing. I believe the GUI loop must complete before generating the events for the others

[JÞB]

"LabVIEW completes processing the user action that triggered the event only after all configured Event structures handle the event without discarding it." is a little ambigeous.

That seams to infer that any notify event has the opportunity to modify or discard the event before any user action is processed.  What happens if the user action event is registered as both a notify and a filter?  Does order of registration effect if the filter event mods apply before the notify event is processed? The event inspection window would give us some insight (I think.)   I might have to play with it when I have time.