Naming event cases

[Florian.Ludwig]

Hi,

I'd like to know if there is a convenient way to change the names of the cases in an event structure or to identify the cases in any other way.

The problem I'm experiencing: Whenever I have an event structure that has several cases which monitor several inputs each it is not apparent at first glance what a certain case does. For example I'd like to name a case in my event structure "update display" so that I know what it does and not which front panel element changes cause it to execute (of cause one must still be able to view this :-).

Any suggestions?

Regards Florian

[GerdW]

Hi Florian,

the event structure cases are named by their "workload": they show the control name and the event type (like: "FP control: value change").

What else do you need here?

If you want to change/extend the existing behaviour you should post in the Idea Exchange...

I would not opt for such an idea, as you can easily separate the event structure (which is "analyzing" the events) and a state machine (which is doing the work). The state machine gets command with a typedef enum - that's the place to create names like "UI update".

Btw. there's a pattern called event-driven state machine! I think, that's what you need...

[smercurio_fc]

It sounds to me like you're looking for a Producer/Consumer architecture, in which the consumer is a State Machine.

[Florian.Ludwig]

Thanks for the answer GerdW,

I am indeed using that exact design pattern. The inconvenience comes when editing the event structure.

I have a case where I enqueue "UI update" as typedef'ed enum. That case shows as ("FP control A", "FP control B", ... "FP control Z": value change) - like you said, but sometimes there are a lot of cases in an event structure.

If I'd like to find the case where I enqueue "UI update" (to add or remove monitored FP controls for example) a name for the case would come in handy like (UI update "FP control A... : value change).

Maybe it's for the idea exchange, but maybe it's just a question of using best practice. I'd welcome suggestions/criticism like "that's only a problem because you forgot to..."

Regards Florian

[smercurio_fc]

Well, I supposed you could use user events. That won't do exactly what you want, but it's a little closer.

[Ben]

Another approach is to edit the names as you would like to see them in the Event Structure and then only show the caption of the FP.

Ben

[rpursley8]

You can also document your code and place a big sign in each event describing its function the way you want it described.

[Ben]

---

@rpursley8 wrote:

You can also document your code and place a big sign in each event describing its function the way you want it described.

---

If we are talking about what appears inside the Event structure, yes I strongly agree. I also recomend placing the controls for which the event is registered inside the event case. This makes finding the right event case just a matter of "double clicikng" the control on the FP.

Ben

[Florian.Ludwig]

Thanks for all the suggestions,

I'm already using only captions on the FP (advisable for many reasons imho), and once your inside the case the typedef'ed enum does a decent job of documenting which case you're in

(though Randall is right - bigger is better here, especially when you're "ctrl-mouswheeling" through the cases :-).

I just wished there was some clue visible in the event structure drop down menu. The event structure I'm working on has about 70 cases some of which monitor more than 20 FP controls.

Scrolling is not that convenient either - and yes there's a lot of FP space in a tab control.

That's also why user events would be too much work to do now for only a marginal improvement.

Regards Florian

[Ben · Accepted solution]

---

@Florian.Ludwig wrote:

Thanks for all the suggestions,

I'm already using only captions on the FP (advisable for many reasons imho), and once your inside the case the typedef'ed enum does a decent job of documenting which case you're in

(though Randall is right - bigger is better here, especially when you're "ctrl-mouswheeling" through the cases :-).

I just wished there was some clue visible in the event structure drop down menu. The event structure I'm working on has about 70 cases some of which monitor more than 20 FP controls.

Scrolling is not that convenient either - and yes there's a lot of FP space in a tab control.

That's also why user events would be too much work to do now for only a marginal improvement.

Regards Florian

---

Have you concidered a "divide and conquer" approach by which I mean pushing some of those events down into a sub-VI that uses Dynamic Event Registration to do the work?

Examples of things that can be pushed down are things like "Whn this button is clicked this thing should be hidden/shown.

Ben