Getting VI 'protoype' Information for Call by Reference VIs

[LeeH]

Hello all,

I'm currently attempting to implement a Labview GUI plug-in type architecture whereby I want to call external GUI Setup pages in an LLB from an executable. Before calling the external VIs from the LLB however, I'd like to check that the connector pane of the VI in the LLB matches that used to provide a strictly typed reference for the call by reference node in the executable.

I've found that I can get all the controls/indicators from the VI in the LLB but this doesn't give the full information I need (the method returns all controls and indicators in the VI not those necessarily connected to the VI connector pane and the order they are returned in seems arbitrary?).

Does anyone know if I can obtain the controls/indicator names and types connected to the connector pane of a VI programmatically? or at least compare the connector panes of two VIs to check if they are the same?

thanks

Lee

[djolivet]

You could try opening a strictly typed reference (not sure if this is the right terminology) to the VI and checking the error:

[Mark Yedinak]

If you are designing this from the ground up why not spend some time implementing a standard API for your plugins? This way you wouldn't need to worry about mismatched connector panes. Design you modules to handle the implementation specific tasks but call them using the same API. Generalize the API using type indentpent items such as variants. This way you can use the same method for calling your plugins and not worry about the connector pane. Or am I missing what you are trying to accomplish.

Another possibility would be to use LVOOP with inheritance. You could then overload your general class with type specific classes to handle the variations.

[jdunham]

QUOTE (LeeH @ Mar 24 2009, 09:16 AM)

Does anyone know if I can obtain the controls/indicator names and types connected to the connector pane of a VI programmatically? or at least compare the connector panes of two VIs to check if they are the same?

If you turn on http://wiki.lavag.org/Category%3a%50rivate_method' rel='nofollow' target="_blank">private methods, there is a method "VI.Export Interface" which dumps out the goodies you want.

[LeeH]

First of all, thanks for your replies! This is the first time I've used LAVA and I wasn't expecting such a quick response.

djolivet - that's a simple way of checking if they match before running a VI and that's great thanks. I think I need to clarify a few things though about what I'm trying to do.

1) It is expected that the interface between the external GUI setup page LLBs and the executable will be updated with new data types etc. passed between the two. At the time of writing my original post I thought I was going to implement a mechanism whereby I could 'get' the prototype information from the external VI which would essentially provide a 'version' of the external VI being used so it could be called with the appropriate interface from the executable. The executable would be able to maintain backwards compatibility with previous versions of the interface by maintaining a library of type references for previous versions.

Having read Mark's reply however I think this is a bit dodgy and it would be better to create a standard API as he suggests with the external LLB VI reconstituting variant data and throwing away the stuff it doesn't need if it's an earlier version (I think this is what you were implying?). The LVOOP stuff would be good as well as it would essentially do the same job but in a more elegant way!

2)The GUI setup pages in the external LLB are expected to be supplied to users with the ability provided for them to modify the pages if they want to. I was originally hoping that checking the VI prototype info would provide a means of sanity checking the VI that has potentially been modified, but having thought about it a bit more, if the user wants to swap inputs/outputs etc. there's nothing I can do about it to check if it's ok. The connector panes might match but that doesn't mean it will actually function in the same way.

jdunham - that's very clever but I'm not sure my boss would go for it!

Thanks everyone

[Grampa_of_Oliva_n_Eden]

QUOTE (LeeH @ Mar 25 2009, 05:01 AM)

... The LVOOP stuff would be good as well as it would essentially do the same job but in a more elegant way!

...

Thanks everyone

Look seriously at LVOOP before putting any effort into writing anything that does not use LVOOP. It worked well in my plug-in app and since all of the low-level stuff was handled by LVOOP I could just concentrate on making the app meet specs rather than coding up a mechanism to do what LVOOP offers.

Ben