LabVIEW
Community Nugget 4/08/2007 Action Engines
Solved!
Well for (1) he was a new developer doing his first project in the LabVIEW team as far as I heard, and for (2) I run into this when trying out the Feedback nodes and at one of the next NI weeks this story was told by people who should know.
Creating by Reference OOP in LabVIEW is pretty trivial. Just place a DVR in the private data of the object and put the actual data into the DVR. et voilá!
@ConnerP wrote:
However, AEs are conceptually easier than passing around an object in a DVR or copies of an object containing a bunch of DVRs.
Until you need to find all AE that use a certain function. ("Where's the init?").
That's just one of the reasons I don't use AE anymore. Of course, an AE can (and should, AFAIC) be wrapped in a library, made private, and only the function wrapper should be used to prevent this. At least then I can easily find all init instances.
Still, the AE is a global. And a singleton. That's my next problem. An AE that suits my needs, cannot be reused in the same project. Unless a copy is made, or the AE needs to be redesigned to use some sort of indexing. Both are no good for me... And to anticipate the expected response: yes, this happens to me a lot.
By reference is not the same as being global. By reference you can still follow the wire to see where it's used. And the needed wire prevents random lazy usage of the AE. I've seen that a lot. There is an AE, so it's used everywhere, from the top level to the deepest catacombs of the application. When a wire is required, people are less inclined to do this, and when they do, at least you can follow the wire. Using AE's like this prevents reuse of modules, as there is such a strong coupling between the module and the AE. Obviously, this can be prevented by actually thinking about how the AE should be used, but it's not enforced. And any code that uses by reference objects can still be called twice without problems.
Another side effect of the AE being used throughout the entire code, is that it prevents copying. As the AE are global, cloning\copying anything that contains an AE will make the two processes communicate. Often that's not desired.
@ConnerP wrote:
However, AEs are conceptually easier than passing around an object in a DVR or copies of an object containing a bunch of DVRs.
That might be true (arguably), but normal by wire objects are even easier.
By reference objects are not the substitute of AEs. By wire objects are.
I never use DVR objects, because they are so terrible to debug. I want to stop my main, and then run a sub VI with the data that it used the last time it run. There's hardly any use for them. I did use them because I though it would prevent memory copies. But then the by wire child performed almost the same without all the disadvantages (memory leaks, debugging). Sometimes there's still need for them, but I manage avoid them most of the times.
To me AEs lean more towards the quick and dirty side of the spectrum. That doesn't invalidate them. They're just not suited for my needs. I can imagine projects where they fit perfectly. I used to make them myself. If you only get those kinds of projects (, and when you don't mind rewriting code when you need an up scale), AEs work wonders. For me, it's the other way around. I work on large projects, where everything is dynamic. So my entire codebase has no AE. So even for smaller projects, I reuse my codebase and experience based on larger projects. So no AE for me...
Search LabVIEW like a graph! 
This is a great discussion and I'm glad I resurrected this thread!
However, I'm still wondering what the best strategy is for a dynamically updating GUI. I have been working on an AE based on Ben's GUI Control, but I'm not sure that's the best option.
My preference would be to go AF and make a GUI actor but I don't have time for that on this project.
@jfalesi wrote:
dynamically updating GUI.
You mean the values? Or the layout?
I usually initialize a class (set values) with control references. Then use methods to update the values (and other stuff, like enabling\disabling).
Haven't worked with those QControls jet, but they might make life easier...
@rolfk wrote:
Creating by Reference OOP in LabVIEW is pretty trivial. Just place a DVR in the private data of the object and put the actual data into the DVR. et voilá!
Yeah, that's basically what G# does for you, plus you'll get garbage collection, automatic icons and a debugger that'll look at live objects. 🙂
/Y
@jfalesi wrote:
However, I'm still wondering what the best strategy is for a dynamically updating GUI.
You really need to elaborate more on what you mean by this. If you are just talking about a single VI's GUI, then I prefer using User Events to send that data/messages to the GUI loop (which should just be a While Loop with an Event Structure anyways).
