First foray in LVOOP mixed with Action Engine functionality, would appreciate comments

[Neil.Pate]

Hello (LVOOP) experts!

I am a big fan of Action Engines (AEs), and use them very regularly.

Now, say I wanted to have a Logging module that writes text to a log file, I can create an Action Engine for this and all is well, i.e. I can drop this VI anywhere in my hierachy and it basically just works. I like to encapsulate AE in a lvlib.

So, what if I wanted a second Logging module, doing exactly the same thing, but operating on a different file. Well, I could create a new copy of the Action Engine in the project, duplicating the code and giving the second AE a different name. This is of course a bit clumsy, as what if I wanted 100 of these!

I suppose I could make the AE re-entrant (cloned) use VI server to obtain a second copy of the AE, but I have not tried this.

So what I decided to do is make a LV Class, and just instantiate a second class as needed. I really really really like the ability of AEs to drop them anywhere without wiring all the way through the hierachy, so that was a design goal with my LVOOP implementation. As far as I can tell, one way to do this is using single element named queues (sort of a singleton design pattern).

The attached code is my attempt, I would really appreciate comments, both positive and negative.

[tst]

What you've basically built is a SEQ-based, by-ref class (although you pass a name, not a reference), which is certainly a valid construct. dqGOOP has been doing that for years and the singleton example also uses this, as you mentioned.

Some comments:

1. You really don't need the object as an input. It can be a constant on the diagram.
2. You could make this a by-ref system and pass the object which holds the queue reference, similar to the singleton example. This has less chance of braking, IMO.
3. Instead of acquiring the queue in each member VI, create an LV2 manager VI - when it gets a name it looks up its reference in an array. If it doesn't find it, it creates a new ref and returns it. If it does find it, it returns it. That simplifies some of the code you have to replicate for every member VI.
4. The fact that you have to replicate code at all for member VIs is annoying. It would be great if LVOOP had by-ref support built-in or could at least create data access VIs from a template.

[Neil.Pate]

---

tst wrote:

What you've basically built is a SEQ-based, by-ref class (although you pass a name, not a reference), which is certainly a valid construct. dqGOOP has been doing that for years and the singleton example also uses this, as you mentioned.

Some comments:

1. You really don't need the object as an input. It can be a constant on the diagram.
2. You could make this a by-ref system and pass the object which holds the queue reference, similar to the singleton example. This has less chance of braking, IMO.
3. Instead of acquiring the queue in each member VI, create an LV2 manager VI - when it gets a name it looks up its reference in an array. If it doesn't find it, it creates a new ref and returns it. If it does find it, it returns it. That simplifies some of the code you have to replicate for every member VI.
4. The fact that you have to replicate code at all for member VIs is annoying. It would be great if LVOOP had by-ref support built-in or could at least create data access VIs from a template.

---

1. Fixed. I copied this technique from Dr D's Xylophone project. I thought if you drop the class constant on the BD it actually creates a new object each time?

2. Not sure I get you on this one, could you provide some more enlightenment please.

3. Done. Probably not the most efficient implementation though...

4. Agree it sure is annoying!

New version with basic queue manager attached!

[tst]

---

nrp wrote:

1. I thought if you drop the class constant on the BD it actually creates a new object each time?

---

 It does, but so does using an unwired control or splitting a wire. In any case, it doesn't really matter, since you only used it to get the queue type.

---

2. Not sure I get you on this one, could you provide some more enlightenment please.

---

Sorry. I was actually thinking of the reference example, not the singleton one.

---

3. Done. Probably not the most efficient implementation though...

---

It seems reasonable enough, although I would suggest changing the init VI to call the manager instead of what it currently does. Also, I personally prefer not having a default case when you have an enum selector. It allows your code to break if add a value to the enum, forcing you to fix it.

---

4. Agree it sure is annoying!

---

There seems to be some hope, but I haven't looked at this yet.