Ability to Diagram Disable ("Comment Out") a single Event Case in Event Handler Structure

[JackDunaway]

It would be useful to be able to disable the handling of a single Event Case in an Event Handler Structure. Note that this is distinctly different from merely Diagram Disabling the contents of the Event Case; using that method, the Timeout event case will be reset, and additionally program execution will continue past the Event Handler Structure (in the example below, continue to the next iteration in the While Loop).

Here's an example of what a Disabled Event Case might look like - the Event Structure and contained code is "washed out" as if Diagram Disabled - additionally, the disabled event in the list of Event Cases is struck-out and in italics:

And here's a proposal for how one might disable a given Event Case, using the context menu that pops up by right-clicking the border of the Event Handler Structure:

[Intaris]

In addition tho this idea which I've already kudo'd I have often thought it would be useful to be able to copy and paste individual event structure frames.

Refactoring code with event structures is a somewhat laborious operation.  The same would most likely apply to case structures.

I'd love to be able to simply drag and drop a single frame of one event structure to another event structure.

[johnsold]

Jack,

I think this is a good idea.

My concern is that the "washed out" look part needs fine tuning.  As shown in your image it would net be clear whether the entire structure was disabled or just that case.  If one of the enabled cases is visible, would there be any indication that another case was disabled without pulling down the selection menu?

I don't have a good idea of what needs to be done, but I have some discomfort with this appearance.

Lynn

[David_L]

I like this idea, but agree with Lynn.  My thought would be to have the frame be not washed out, but the inner code washed out.  Then you can also put a slash through the case selector terminal.

[X.]

If the Diagram disable structure was a bit more "capable" (as in auto-connect wires through the "enabled" case, wink wink NI), you would have a simple workaround. Except for the event firing very briefly... but would that be a big deal?

[dthor]

---

@X. wrote:

Except for the event firing very briefly... but would that be a big deal? 

---

Yes, that's the whole point of this suggestion. JackDunaway doesn't want the event to be fired at all, as fired events reset the timeout counter.

[X.]

I just wanted to learn when this is needed in practice... I understand the case where you don't want to go through the hoops of an event case, but disabling the event altogether (with the consequences described in the original post and kindly reminded by you) is a completely different thing (unless again the loop is merely here to enclose the event diagram, so the iteration index is never really checked and the timeout event is not even included).

[JÞB]

Jack- The idea is BRILLIANT!  I agree with David that washed out needs fine tuning.  What about a case that handles multiple events and, we only want to disable a subset of the events handled by the case?  What if we wish to programatically enable/disable specific OS generated events?  The idea makes me drool just a little.

[AristosQueue (NI)]

> What if we wish to programatically enable/disable specific OS generated events?

You can already do that with dynamic event registration node --- you can change out the events for which you are registered inside the event structure, including setting the event refnum to "not a refnum" so that you're not registered for anything in that position.

[JÞB]

> What if we wish to programatically enable/disable specific OS generated events?

You can already do that with dynamic event registration node --- you can change out the events for which you are registered inside the event structure, including setting the event refnum to "not a refnum" so that you're not registered for anything in that position.

---

Of course I knew that-  I was imagining something like a registered event property node and my mind flew off track right into the dynamic event without even recognizing it.

[JÞB]

> What if we wish to programatically enable/disable specific OS generated events?

You can already do that with dynamic event registration node --- you can change out the events for which you are registered inside the event structure, including setting the event refnum to "not a refnum" so that you're not registered for anything in that position.

---

[JackDunaway]

---

@johnsold wrote:

My concern is that the "washed out" look part needs fine tuning.  As shown in your image it would net be clear whether the entire structure was disabled or just that case.

---

---

@David_L wrote:

I like this idea, but agree with Lynn.  My thought would be to have the frame be not washed out, but the inner code washed out.  Then you can also put a slash through the case selector terminal.

---

Yeah, you're both keying in on actually the one thing that got the most scrunity when creating the proposed visual design - is the frame washed out or not?

The answer is predicated upon what an Event Handler Structure implementation actually "looks like" - do the collection of Event Cases reside within a single Event Handler Structure frame, or does each Event Case have it's own frame? I see each as having it's own frame, and therefore it should be washed out, but I can totally be conviced otherwise. (For instance, consider the degenerate Event Handler Structure that only has one Event Case. If you disable that case, should the entire frame be washed out? I say yes)

Another separate but related issue is whether terminals into and out of the structure should be greyed. You'll notice I greyed the output Bool and the input Error, yet the DynEv terminal is not greyed, which are all intentional (and agonizing , and perhaps incorrect  ) decisions.

I think we can converge on the important point here, and that is as long as the visual design portrays an accurate analog of what's conceptually happening, justice to LabVIEW prevails and we're all happy!