topic Re: Hidden Controls in LabVIEW

Hidden Controls

jspaarg — Tue, 07 Feb 2006 21:30:19 GMT

Is there a global way to show all hidden controls?

The only way that I have found is to right-click the block diagram control and click "Show Control".

Problem is, how do you know which controls are hidden?

Any help is appreciated.

Re: Hidden Controls

tbob — Tue, 07 Feb 2006 22:08:25 GMT

The method you described is the only way that I know of to show hidden controls. The only way to find hidden controls is to do this on every control in the block diagram one at a time. Yes it is a pain.

Re: Hidden Controls

Darren — Tue, 07 Feb 2006 22:40:44 GMT

It would indeed be cool to have a menu option in LabVIEW to show all hidden controls on a panel. Who knows, maybe we'll see this feature in a future version of LabVIEW... 😉

-D

Re: Hidden Controls

michenglaoxu — Tue, 07 Feb 2006 22:50:01 GMT

It makes the code really unreadable. NI should do sth for Hide control in its next LV version.

Re: Hidden Controls

jspaarg — Tue, 07 Feb 2006 23:01:01 GMT

I am used to a number of global development environment concepts that would benefit LabView.

I have been writing software for a lot of years, but have only been doing LabView for about six months.

Among my biggest complaints has been lack of project based development, which was apparenetly added in 8.0.

I am using 7.1 and chance of upgrading is slim.

Is there a place on the forums or elsewhere where NI solicits input for feature enhancements?

Re: Hidden Controls

Darren — Tue, 07 Feb 2006 23:09:34 GMT

Yes, you can submit suggestions here:

http://digital.ni.com/applications/psc.nsf/default?OpenForm

Thanks for your interest in making LabVIEW a better product,
-D

Re: Hidden Controls

Ben — Wed, 08 Feb 2006 00:26:21 GMT

Attached is a simple VI that will iteratively search for controls and when one is found, set its visable property true. Change the "This VI" constant to a path control if you want to use this VI on other VI's.

Most of its opeartion is self explanatory except the "to more specific" function that is used in a manner I first saw demonstrated by Jean-Pierrre Drolet. If LV is succesful in converting the control reference into a tab control reference, it assumed to be one. In that specail case, we gather a new set of control references and add them to the pile.

the process continues until we can not find any more controls to make visable.

Can I ask you a question please? You said "Among my biggest complaints has been lack of project based development, ...".

If you miss it then you know what to do with it. I have not quite figured out what I do with it now that I have it!

So what should I be able to do now that I have LV 8 and project management?

Curious,

Ben

Message Edited by Ben on 02-07-2006 06:27 PM

Re: Hidden Controls

Darren — Wed, 08 Feb 2006 01:26:27 GMT

...to make a slight addition to Ben's example, don't forget to recurse through Clusters and Arrays (the other control types that can contain other controls) in addition to Tab Controls. And in case you're wondering, yes, you can make the element inside an array invisible... 😉

...and in case you're still wondering, RadioButtonsControl inherits from Cluster, so you don't have to parse those separately from Clusters.

...and in case you've stopped wondering, I'm thinking about officially adding a panel parsing VI to vi.lib somewhere in a future LabVIEW release so you guys can stop writing your own...if you own the VI Analyzer, you've already got one: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Get All FP References.vi.

-D

Re: Hidden Controls

Ben — Wed, 08 Feb 2006 01:39:49 GMT

I'm thinking about officially adding a panel parsing VI to vi.lib somewhere in a future LabVIEW release so you guys can stop writing your own...if you own the VI Analyzer, you've already got one: vi.lib\addons\analyzer\_analyzerutils.llb\VIAnUtil Get All FP References.vi.

(You appear to use the color scheme that I do for my boring VI's.)

Oh yes please do!

Aside from the method I used in my example I have only seen scripting methods used to ID control types. Do you have any recomendations on better ways of identifying what type of control a reference is associated with?

Ben

Re: Hidden Controls

Darren — Wed, 08 Feb 2006 02:27:08 GMT

I made this suggestion in another thread recently...you can wire a control reference into vi.lib\utility\GetType.llb\Get Type of Control.vi, and it returns an enum describing the datatype of the control. As for identifying controls based on their class, you can use the Class Name property of the Control class.

-D

Re: Hidden Controls

tst — Wed, 08 Feb 2006 07:59:49 GMT

Darren, I like that!

I do have some questions, though.

What do the NEVER, boolU16, Extdata, Variant, Handle, Substring and Subarray mean? When (if ever) will we get a C or Pascal string as a result?

Re: Hidden Controls

Wiebe@CARYA — Wed, 08 Feb 2006 10:10:35 GMT

It's easy to make a vi that does this for you. Get the VI reference, get it's front panel, get all controls, in a for loop set the visible property. You can optionally get the control name, and do some filtering on it.

(You can also put this functionality in a sub vi, and with some UI handling, make the VI suitible to put it in the tools menu. Just put the VI in the project sub directory of LabVIEW.)

Regards,

Wiebe.
"jspaarg" <x@no.email> wrote in message news:1139348445949-321685@exchange.ni.com...
Is there a global way to show all hidden controls?
 
The only way that I have found is to right-click the block diagram control and click "Show Control".
 
Problem is, how do you know which controls are hidden?
 
Any help is appreciated.
 

Re: Hidden Controls

jspaarg — Wed, 08 Feb 2006 13:57:38 GMT

All these ideas and VIs sound really useful, but they still seem to be a work-around for an inadequacy in the development environment.

It still seems that solution is for NI to provide a menu item (e.g. under edit) that just turns modifies the visible attribute for all controls (and indicators) in a project.

Re: Hidden Controls

Ben — Wed, 08 Feb 2006 14:06:13 GMT

Darren wrote;

"...you can wire a control reference into vi.lib\utility\GetType.llb\Get Type of Control.vi, and it returns an enum describing the datatype of the control. "

I have to agree with tst that this is an excellent piece of information.

I had previously known about the type descriptor and parsing it to pull out info like the strings associated with an enum. I had concidered writing code to parse all the variations of the type descriptor but two issue stoped me.

1) Parsing types within types like arrays in clusters or clusters of clusters etc.

