LabVIEW
Moving Objects with Mouse using Dynamic Event Registration
LabBEAN wrote:
In that case, enjoy the freedom that follows deleting that "Idle" item in your enum 😄
I noticed that right before posting the VI, almost changed it to "Initialize" to hide the name, but figured nobody would catch it. Well, you caught me.
(Actually, Idle does have it's merits in some of the loops. This command typedef services many similar processes, some of which have a desirable freewheeling Idle state)
LabBEAN wrote:
The Q ref's are passed to all loops in the beginning.
That's how I used to do it before wrapping the Q ref's in AE's. Readability has become a breeze - even for the inherently difficult task of tracing asynchronous messaging - by using the "Find All" functions. You will notice on the Idea Exchange that I have suggested many improvements for these "Find" functions that would make such tasks more powerful and enjoyable.
LabBEAN wrote:
And, here, you are exercising your right to personal preference by using the Action Engine instead of discrete VIs.
?? Action engines are discrete VI's. What are you calling a discrete VI here?
JackDunaway wrote:
...you caught me... Idle does have it's merits in some of the loops
Maybe I get away without one by using a Timer loop.... Like you, we share the same "command" type def between all the loops.
JackDunaway wrote:
?? Action engines are discrete VI's. What are you calling a discrete VI here?
"The four actions are Create, Send, GetRef, and Destroy". These could also be 4 discrete VIs. Action Engines, although useful at times (e.g. is my USB debug key plugged in -- well this would technically be an LV2), violate the principles of Loose Coupling and High Cohesion. In this case, the only data that your AE is providing these functions is the queue refnum:
JackDunaway wrote:
That's how I used to do it before wrapping the Q ref's in AE's. Readability has become a breeze - even for the inherently difficult task of tracing asynchronous messaging - by using the "Find All" functions.
Option 1:
Couple the queue refnum with the queue functions and create a separate AE for each queue refnum you use.
Drop the appropriate AE everyhere and wire an action.
"Find All" for queue operations having to do with a specific AE (e.g. GUI).
In our case this would be five AEs.
Option 2:
Use discrete wrapper VIs for Create Queue, Enqueue, Dequeue, Destroy Queue, etc.
When enqueueing to another loop, unbundle the reference and wire it in.
"Find All" for a specific queue operation (e.g. Enqueue).
Option 3:
Use queue specific discrete wrapper VIs for Create Queue, Enqueue, Dequeue, Destroy Queue, etc. (e.g. create and release queue reference each time -- except in Create Queue, just create).
"Find All" for a specific loop AND operation (e.g. Enqueue GUI).
Tradeoff: tiny performance hit by creating and releasing queue refnums
I haven't had the need to "Find" queue wrappers so far (maybe because of my debug tools?). Either way, though, pushing an Enqueue outside the case structure for each loop (rather than dropping it with every enqueue) and wrapping it in a For Loop allows enqueueing multiple items or no items to the native queue with each loop iteration. To enqueue to another loop, you drop an Enqueue at that point.
OK, I am beginning to understand where you're coming from, let's see if I can reconcile why I like these "weakly cohesive" AE's for the benefit of a "loosely coupled" application architecture:
You are arguing that the message wrapper itself has weak cohesion, and is "loosely defined" since it's unclear exactly when the inputs should be wired. We agree that taking my AE and splitting it into 4 discrete VI's would be ridiculous, because there are 4 primitives that do the job! And those primitives are very strictly defined, with no questions for "unused inputs" (since there aren't any). So basically, if we nix the weakly cohesive AE in favor of the strongly defined primitives, we end up passing the control refs from Top Level Creator, to SubVI, to SubVI.... And if you have a SubPanel architecture (I do), you end up having to pass the Control References via "Control Value Set" method to the VI inserted into the panel (which I really dislike for it's fragility).
Instead, wrap those Control Refs in an AE, and you have no data coupling (where coupling is due to dataflow of the Control Ref wires going in and out of connector panes) between your top level VI's and user VI's inserted into SubPanels. (By the way, named queues would be one method to get around this type of coupling, but it doesn't work for Notifiers and User Events)
Using the "loosely defined connector panes" of the Messaging AE's is simply where familiarity and training comes in: I have lots of those messaging wrappers, and they all behave the same with those same four actions. I can be guaranteed that almost all the time there will be one Create, one GetRef (the consumer), and one Destroy. All the rest are Sends (which, consequently, Send is the default input - I leave that input unwired since it is used most - and familiarity and training tells me that's a "Send"). Also, I can do a "Find All" on that VI, and immediately jump to every single message sender. THAT's the biggest advantage of this entire construct - being able to very quickly find all instances of who is talking to who in the entire application architecture.
For instance, if you pass in a control ref into a SubVI and it goes into a large case structure, what all cases send messages (or destroys the queue, or sneaks a few items out, or passes into another VI which does some of the above??)?
On the other hand, if you have a Messaging Wrapper, it's easy to find all instances of talkers on the asynchronous messaging system:
I'm certainly open to suggestions, comments, questions, and insults - any architecture set in stone is doomed to fail eventually.
