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]

@tst

That's great! I did not know that.

I just tried it out and although you need to be careful which name is being displayed, it is indeed possible to create menus with varying depths on a class property node.  This essentially covers what I'm looking for.  The distinction between a property node and an actual polymorphic VI is too small to warrant pursuing any further.

Shane

[Intaris]

I just revisited this and found the implementation to be severely lacking for my originally proposed purposes.  The code AQ delivered as an example SEEMED to offer what I was originally looking for but on trying to reproduce my own code, I realised that once any of the classes have a parent-child relationship, the autoupdating will not work.  Not only will it not work, it will break the VIs involved.

I move to have this idea changed back from completed because the current implementation certainly does not fill the role I had originally intended.

Discussion HERE.