Event structure mischief.... suggestions?

[smallmediumlarge]

Re tst: 

Thanks for pointing that out about event registration, that is definitely important

Also thanks for looking at my code. You're right, it's not the complete code, however it is identical to what is in my actual program.

The reason my code is a bit jumbled I guess is that I didn't really know how to build a good architecture when I started. I read that

having an event-handling loop and a queue-based message handling loop was a good design and went with that.

To respond to some of your points,

1) My original intention in encapsulating the event structure in a subVI was to "clean up" since my original code was rather unreadable. This plainly back-fired a bit, and I think I will make the change you suggested. It might even solve the problem, since now I don't need to register for front panel controls dynamically, only the user event.

2) That was a mistake, and should have been in there. 

3) When used with my application, the VI is reentrant, and so are its event and message-handling loops. 

I had switched to non-reentrant for debugging because I was only running one instance, and it was bugging me that double-clicking on an icon opened a clone instead of the original. 

4) I see what you are saying. I might not even need queue-based message-handling, and could do everything with the event structure, which would simplify my block diagram quite a bit. 

All in all, thank you for the suggestions; I will make some changes and hope they work out, though I am still puzzled as to the source of the error. 

[smallmediumlarge]

Hi JackDunaway, 

Thank you for the pointers and kind words. I'm pretty sure I watched a video of one of your lectures when learning about user events 🙂

[smallmediumlarge]

---

@altenbach wrote:

---

For example, I might have two event structures that listen for a value change of a boolean. One event structure will do some recalculation based on the new value while another event structure would change the range of a scale or the visibility of certain controls. Both will execute when the boolean is changed by the user. I typically have a parallel loop that exclusively handles cosmetic UI stuff.

---

I know this discussion is finished, but thanks again for this idea, I've spent some time thinking about how to restructure my code more effectively and I didn't realize at the time how useful it could be to have separate event queues for program operations, UI, and message handling. I now think this is what I'm going to do.