Password Protect a Single Tab in Dialog Tab Control

[PhillipBrooks]

I found this book to be very helpful in understanding how to effeciently use LabVIEW to solve problems.

A Software Engineering Approach to LabVIEW™ by Jon Conway, Steve Watts

http://safari.informit.com/0130093653

This book is a bit dated, but the techniques described are still valid. It was suggested to me by a senior NI software engineer, and it really opened my eyes.

When you mention the use of locals and globals, experienced LabVIEW users will point out that these can cause a host of problems including race conditions. Locals and globals can often be eliminated by use of a combination of data flow, shift registers and case statements.

Message Edited by Phillip Brooks on 05-29-2007 01:01 PM

[Nightghos]

Thanks, that very helpfull, just to let you know, the application i'm developing it needs variables, because is very customizable, that's why i can't avoid the use of variable all over the place, i'm using shift register to change states between this system. But like i said to the guy everything depends on the "design and the problem i'm doing".
I have a lot parameters customizable from the user input. So, how i can do that without variables? enlight me on this one, because it surprise me that this is the first forum i know that you guys talk about "bad coding" without asking what i'm doing first. Fully customizable means a lot of variables, shift registers are use on the process, not as a "variable" input from the user.

[PhillipBrooks]

One of the techniques used to handle lots of data like this is to create "functional globals". These are also ofter reffered to as LV2 globals (LabVIEW 2.0 and before had no concept of globals) or sometimes as action engines.

These are sub-vis that contain a while loop, a shift register and a case statement to perform actions, such as "set ", "get" or "initialize". When you "set" a value, you store the contents of the input variable in the shift register. When you perform a "get", the contents of the shift register is returned. For a better description, see this LabVIEW Wiki entry. You can also search the forums and NI Developer Zone for keywords ("functional global")

If your while loops have too many "telephone wires" (lots of shift registers at the top that you keep wiring over and over again each time you add a case) then functional globals may help. The first book I mentioned is very good, and you might consider two newer books, "LabVIEW for Everyone, Third Edition" and "The LabVIEW Style Book". (I own all of these, and I am not affiliated with the writers or publisher in any way).

Message Edited by Phillip Brooks on 05-29-2007 01:27 PM

[Nightghos]

Functional Global Variable. Is a variable isn't?
And in my case the value of the my variable is so wide, that is not worth to enumerate everything in shift registers, you end up wasting time, instead of saving time, also you charge the memory with unnecesary space.
SubVI's is a class. Set, Get, Initialize, class lingo.
At the end those functional global variable, are possible to manage as Pointers, and references, in my case the input is straight and the number is used right away, like I said to you the input can be from 0 to 360,000 with decimals, so you want to make a shift register this big? i don't thinks so. A Class (SubVI) can help, but still you will need a variable from the user input.
Anyway all you guys are telling me is a diferent way to call the variables, and classes that handles variables. If you read carefully the links you send me, those are variables at the end managed by classes. I don't need more layers on my program.
Very smart people here, but in this particular program i don't see a reason why adding another layer to my program, wasting time, energy and memory are needed to make your suggestions, happen, I just happen to need simple and plain variables, not classes on top of them.

[Nightghos]

Besides all this variables discussion, my comments was that i don't like graphical programming as much as  I like conventional programming. "It's just an opinion".
The Password protection in the Dialog Tab was a very helpfull tip.
It's just that i don't agree with your suggestions about the variable, if i need a variable i will use it, if I see that a Class (SubVI) is going to be usefull for other problem, i will use it, like i said for the approach of this specific problem i don't need.
You see, in the Case of the Single Tab Control the answers were smart, because you guys know exactly the problem, so you give a solution.
In my case with the variables, you still didn't even ask me about my problem, and you're just throwing balls, being a loose cannon.

Message Edited by Nightghos on 05-29-2007 12:56 PM

[JDave]

In LabVIEW words like variable, class, and function carry distinct meanings.  New ideas like subVIs and Functional Globals do not correlate directly.  So while people have been making assumptions when providing suggestions to your particular problem, assumptions have been made regarding their ideas without fully looking into them.  Their suggestions are very good and are roughly equivalent to saying "Make sure in that C++ program you make your classes have high cohesion."  Some ideas are independent of the problem being tackled and merely represent 'best practices'.

[shoneill]

Nightghos,

Are you sure you've grasped the idea behind LabVIEW?

You claim to have much experience in C++, but software architecture (i.e. heirarchy) is as important there as in ANY other language.  It's not a LV thing.

I find the application of typical software engineering principles to LV a rewarding exercise.  Cohesion, coupling, encapsulation, data hiding and abstraction all help keep code maintainable.  If done properly.

A lot of us here have a LOT of experience in LabVIEW and understand how it works "under the hood".  Using variables is only very rarely the correct solution to a problem.  Local variables are hugely over-used by people coming from languages like C++, because LabVIEW requires a different way of thinking about data.

Are you aware of thread switching, data copying and so on?  Not to mention race conditions.... If you want to post a piece of your code, we'll show you WHY locals aren't the best solution.  And of course, if your application happens to be one of the rare cases where it IS the best solution, then we're of course big enough to admit that.

Show us the code before ranting.  Your assumption that variables are a good solution while bad-mouthing others who are trying to help is quite impolite.  Put your code where your mouth is or keep your venom to yourself.

Shane.

[vrundquist]

I just wanted to comment on the use of passwords at start up.  I have a program in which I password protect the setup variables with the property nodes using a sub vi to enable / disable the 'visibility' of the controls.  the reason for this is that the program is running a system in line with a production facility providing data on QC.  Therefore it is never shut down or re-started.  For me I have to control access while the software is running and LabView does a great job letting you do this by hiding and enabling certain controls.

BTW, I do all of this without the use of local variables.

Another method to do this is to use the vi ini file vi's.  LabView allows you to write custom setup files with custom tags etc for all of your setup variables.  Your program can read this file when it starts up.  You can then have another vi dedicated to the changing of the parameters in the file.  Then just password protect this vi.  Your main program can be signaled to re-load the configuration file if the config vi. changes it.  I have done it this way before and it works very well too.  Don't try it with a program that requires precise timing as disk access in LabView can be slow.

Victor Rundquist

-using LabView since version 5

[buba]

I found the samples helpful, but Am still learning how to use labview. I did not get how you did the password in sample2.llb(47 KB), tried to do it but couldnot. I want to know how please, thank you.

[vt92]

sample2.llb shows you how to disable/enable controls (not tabs) with a password.  This example could be modified to do the same with tabs.

Something like the attached...