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]

In a nutshell, the behaviour I am looking for is similar to using references and property nodes.  Changing the Reference type automagically updates the available functions for that object on a node connected to it.

I want to implement something similar to the property node where it auto-adapts to the type, but then lets manual choice of the actual routine to be executed for that type. 

Wrongly connected wires are broken, but us programmers still need to have SOME work to do... 🙂 

[tst]

So, if I understand correctly, you want a simple way to select a VI from the current class and your suggested implementation is adding an optional selector which will show a list of all the VIs in the class?

[Intaris]

Yes and no.  Not all the VIs, but user-selected ones (public or public/protected depending on where it's being used).

The idea would be that these "selector" VIs could be further packaged as polymorphic VIs.

[tst]

I still can't understand the connection you're making to polymorphic VIs. Let's see if we can rephrase it - you want an option where we drop a VI from a class and we then have a selector (like the polyVI selector) which will allow us to replace it with any other valid VI from the class?

[Intaris]

The reason why the word polymorphic makes its way in is that it's the only thing in LV at the moment which we can implement in that way.

You've correctly understood what I'm getting at.  Seemingly the word polymorphic is more confusing than helpful.

The point is, though, that these selector VIs can then themselves be incorporated into standard polymorphic VIs.

Shane.

[AristosQueue (NI)]

You will have the ability to write this API using LV 2010, though it might not be immediately obvious that it is possible and the syntax may not be exactly what you expected. I've asked that this idea be marked as "In Work" and will eventually become "Complete" when LV 2010 ships. I have posted example VIs here, but since those VIs are saved in LV 2010, you'll have to wait until the release to view them. If at that point there's further requests, file them as new ideas.

[tst]

Stephen, I'm pretty sure your suggested implementation only answers a subset of the cases where this behavior is desired.

As I said in earlier comment - if I understand Shane's request correctly, he wants an easy way to select any VI in the class. This doesn't fulfill that requirement. It might work for his specific use case, but I'm sure there are many cases where it won't. Perhaps an RCF or QD plugin is in order.

[Intaris]

I'm actually glad that someone from NI has mentioned the addition to LV 2010.  I didn't want to break the rules regarding mentioning Beta thingies in this forum.

I do personally see this as a sub-set of what I wanted, but the ability to define which functions are displayed is also a nice effect of this implementation.  I need to wait until 2010 is released before I can give my final 2c on it, but I think it comes kind of close to what I wanted.

@AQ, will this function allow auto-uptading of the VIs which can be chosen when I replace the defining class upstream as shown in the original picture?  If so I'm happy for the time being.  If not, I don't think it successfully relfects what I was looking for.

[tst]

> ...will this function allow auto-uptading of the VIs which can be chosen when I replace the defining class upstream...?

Yes.

P.S. We can also have the discussion in the beta board.