Hidden Controls

[tst]

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?

[Wiebe@CARYA]

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?
&nbsp;
The only way that I have found is to right-click the block diagram control and click "Show Control".
&nbsp;
Problem is, how do you know which controls are hidden?
&nbsp;
Any help is appreciated.
&nbsp;

[jspaarg]

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.

[Ben]

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

[Ben]

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

[jspaarg]

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)

[Ben]

Thank you jspaarg.

Ben

[cs42]

---

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

[tst]

@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:

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

[Darren]

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