goop and flow

[blunderer]

I'm starting to work with GOOP from endevo in labview.
As I'm a beginner in both labview and GOOP (but I now OOP concept from C++) I'm wondering if it's better to use objects in the traditional flow program or if I have to try to use only objects and have just a "main" vi which create the first object that will manage all the application and then be destroyed by this "main" vi.

I think that the second case is a bit radical, and I'd rather choose the first one but I would be pleased if someone can give me some pieces of advice.

Thanks in advance...

[Underflow]

blunderer,

I'm struggling with the same question, so I can't give a really definitive answer, just my experience. Perhaps others can give more definitive responses.

I've had the best luck sticking with the flow model (using OpenGOOP at the moment). The simplicity of the flow model makes managing all that complexity so much more possible. I've built one "object manager", and it turned out to not really be worth the effort. Now, the problem I was solving with my program wasn't all that hard, and given a more complex problem, a manager might be better.

Some resources, if you haven't run across them:

The LAVA forums Large Application & Design section:
http://forums.lavausergroup.org/index.php?showforum=12

OpenG:
http://www.openg.org/
If you get the OpenG Commander package, you can stop it and open it up to see how it's put together. I particularly liked the Queue Manager to handle communication, but you can see how it could introduce a fair amount of complexity.

I'd be very interested in other responses on this thread as well!

Joe Z.

[blunderer]

Thanks for your answer

Actually, my application is not that complicated too, but I'm working on finding a kind of way to explain GOOP to non OOP programers. In order to do this, I need to be clear on my methodology and be abble to explain why I'm using one solution instead of another. Now I'm just wondering about this "object manager", does it require to be an object and why, the pros and cons.

[becktho]

Hi

I'm working on a project where I use OOP in LV. Up to now I did not use it but here it makes sense, because I have to handle several objects.
The SW controls a test stand where the units are placed on a rotary plate. This plate is divided into 8 sections. One section is to put/remove an item, 6 sections do the same kind of test but with different parameters and the 7 section is another kind of test. All tests run in parallel and I saw no other way than placing unit-objects in these sections. It is not working in a productive environment yet, but the first tests were good.
The rest of the program still is "simple" LV, using the dataflow.

The main advantage in this application is that I am able to have these objects with its methods and properties, which are buffered in an array and I just can move these elements (references) in the array if the plate is moved on a section.

I always wanted LV to have more possibilities in OOP (I also use JAVA), but I found it is better to use the dataflow-paradigm, because LV is made for this. If there is really need for OOP functionality I use it - but just then.

Thomas

Message Edited by becktho on 06-24-2005 09:09 AM

[blunderer]

I think that it is the best for me to hear about the experience of several labview programers to see what is the most used way and their reason...
Thank you, that's very helpful.