double dynamic dispatch

[shoneill]

I'm just throwing an idea out here for a moment.....

I'm fiddling about a bit with OOP at the moment (LVOOP to be precise) and I'm wondering if I can use it in a semi-nice way to do a certain task.

I was wondering if it's possible to have a VI which takes an instrument class as an input (with Dynamic dispatching) and accepts a second class as secondary input (also Dynamic dispatching).  This would most likely mean I need a lot of VIs to cover all Class 1 & Class 2 options, but that's do-able.

I'm toying with ideas still stemming from my nugget a while back.  I basically have a family of instruments (spectrometers) which have different parameter sets which I would like to have settable independently of each other.  It would be quite nice to have a single "set" function accepting two classes (one for the instrument, one for the data to be set), then causing the correct routine for this data set to be called without me having to parse strings, variants or anything like that.

The LV help says "Note  Although a dynamic dispatch member VI can have no more than one dynamic input, the VI can include multiple dynamic outputs" but I was wondering if there's a workaround to allow something of this kind.

Of course I could just try things out, but that'd take me quite a while as I'm not yet very proficient with LVOOP.

Shane.

[shoneill]

Never  mind, I think in my trouble getting to grips with LVOOP, I'm over-complicating things.....

Shane.

[tst]

Shane, you might wish to check out the LAVA GOOP forum. There were quite a few discussions there about LVOOP and its implementation which would probably be invaluable when trying to learn it.

[shoneill]

Thanks Tst,

I find the lack of overview as to what's going on rather confusing.  I never know exactly which VI is currently executing......

Shane.

[tst]

That was my biggest issue with LVOOP - you get a million VIs, none of them has any code in it and it's very hard understand what's happening and where the execution is. I was told though (and I'm willing to believe it) that once you find a use case for LVOOP (which could be different from the use cases for GOOP) and actually do some coding of your own, it should grow on you and you will find it more natural. Then again, I only had 8.x at home, so I didn't really get a chance to play with LVOOP.

I think the workaround for the issue you mentioned is placing conditional brakepoints if you need to debug. Another option I can think of is logging debug data to a central location.

[shoneill]

Thanks for the help,

I have already implemented a small LVOOP routine, and it sure made sense when I was writing it myself.  But I downloaded some examples (LV2OOP) and I found it downright confusing.  I feed like a real n00b!

I'm convinced there are some really powerful uses for it, but I just don't have the same feeling of "I know this" as with other areas of LV.  I've been working with 6.1 until recently.  I think I need some courses.  Learning from zero is easier than re-learning stuff you thought you'd already learned.....

I can only imagine others feel the same way.  Some way to highlight what's going on behind the scenes with a LVOOP project would probably go a LONG way to converting people.

Again, thanks

Shane.