LabView OOP - nest independent running VI in Object - bind vi execution to object

[wiebe@CARYA]

---

@szewczak wrote:

Is this similar to what you are trying to do?

---

No really. But all in all not bad.

The naming is a bit alien to me. Not sure if that G# or something, but I avoid class names in methods (like the plague). Same for the project organization. But that is probably just taste and customs.

I'd probably avoid getting the main.vi references by there name. Give each child an override method that contains a (static) VI reference. Use that instead of a reference opened by name. That way, each object is responsible for it's own reference. This opens doors... E.g. to cloning the objects, allowing multiple instances of the same window. Or you can let the object decide which front panel to use based on it's own logic, they don't need to be called main.vi anymore (although that would help keeping thinks clear).

[szewczak]

I may have gone down the rabbit hole trying to play with this problem and I am calling it quits due to a specific limitation with LabVIEW Classes and Dynamic dispatching. Specifically:

Which yields the error:

The connector pane of the strictly typed VI reference input includes a dynamically dispatched terminal,
which means it is part of a method of a LabVIEW class.
Dynamic member VIs are not supported by the Call by Reference node in this version of LabVIEW.

I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.

Thank you for your comments on file organizing in LVOOP. I looked up a style-sheet and now I am ashamed. 

[drjdpowell]

---

@szewczak I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.

---

No, you just need a static VI that does nothing but call your dynamic-dispatch VI.

[szewczak]

Drdjpowell, correct that snippet only does what you described. But I included it to discuss the part I found frustrating about LVOOP, that objects with hiearchy cannot be used by call asynchronous tools like the one I. The snippet. I get why from a system management perspective this is so, but it means that organizing vis into a class hierarchy is not compatable with calling child object vis asynchronously.

[wiebe@CARYA]

---

@drjdpowell wrote:

---

@szewczak I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.

---

No, you just need a static VI that does nothing but call your dynamic-dispatch VI.

---

And that DD VI reference (called by the static parent VI) is returned by a DD VI in each child. Think we're on the same page.

[wiebe@CARYA]

---

@szewczak wrote:

I think this is nail-in-coffin for using classes to organize your dynamic called processes in LabVIEW.

---

I would like it a lot if call by reference would accept DD VIs. But usually, the call by reference call would be the exact same as a DD call.

In fact, it would be possible to refactor the dynamic call out. Simply start all objects in a parallel for loop. That loop won't quit until everything is done. Then use the VI reference to put the FP in a sub panel. Or better: send an event and let the object put itself in a sub panel. It's often overlooked that normal VI's (not dynamically started) can be put in a sub panel...

[drjdpowell]

---

@szewczak wrote:

Drdjpowell, correct that snippet only does what you described. 

---

I wasn't describing your snippet so I think you've misunderstood me.  You need to call-by-reference a static-dispatch VI with a child object passed in, then make a (not-by-reference) call to a dynamic-dispatch VI inside the static VI.  Multiple frameworks ("Actor Framework", "Messenger Library") do this.

[wiebe@CARYA]

---

@drjdpowell wrote:

---

@szewczak wrote:

Drdjpowell, correct that snippet only does what you described. 

---

I wasn't describing your snippet so I think you've misunderstood me.  You need to call-by-reference a static-dispatch VI with a child object passed in, then make a (not-by-reference) call to a dynamic-dispatch VI inside the static VI.  Multiple frameworks ("Actor Framework", "Messenger Library") do this.

---

Good one.

[szewczak]

Finally went and read the intro to actor framework, realized how much better that is for this kind of problem. Sorry for adding confusion to this thread!