Allow special "polymorphic" class functions

[Intaris]

With the advent of LVOOP, some things have changed about the way we work with LV.

I currently have an example of an instrument driver (USB) which I'm implementing using LVOOP.  I have many different individual commands, each with their own input and output values.  I have one nice "polymorphic" VI with all of the creator VIs for every command organised nicely in a menu with several levels.  I say "polymorphic" because I don't set the VI to adapt to the data type.

After processing the instrument command, I again use a "Polymorphic" VI (See above regarding the "") for reading the various values from the processed command.  Both of these "polymorphic" VIs use menus and do NOT adapt to data type.

I have basically two VIs for every class, one to create the query / command and others to process the data contained within the created object.  I have two VIs for EVERY instrument command.

What would be cool:

Having a special VI for a class which is presents the user with a menu for the individual functions (no adaptation to data type) which itself can be included in a regular polymorphic VI (adapting to the object type).

 

This would allow the user to select a different instrument command and have the corresponsing process VI on the right automagically update to present the user with the commands available for that particular object. 

That way we could create an entire instrument API with only TWO VIs ("polymorphic" creator and polymorphic-"polymorphic" function VI).

Shane.

Message Edited by Intaris on 01-29-2010 02:42 AM

[Intaris]

We could I suppose but I simply don't have time to install the beta ATM.... 😞

[G-Money]

Available in NI LabVIEW 2010

[G-Money]

Already implemented in LabVIEW. Available in LabVIEW 2010.

[Intaris]

Completed and then Declined????

Completed i understand since it was released AFTER I had asked for it, but "Declined" seems a bit late don't you think?

[G-Money]

This was an accident. I was moving a lot of ideas out of the Completed category that weren't actually implemented because of the idea itself. This one clearly was with Aristos working on it, should have been moved to In Work, and then Completed. I apologize for the inconvenience.

[G-Money]

Available in LabVIEW 2010.

[Intaris]

Hey No problem.  It was more amusing than annoying. 

[Intaris]

AQ, the code you posted does not encopmass what I was looking for.  I see no way of doing what I was looking for in LV 2011. The code supplied covers the polymorphic VI on the left, but does not deal with the issue of auto-updating the VI on the right of my graphic.  In my example the polymorphic VI on the left outputs one of a long list of individual classes.  Each of these classes has a polymorphic VI defined which encompasses essentially the API on this class.  This API polymorphic VI cannot be automatically updated based on the class wired to it.  This is, however, what I'm looking for.  The Polymorphic VO on the right needs to be a class member of the onject output from the polymorphic VI on the left.

I want, essentially, to be able to have a DYNAMIC DISPATCH POLYMORPHIC VI.

At the moment I can create a polymorphic VI as a class member (and can have multiple different VIs in inheriting classes without a namespace conflict or an override conflict).  Unfortunately, we cannot actually make the wire connected to the polymorphic VI actually determine WHICH class Polymorphic VI should be used.

Example:

Class A and Class B both inherit from Class X which has a dynamic dispatch "API.vi" defined within it with elements "Write Value" and "Read Value".

Class A defines its own Polymorphic VI called "API.vi" with elements "Set Value", "Read Value" and "Exit".  Blass B does the same with the elements "Set Value", "Read Value", "Update Value" and "Exit".

If I drop an instance of the polymorphic VI from the parent class to the BLock diagram, it will show the selector for the parent class.  If I now wire up Class A to the Polymorphic VI, it should show the menu for Class A (Set, Read anf Exit).  If I wire up Class B to the Polymorphic VI it should show the menu with "Set", WRead", Update" and "Exit".

Another way of looking at it since the introduction of property nodes for classes would be ato allow a menu structure for property nodes and method nodes for a class so that the available API can be accessed in a more structured way.  Property node folders within property node folders within the class definition so to speak.

[tst]

>...allow a menu structure for property nodes and method nodes for a class...

I can't say I understood everything, but I believe that this does at least exist for property nodes. It seems it can be done by using a colon in the folder name - http://lavag.org/topic/13581-property-node-names/?p=81733

This doesn't cover standard class VIs and doesn't seem as convenient as simply nesting the folders in the tree, but it seems like it should work.