2) The danger that all of my work would go to waste if NI added new data type (like in LV8) and had to modifiy the type decriptor to support the new data type..

Finding out about this utility and specifically "Get Type Code from I16 Array.vi" solves these issues!

Thank you Darren!

Ben

Re: Hidden Controls

Ben — Wed, 08 Feb 2006 14:33:38 GMT

Darren wrote (in that oher thread)

If you're using LabVIEW 7.0 or later, you can wire any control reference into this VI:

That's why I missed it. I stoped looking in LV 6.0! I guess I spent so much time trying to shut-off the "guess the wrong tool" feature that I missed the really good stuff.

Ben

Re: Hidden Controls

jspaarg — Wed, 08 Feb 2006 14:43:54 GMT

To Ben: regarding your post yesterday

I have been writing software for a number of years in various development environments that were project-based (C++, VB, Delphi, numerous assemblers, etc) but have only been using LabView for about six months.

One of the biggest advantages in project-based environments is the ability to maintain different versions of the same file in the different project folder and have the environement recognize that they are different files. With LabView's "memory model", I have lost much work because it overwrites files in memory with the old versions. Yes it gives popup warnings, but they don't really indicate the consequences. My understanding with 8 is that you can load multiple copies of the same-named VI into memory. This allows you to compare the two visually.

Other features that are present in most project-based environments (but may not be valid for LabView) are:

The ability to link in pre-built libraries,

The ability to run post-processing programs on built systems.

The ability to run simulations and inject signals.

Well-integrated help (I find LabView's help to be very middle of the road in terms of ease of use)

Re: Hidden Controls

Ben — Wed, 08 Feb 2006 15:01:34 GMT

Thank you jspaarg.

Ben

Re: Hidden Controls

cs42 — Wed, 08 Feb 2006 15:08:20 GMT

One of the biggest advantages in project-based environments is the ability to maintain different versions of the same file in the different project folder and have the environement recognize that they are different files. With LabView's "memory model", I have lost much work because it overwrites files in memory with the old versions. Yes it gives popup warnings, but they don't really indicate the consequences. My understanding with 8 is that you can load multiple copies of the same-named VI into memory.

Are you sure that you can have VI with the same name in memory in LV8?

Actually this is one of the biggest problems I have with LV. Why didn't they include path information? That would make things so much easier. What's annoying for me as well is, that after a "save as" of a VI, all callers which have been in memory (i.e. all VIs having been loaded in an LV session) will refer to this "new" VI. It's OK for VI that are actively open (but even then I'd rather liked to be asked) but for VI that I did already close this can be annoying...

What I think is nice with the project view is, that you have a view with all the things in one place (without having to use the hirarchy viewer and a file system browser). You can even see "external" dependencies. Unfortunately we won't be able to switch to LV 8 soon...

Cheers,
Carsten

Message Edited by cs42 on 02-08-2006 04:09 PM

Re: Hidden Controls

tst — Wed, 08 Feb 2006 16:01:10 GMT

@jspaarg wrote:

Other features that are present in most project-based environments (but may not be valid for LabView) are:

I don't have any experience with other project-based environments, but some of these may be already available in LV. Perhaps you can explain more and we can tell you.

The ability to link in pre-built libraries,

I'm not sure what you mean by this, but here are 2 guesses: in LV you can use the "VI Server" to call VIs dynamically so you don't need to have the libraries when you build the application. You can also place your own VIs in the palettes, e.g. by placing them in the user.lib folder.

The ability to run post-processing programs on built systems.

Again, I'm not sure what this means, but dynamically loaded VIs may be the solution here as well.

The ability to run simulations and inject signals.

LV is well known for its ability to simulate data and for allowing you to test your code very easily. The fact that each function can be run directly allows you (mostly) to test your code from the bottom up.

Well-integrated help (I find LabView's help to be very middle of the road in terms of ease of use)

I know that the LV help system is not always clear, but I find it to be mostly very good. I like the fact that you get the context help (ctrl+h) which allows you to see more details about what you're looking at without opening a new window and I like the fact that it's context-sensitive (right click something and you get help specific to it). do you have any concrete suggestions?

@cs42 wrote:

Why didn't they include path information?

I have several guesses:

A legacy from a time where long paths were a problem. It wasn't changed until a project environment was created.
To more easily support platform independence.
To keep the relative path scheme which LV has. Something which can't be done with full path names.

Re: Hidden Controls

Darren — Wed, 08 Feb 2006 16:20:35 GMT

Hi tst,

My understanding of that enum is that all its types originate from a list of internal LabVIEW types (i.e., stuff in the LabVIEW source code). Obviously most of those have analogs to controls/indicators in LabVIEW, but some of them (like the ones you mentioned) do not.

-D

P.S. - I was going to discuss the GetType.llb as a Weekly Nugget topic, but I think it has sufficient coverage now that you posted it to the Interesting Topics thread. Looks like I'll have to discuss some other cool utility hiding in vi.lib somewhere instead... 🙂

Message Edited by Darren on 02-08-2006 10:21 AM