How do I find the typedef for a control?

[Sweet William]

I have several VI's (350+) which make use of a number of typedef and strict typedef controls. I want to automatically generate some documentation but I would like to insert the name of the typedef as the data type but I cannot see how to make the link between a control from Controls[] to the control VI's listed in Callees[]. I suspect that there may be something in the Type Descriptor of the control but I cannot find anything that explains how I can map this to one of the Callees[].

Thanks
Bill

[CoastalMaineBird]

One way is to use an otherwise unused property of all your TYPEDEFS to store the name in. You could use CAPTION, DESCRIPTION, or TIP.
If you set the CAPTION property of your TYPEDEF to "My TypeDef", then your doc generator can use a contol refnum and a property node to get at the caption.
On second thought, that might only work for STRICT TYPEDEFS, since the caption may be independent otherwise.
Even if that works, it means going back and editing your 350+ files.

< UGLY HACK ALERT >
Another way is to compare the TYPE DESCRIPTORS to a known set of type descriptors.
Suppose your doc gen app has a cluster of 350+ instances (one instance of each) of your typedefs. You set the caption or label of each one of these to the text you want to see.

Use the CONTROLS[] property of the cluster to get an array of control refnums. When you have a control you want to find the type of, get its TYPE DESCRIPTOR.
Search thru your reference control refnum array, getting the TYPE DESCRIPTOR of each, and comparing it to the TYPE DESCRIPTOR of the control in question. When you find a match, extract the CAPTION of the reference control and use it.
Be aware that the TYPE DESCRIPTORS may be 100+ words long.
You might have to include the basic types (I16, U32, STR) in your reference cluster, or deal with them separately if not found in your table.

< /UGLY HACK ALERT >

The type descriptors are meant as an internal structure, with good reason, I suppose. NI can change them at any time. Still, comparing them for equality shuold always be valid.

[Sweet William]

Thanks CMB

I actually sorted this out and came up with a variation on the UGLY HACK. Rather than loading all the typedefs, I just load the ones that are in the Callees[] list and compare type descriptors. It works like a charm except I can't figure out how to tell if the object is a control or indicator.

Aloha
Bill

[CoastalMaineBird]

Yeah, I did a doc-gen app last year and I couldn't find an answer to that, either. I wanted to list all the inputs in one table and the outputs in another, but couldn't find a suitable scheme to determine a control's direction. I don't think the Type Descriptor tells you that.

[Sweet William]

I did some hunting and found this link

http://digital.ni.com/public.nsf/3efedde4322fef19862567740067f3cc/32e64e35fc96e9f4862569fa0059b978?OpenDocument

It talks about the Is Indicator VI that NI has made available for this.

Ciao

[CoastalMaineBird]

Hmmm. LabView 7 has an INDICATOR property for controls. The HELP is broken for it but it returns TRUE for an indicator, and FALSE for a control.

Sounds like just what I needed.

I tried writing to the property (wouldn't THAT be special?), but I got an error message to the effect that "This property is writable".

I would have thought the message should be "This property is NOT writable", or the property node should not have allowed me to set it to write mode, but they don't ask me these things....

[Greg_McKaskle2]

> Hmmm. LabView 7 has an INDICATOR property for controls. The HELP is
> broken for it but it returns TRUE for an indicator, and FALSE for a
> control.
>
> Sounds like just what I needed.
>
> I tried writing to the property (wouldn't THAT be special?), but I
> got an error message to the effect that "This property is writable".
>
> I would have thought the message should be "This property is NOT
> writable", or the property node should not have allowed me to set it
> to write mode, but they don't ask me these things....

It looks like the property description is missing the NOT, but notice
the second part of the entire message.

"This property is writable or this method is available only when the VI
is in
edit mode."

That means that you can set this if the VI has not yet been reserved or
isn't running. Since it is valid to use this to write to editable VIs,
the diagram lets you pick it and then has to tell you when you try to
use it on running VIs.

Greg McKaskle

[CoastalMaineBird]

That means that you can set this if the VI has not yet been reserved or isn't running.  Since it is valid to use this to write to editable VIs,

Hmmm. So I could have a program that dynamically loads a VI from disk, changes all it's controls to indicators, and all it's indicators to controls, and writes it back.

Given that changing a control to an indicator will break the diagram in which it is wired, I'm hard pressed to think of a good use for this, beyond monkeying with the boss's VIs over the network.

Can you suggest one?

[KellyH]

The error description should read "This property is writable only when the VI is in edit mode, or this method is available only when the VI is in edit mode."

We will address this in a future version of LabVIEW.

[CoastalMaineBird]

The error description should read...

Notice also that the HELP for this property doesn't work - If you have the property on a diagram, and ask for help on it, there is no such topic in the help file.