Display different measurement data types with dynamic dispatched VIs ?

[zigbee1]

I came across an OOP introduction which seemed to solve an issue with displaying multiple data types by using dynamic dispatched VIs:

The solution seemed to be creating a new "Measurement Result" parent class and have "Strain result", "Temp result" etc... inherited from "Measurement result". I see after Acquire, then Measure, the VI should return a "Measurement Result" object instead, so does each of its own child classes VIs.

However I still can't visualize how this helped solved the original problem of being able to display multiple data types ?

[tyk007 · Accepted solution]

Over-riding virtual methods changes behavior but not the interface. I agree that the slides make it out to be a little confusing; it doesn't mean that somehow we can return a different data type (strictly typed, not string or variant) to the caller by using a class hierarchy. What it could mean though is that the logic that would then use the measurement result could be encapsulated in a hierarchy:

• If you needed logic to append a measurement result to a log file (aka "Save") then this is handled by the dynamic dispatch methods, perhaps taking in a TDMS reference as input and then performing the custom data conversion behaviour etc. to the file inside the method.
• If you needed logic to display the test result on a user interface (aka "Display") then this is handled by the dynamic dispatch methods, perhaps each opens it';s Front Panel pro grammatically and presents a UI to the user with the data shown on indicators (numeric, boolean etc.).

Note that in all of these cases the VI interface is the same for all dynamic dispatch methods but the polymorphism is capturing the different actions inside the VI.

[zigbee1]

That was exactly what I thought. Thanks for the expert opinion !

[PaulOfElora]

OK, I'm halfway there, I think, but brand new to OOP.  I made a "Measurement" class, with 3 child classes - Analog (DBL), Digital (Boolean), and Motion (cluster of motion parameters).  I have a generic, empty "Measure.vi" as a member of the parent class.  So I thought I'd create member VI's for each of these child classes, all with dynamic dispatch ins & outs.  But I'm not understanding how one generates differing data types on the connector pane.  "Analog" would have a channel # as input and DBL as output.  "Digital" would have a bit position as input and Boolean as output.  "Motion" might have a string as input and motion parameters cluster as output.  Am I forced to write polymorphic VI's?  I thought that's what inheritance and dynamic dispatch were supposed to do for me somehow (and I'm hung up on the Somehow!) Thanks for any light y'all can shed - paul

[Kevin_Price]

So I *think* what you're missing is a different way of thinking about things.   Once you get into OOP, you have to let the classes own their data and not give it up.  Instead of making class functions that return class data via output terminals, you make functions which operate on the data in the ways you need without actually giving the data back to you as an output.

As I've mentioned in other threads with you, I'm not a LVOOP expert.  I find it kinda unnatural to think this way.  But it seems to be the necessary path forward.  Your Measurement class probably needs some kind of "Plot" function and maybe some kind of "Log to File" function.  Don't develop apps that depend on asking classes to give you their data.  Instead, develop the needed functions that act on that data in the ways you want, and make them class member functions that have internal access to class data.

-Kevin P

[PaulOfElora]

Thanks Kevin, I do appreciate your help.  Darn that Elijah Kerry for planting this in my head!  I'll digest this some more... the idea of differing types on the same wire still addles me - paul

[PaulOfElora]

Come to think of it, I haven't seen that either in the 1,001 examples I've seen - "Don't develop apps that depend on asking classes to give you their data"

[PaulOfElora]

Holy Cow! I don't usually ignore the shipping examples, but I ignored "Dynamic Terminals.vi" until just now.  I spent days - DAYS! eating bark and grass in the wilderness thinking that all descendant VI's had to have exactly the same data as their ancestor.  Why did I think that? WHY?  This old slow squirrel just found a nut.  Thank you Kevin, Yamaeda and everybody who  helped me - you guys are a huge help for us rank amateurs! paul