OOP architecture

[tysonl]

I have a sizeable application that I am trying to re-write into LVOOP and I am struggling with a architecture/design issue.  My current application uses a QMH design pattern and contains controls that simply start and stop various parts of the HW it interfaces too.  It contains a UI event handling loop, a UI event processing loop, various worker loops (acquire, process, and save data), and a few display loops.  I currently have coded up some of the UI event handling and processing using the command pattern in LVOOP.  What I am now struggling with is how to design and implement the worker loops/routines.  Basically, how do I design and launch my worker processes/objects using LVOOP?

I am envisioning creating classes for my HW (data acquirers), data processors, loggers, and displayers and have them work together.  I think I know how to create the classes, but I don't know how to launch them. 

As a simple example, consider a counter class.  How do I, from my main, top level UI, launch a counter object that counts in the background and report or makes available it's count back to the top level UI?

I apologize if the above is confusing.  I have done OOP before in other languages (Python, C++, Java), but I am completely new to LVOOP. 

[dkfire]

One question: How would you do it in non-OOP?

How do we normally launch a process/vi to run in the background?

And how do we normally transfer data between two loops?

OOP is not that different from non-OOP, you need to do a lot of the same things. It is just a matter of encapsulation.

Once you have answered these questions, take a look at the Actor Framework.

Also do a search on the other side for Self-addressed stamed envelops, LapDog, or just OOP framework/messaging.

There are a ton of information on the Lavag.org site around OOP in LabVIEW on a little higher level.

[dems]

Yeah, the obvious answer is actor framework, which is built into the product. Worth clarifying is what actor framework gives you (also, this is my opinion not fact, feel free to challenge this): 

-Async launch

-Guaranteed shutdown

-Simple (if extremely tedious) QMH scheme (that is, the IDE makes this tedious but is otherwise essentially the command pattern).

These are the key parts of a QMH to my mind, so if you have a bunch of QMH functions you should be able to make them into actors with 0 trouble (and a bit of tedium).

So thats part of it. The other half is that you think there is actually a difference between lvoop and other-oop. There are probably differences, but the basics are usualy the same. 

LabVIEW is notably missing: mixins, interfaces, etc. Basically, you get the CORE lvoop concepts but not the nice fancy stuff which other languages have right now. In theory, this sucks. In practice, this only sucks a little bit. Theres usually one thing you can kinda work around which would usually be better if you had interfaces or mixins. Pssst, that thing is always

The other tough bit is by val vs by ref. This is actually a combo of two problems. 1 is that the labview compiler is not, in fact, magic. This means that there sometimes need to be references. But because NI pretends the compiler is magic, we only have DVRs. DVRs have absolutely godawful syntax whether the DVR is a dbl or an object. 2 is that people don't know how to handle byval. Please please please note that these are two issues. If you think there is only one issue, you mayneed to relearn dataflow.

Dataflow provides some absolutely aweome benefits in some cases. For example, lets say blah blah blah blah blah blah blah happened to object X. One option would be to perform operations blah, blah, blah, blah, and blah. But then you have to be ready to revert those changes. A much better option is to say "heres a copy of X, do what you want with it". At the end of the day, you know what happened to it (customer modified X to do Y) or you can check the final state (user added item A, deleted B).  In both cases your user had the ability to do as they please, while you could still restrict access (becase the user only ever had a copy). That is extreeeeemely powerful.

[dems]

Hrm, sorry....looks like my link got removed?

I was linking to https://decibel.ni.com/content/docs/DOC-24015 as the main feature interface people usually want for lvclasses.

also its worth noting that I was obviously grumpy about objects earlier. The compiler is, of course, magic. However making a billion in-place structures to handle anything you need to do by reference is really painful, and some times that is necessary.

[dkfire]

---

@dems wrote:

Yeah, the obvious answer is actor framework, which is built into the product. Worth clarifying is what actor framework gives you (also, this is my opinion not fact, feel free to challenge this): 

-Async launch

-Guaranteed shutdown

-Simple (if extremely tedious) QMH scheme (that is, the IDE makes this tedious but is otherwise essentially the command pattern).

These are the key parts of a QMH to my mind, so if you have a bunch of QMH functions you should be able to make them into actors with 0 trouble (and a bit of tedium).

...

The other tough bit is by val vs by ref. This is actually a combo of two problems. 1 is that the labview compiler is not, in fact, magic. This means that there sometimes need to be references. But because NI pretends the compiler is magic, we only have DVRs. DVRs have absolutely godawful syntax whether the DVR is a dbl or an object. 2 is that people don't know how to handle byval. Please please please note that these are two issues. If you think there is only one issue, you mayneed to relearn dataflow.

---

There are two statements that I don't like in your reply.

First the Actor Framework is not something that is obvious, there are so many other options. 

Take the time to read some of the post on Lavag about OOP, framework and messaging.

There you will see that there is other ways to do things.

Second, the statement that people don't know how to handle "by value" is simply not correct.
LabVIEW by language is "by value", so if you can code LabVIEW you should know how to handle "by value". 

And OOP can be done without references.

It is a matter of knowing your programming language, then you will be able to do everything and select the right tools to for the job. 

But this is just my opinion.

And DVR is not the only reference method to use. You can use SEQ ( Single Element Queue) or Notifier.