Here is something more to think about.
I am a bit of a purist and I do not like sharing data (references) between independent loops. A control refnum is a reference. Using a DVR is a reference. By sharing it, you have given multiple point of control over that reference. Yes, it is easy but it can get you into trouble.
I like to think about an EventLoop as an actor with a different communication mechanism. Messages are not pushed to a queue but made into a UserDefinedEvent and signalled on the EventLoop's event ref. You add that Dynamic Event Terminal and handle the 'user defined event' as if it were a message.
The EventLoop is now a client to the Actor. It should receive update messages from the Actor. Processing these updates causes the EventLoop to update the controls. You can create a map of Actor state values (by name) to control refnum within the EventLoop. Note that the Actor does not have to broadcast its entire state but can be selective. An actor that represents a motor might be on or of, have a set speed and an actual speed, and have a direction. You could pack this up into a single message but you don't need to.
When the EventLoop needs to change the Actor in some way then the EventLoop gets the value from the UI control and package a message up to the actor and as typical with AF Enqueue it. That message probably will result in some Actor state change and the EventLoop will hear about it.
Now think about the EventLoop as a class, one method in that class contains the LV event structure. The private data of the class has the mapping between Actor state value and control. And I can register multiple instance of the same class by sending the Actor the EventLoop instances UserDefinedEvent refnum. Now a bunch of EventLoops are 'listening' to the same Actor and getting updates. This seems a bit silly if they are all identical, but what if the EventLoops were actually slightly different. Maybe one EventLoop shows a historical plot, another shows a grid of data, and yet another shows an animation based on this. The Actor now knows nothing about how its data is being presented (or values being controlled for that matter), it is only sending updates to anybody that cares and acting on message from anybody that is listening.
One more enhancement, the method vi that contains the LV event stucture can be 'told' where to display itself. Now I can create a primary user interface with multipl panels. I 'tell' each one of the metthod vi's to display itself in a specific panel in the primary user interface. Now I have one window presenting different 'views' of the Actor at the same time.
It is a step, alright maybe a couple steps, beyond the simple EventLoop per Actor. But I am hoping that you all might ponder on ways to maintain data encapsulation instead of sharing common memory. As a caveat, sometimes there are reasons to share memory most notably performance, but the use case for most Actors I have some across, the publish of discrete data via messages has worked well.
If I was not too clear, let me know.
-Kurt
