Whether I Can build my own control like LabVIEW IO control

[Jun_Liu]

Dear,

In my LabVIEW application, I want to create a control that had similar behavior as LabVIEW IO control, such as VISA resource name control, and Shared Variable Control.

• With VISA resource name control in edit-mode, when I click the down arrow, all local VISA resources will show in the drop-down list.
• With Shared Variable Control in edit-mode, when I click the down arrow, there is a Browse button. After click Browse, a new LabVIEW Window will appear to show possible shared variables.

My question is whether I can build my own control like these two IO controls, especially have the similar edit-time behavior?  （Dynamically include local resources）

Maybe Xcontrol can be an option? But it sounds like Xcontrol cannot be mapped to connector pane in subVI? And obviously, Xcontrol was not as easy as IO control for my customer to use😂

Or .NET control / ActiveX control? Have no experience on configuring its edit-time behaviors, except property node and invoke node in run-time.

Can someone give suggestions about this? Thanks very much in advance.

[JÞB]

Just posting to track ideas from others.

The tongue in cheek answer is "Yes, of course you can create such an Object!"  I simply have no clue how to add a new datatype with custom edit time behavior.  This would likely mean extending LabVIEW with a Framework.

Caution Framework extending means crawling around the LabVIEW Attic blind.  Most of the rusty nails have been bent over but you never know where every other Framework Provider has been.  If you screw with the same thing others have screwed with...  well, just say a tetanus shot doesn't prevent one of those diseases.

[rolfk]

Those IO Controls are for the most part either internal LabVIEW object manager classes (so fully in LabVIEW C++ code) or so called User Refnum object manager classes. The first is beyond anyones reach who doesn't work as NI LabVIEW developer. The second is theoretically possible but completely undocumented.

The principle is mostly as follows: The methods and properties of such a class are defined in a *.rc file like what you can find in  <LabVIEW>\resource\objmgr. Here you can also define a VI that can let you select specific things for the actual resource but how it gets that information requires undocumented LabVIEW manager calls. And all the methods and properties are matched through this file to exported functions in a shared library. This means you need to create a DLL in C(++) with exported functions with specific parameters. The entire interface is as already mentioned completely undocumented. The same applies to the actual keywords and such to use in the according *.rc/*.rch object interface description files. And creating a generic user control of the right type that you still can assign to such a object class is an exercise in undocumented scripting in itself. And to write DLL functions that can actually deal with this is again requiring to call undocumented LabVIEW manager C functions.

Dabbling with this is a painful process. If you have errors in your *.rc file, the class simply is dropped at launch time of LabVIEW. There is no indication what is wrong and why LabVIEW didn't like it, the class simply doesn't exist. Every time you edit anything in this file you need to restart LabVIEW to have it "hopefully" pick your changes up, and you can keep your finger crossed and prey to all the Gods you know, that you didn't accidentally add a syntax error in your change.

So basically, how many man months do you have available for this? 😁

[Jun_Liu]

aha, interesting and helpful to know that. 

Actually, what we need to do is making our APIs easy to call. It is completely unnecessary to take such efforts, even it can be unstable in future use.

Thank you very much, and have a nice day.

[DerrickB]

Another option is writing a library of VIs that provides an API for working with something like a ComboBox by reference. The combobox can be wired to the connector pane and then a reference to it passed into a VI that runs some event handling and other stuff for the combobox to provide the additional functionality for configuration and specific selections.

Is the value just a string? I could whip up a small example.

[Jun_Liu]

Thanks for your reply. I do believe this option can help me to make it.

Yes, that value can be just string. Actually, I wrote a simple code before with VI server to operate ComboBox control in subVI front panel. Every time I run this VI, the ComboBox control in subVI front panel changed as expected. But the combobox control in top-level VI did not changed, except I delete the old one and right-click to create an new combobox control.

I even make the ComboBox control as type-def control, but did not have any help.  

[DerrickB]

Typedef means maintain the type, which for combobox is just string; the list of string values isn't part of the type. You also wouldn't want to try to update and set defaults and save VIs as those capabilities wouldn't be available in any code built into an application.

So I may have gone a bit overboard and written a relatively small and extensible API:

I want to finish up two more example values implementations and then I'll post a link to the code, or maybe I'll just throw it right up to VIPM.

[DerrickB]

Alright it can be grabbed from github at https://github.com/illuminated-g/lv-dynamic-combobox

I didn't get to finish the NOAA NCDC demo (weather info) as the server went down when I was finishing it up but it should give a pretty good idea of what I mean by "creating an API" to drive the combobox behavior.

If you run into any issues with it or have other questions about it feel free to create issues on the repository. Definitely feel free to take the idea and make your own for extra learning 😉