crelf

That's kinda neat

Yeah, I'd tend to agree.

No, that sounds about right. I might have to get my hands on a copy. I thought the first edition was quite good - am looking forward to seeing what they came up with in the 2nd.

Right, but is encapsulation enough to go that route when the inheritance makes it awesome?

There's a newer version? I'd heard that they were working on it, but didn't know it was published. I'd tlak to your local DSM, or maybe even ping some trainers directly (Nancy Hollenback and David Corney spring to mind) - my understanding is that if you can get a minimum number for a course, NI will teach it (hey, that's how Nancy got a week in sunny Sydney about 8 years ago, when she taught me the Advanced Course).

Hmmmm - in that case, I guess you could start by creating LVOOP drivers that wrap the IVI functions, and if you get a new instrument that isn't IVI compatible, you can clone the driver class to a new instrument specific driver. You might even want to implement this with inheritance: have a parent that has all of the IVI functions in it, and only override a method in a child class if the parent doesn't do what you want. This might actually work... Oh, except that TestStand doesn't support LVOOP dynamic dispatch I guess you'd need to wrap it in another class...

Maybe *you* should start by telling us what you think they are? I'm a big fan of IVI - as abso said, it's there already, which has big advantages in that it's supported across several instruments classes and by a foundation that's thought through the architecture much more deeply that I would. Also, it's off-the-shelf and already tested by many people in many ways. That being said the cons I see of IVI is when your instrument doesn't support the IVI standard(s). For example: some hardware vendors will make instruments that are IVI "compatible", in that you can talk to them using IVI drivers, but their setup might require a custom step to put the device into a mode where it'll respond. Or all of the IVI methods work, except for the one you need. Also, if the instrument isn't supported at all, then IVI doesn't make sense. In summary: I suggest you don't make this a blanket choice between IVI or a custom applied OOP pattern, I'd choose IVI everywhere you can, and backfill with custom code where you can't.

You ever used DAQmx? Ever read keys out of an ini file using the VIs in vi.lib? I'm guessing you do do* OOP, just without knowing about it. * wow - "POOP" and "do do" in the same thread - real mature LAVA!

We're stilling talking about programming, right?

It depends on whether you call what is essentially a reference call to something during execution (the DAQmx reference is, for all intents and purposes, the same, but the data it represents isn't). If you take your definition of hygenic, that would mean any calls by reference to an external data item in any programming language would make it non-hygenic. Anyway, we're getting away from the classic definition of hygenic programming, which refers only to macros, or code portions - I think attempting to apply it to a whole programming language in the context of trying to determine if a programming language is hygenic is misguided and of no value, which is why Daklu said that only a pure dataflow programming language can be considered hygenic. I, for one, am glad LabVIEW isn't hygenic. Wait, that didn't come out right...

Right - unless your method is already child or isn't going to be part of an inheritance scheme, and that's called method cloning (which is not supported in native LVOOP, but is with jgcode's LVOOP Assistant and Endevo's GDS).

It shouldn't - can you post an example?

How? I'm interested in hearing the options...

Yep - that'll work nicely - good job. I don't have the code in front of me, but maybe the conversion to number (to decide which Boolean has transitioned from false to true) is set to only I32?

My pleasure Right - the code I gave you is a place to get started - you need to work out how to put it into your higher-level application. Hint: the event structure acts when the switches array is changed, so you can't use that: try keeping the state of your switches indicator in a shift register, and comparing that with the new value to get your two Boolean arrays. Another option is to use the OpenG "Changed?" VI to select whether to execute my code or not.

Yes, that's why I added the at the end of that sentance.

Unless it's a reference - and even then it's still a *copy* of the reference

C'mon Cat, jump into OOP! The NI OOP course is quite good (based on Endevo's course), and once you "get it", you'll never go back. Otherwise, LabVIEW: Advanced Programming Techniques and LabVIEW for Everyone have some good stuff in them, but you're really limiting yourself by shunning OO.