Working on someone else's LVOOP

[BrokenArrow]

Hello all!

One late afternoon, not long ago, I was given a very finite time (like two hours max) to help someone with a LabVIEW project left behind by someone else. The new developer was having problems shoe-horning a new piece of hardware into a system. Piece of cake I thought, as long as there were available channels, I'll be home in time for Family Guy.

Funny 3-D vi's.... Objects! I've never used OOP in LV. I found it completely impossible (given the time constraints) to edit the code and add the device into the available DAQ channel. Mission failed. I threw my hands up and agreed with the other developer that you "can't edit it".

Once I wiggled myself out of the fetal position and the uncontrollable crying subsided, I substantiated my indifference to the code with the fact that nothing was documented, Then I ran accords THIS in the help...

Because a LabVIEW class user only has access to the information you provide when you document the LabVIEW class, be sure to document the class and member VIs as completely as possible.

Can someone please explain what that means?

[LAVA 1.0 Content]

QUOTE (BrokenArrow @ Sep 18 2008, 04:02 PM)

Hello all!

One late afternoon, not long ago, I was given a very finite time (like two hours max) to help someone with a LabVIEW project left behind by someone else. The new developer was having problems shoe-horning a new piece of hardware into a system. Piece of cake I thought, as long as there were available channels, I'll be home in time for Family Guy.

Funny 3-D vi's.... Objects! I've never used OOP in LV. I found it completely impossible (given the time constraints) to edit the code and add the device into the available DAQ channel. Mission failed. I threw my hands up and agreed with the other developer that you "can't edit it".

Once I wiggled myself out of the fetal position and the uncontrollable crying subsided, I substantiated my indifference to the code with the fact that nothing was documented, Then I ran accords THIS in the help...

Because a LabVIEW class user only has access to the information you provide when you document the LabVIEW class, be sure to document the class and member VIs as completely as possible.

Can someone please explain what that means?

I have not been out of the "Funny 3-D vi's.... Objects! I've never used OOP in LV. " frame of mind that long, so lets see if I can help.

You can think of LVOOP as a way of managing type-def'd clusters and a set of VI's that go with them all wrapped in a single llb. The "class" is the cluster. The member VIs are the VIs in the llb that are allowed to use Bundle by name and Unbundle by name on that cluster.

So a translation to non-LVOOP speek is "Document the cluster and the VIs that use it."

I will now step back and let the more LVOOPish out there correct me.

Ben

[jdunham]

QUOTE (BrokenArrow @ Sep 18 2008, 01:02 PM)

Because a LabVIEW class user only has access to the information you provide when you document the LabVIEW class, be sure to document the class and member VIs as completely as possible.

Can someone please explain what that means?

Well the idea is that if you have a good reusable object, you don't release the source code. Not always to keep it secret, but also to keep people from changing something that has already been debugged, and to keep them from breaking the encapsulation. So if you have a defined interface and a defined behavior and a hidden implementation, you need to document that better than you might document your 'normal' code, at least if you're anything like me.

If you have the source code, this doesn't really apply to you. And since you failed to be able to reuse the object, you could probably call the design a failure.

[BrokenArrow]

QUOTE (jdunham @ Sep 18 2008, 04:32 PM)

...since you failed to be able to reuse the object, you could probably call the design a failure.

That's what I'm going with, else my seven years of LabVIEW programming has been a waste if I can't add a freakin' analog input to a system!

Thanks jdunham.

QUOTE (neB @ Sep 18 2008, 04:20 PM)

....think of LVOOP as a way of managing type-def'd clusters and a set of VI's that go with them all wrapped in a single llb. The "class" is the cluster. The member VIs are the VIs in the llb that are allowed to use Bundle by name and Unbundle by name on that cluster.

Ben

That sentence helps tremendously, thanks Ben. When I stepped up to the program, I assumed the cluster full of different data types was just being used to carry and drop off data to different states of the state machine, however, it had a funny color!

Thanks Ben!

[LAVA 1.0 Content]

QUOTE (BrokenArrow @ Sep 18 2008, 05:03 PM)

...

Thanks Ben!

You are very welcome.

Just for the record there is a lot more to LVOOP than what more over-simplification covered. Many of them are just plain "Great" (is "plain great" an oxymoron?).

LVOOP has a bunch of functions built in that create the right type of VIs to access the stuff in the cluster (class) where all you have to do is click on what you want to access in a dialog and auto-creating the Icon image and pattern. It even is smart enough to know what folder to save the VI to.

It also enforces a bunch of rules about which VIs can access what data.

One of the "blow-your-mind" aspects featured in LVOOP is Dynamci dispatching. Dynamic Dispatching is a lot like polymorphic VIs but instead of you manually determining the flavor of VI that get run at development time, LVOOP does it automatically at RUN TIME!

OK now I feel better about over-simplifying LVOOP.

Ben

[BrokenArrow]

Sounds simply brilliant. Seems to me, LVOOP would be advantageous for larger programs.

I was reluctant to use a LVPRJ when 8.0 came out, but once I did (upon being forced to by RT) I thought it was sliced bread, especially with the 8.5 improvements. Sometime soon I may feel the same way aboot LVOOP. I don't want this bad experience to taint my opinion of it. Time to check out the OOP Code Repository.

thanks again Ben.

[shoneill]

QUOTE (BrokenArrow @ Sep 19 2008, 03:54 PM)

Sounds simply brilliant. Seems to me, LVOOP would be advantageous for larger programs.

I was reluctant to use a LVPRJ when 8.0 came out, but once I did (upon being forced to by RT) I thought it was sliced bread, especially with the 8.5 improvements. Sometime soon I may feel the same way aboot LVOOP. I don't want this bad experience to taint my opinion of it. Time to check out the OOP Code Repository.

thanks again Ben.

Same here. LVOOP is the KILLER argument for using projects if you haven't up until now.

Shane.

[Neville D]

QUOTE (BrokenArrow @ Sep 19 2008, 06:54 AM)

Sounds simply brilliant. Seems to me, LVOOP would be advantageous for larger programs.

I was reluctant to use a LVPRJ when 8.0 came out, but once I did (upon being forced to by RT) I thought it was sliced bread, especially with the 8.5 improvements.

Keep in mind, LVOOP is NOT yet supported on LV-RT.

N.

[BrokenArrow]

QUOTE (Neville D @ Sep 19 2008, 12:10 PM)

Keep in mind, LVOOP is NOT yet supported on LV-RT.

That's cool, I didn't mean to intermingle the two subjects when referencing why I was finally coerced into using a lvprj. I don't expect to use much RT now that I'm done with the deliverable I did for the last company I worked for. Sadly, my current assignment isn't LabVIEW-centric. but I've ordered up some hardware to start a side project on my own where I'll be vooping it up new school!

[BrokenArrow]

QUOTE (Neville D @ Sep 19 2008, 12:10 PM)

Keep in mind, LVOOP is NOT yet supported on LV-RT.

That's cool, I didn't mean to intermingle the two subjects when referencing why I was finally coerced into using a lvprj. I don't expect to use much RT now that I'm done with the deliverable I did for the last company I worked for. Sadly, my current assignment isn't LabVIEW-centric. but I've ordered up some hardware to start a side project on my own where I'll be vooping it up new school!