asbo

I don't know that you could make an exception like that, but an unfortunate but functional solution would be to copy the VIs you use out of vi.lib and keep them in your source directory so they're included like your other code.

dannyt seems to have been more insightful than I was and figured out what you were actually going for. You're going to want to learn up on state machines (I see 3 states, minimum: idle, login, and logout). You'll have a parent VI which calls either main.vi or login.vi. You'll need to decide how you want to keep track of whether the user is logged in or not - you can use globals and call the global where ever needed or you could use a shift register in the parent vi and have the state passed as an input to main.vi or login.vi.

QUOTE (Darren @ Jun 3 2009, 06:08 PM) Weekly Scripting Nuggets ... ?

QUOTE (ShaunR @ Jun 2 2009, 03:56 PM) R.I.P., data flow ...

Here's a method that uses a relative path to open a VI reference. The VI reference allows you to manipulate the other VI at run-time. You can execute either VI, but because there is absolutely no communication between the VIs, they don't know which one started first, so both will be visible initially. As soon as you click the switch button, one will hide and the other will stay visible. This is just an example to illustrate the concept for you, you should not just plunk this down into your project and expect things to work spiffy. If you have questions about this method, fire away.

Go forth and kudo: http://forums.ni.com/t5/LabVIEW-Idea-Excha...ey/idi-p/917715

QUOTE (Minh Pham @ May 27 2009, 10:50 PM) While it doesn't do horizontal scrolling, there's no way I'd ever abandon my glorious trackball: QUOTE (Rashid Malik @ May 28 2009, 08:12 AM) What is this auto-tool you geeks keep referring to. Will you point me to its (download and documentation) location. Thanks a lot! It's formally known as the automatic tool selector and you can find it by shift+right-clicking the diagram and clicking the crossed wrench and screwdriver on that palette which pops up.

For whatever reason, I never actually submitted this suggestion to NI. I just did, though, and you lot should bombard them as well. Glad this thread came up again, though ... I'd already forgotten Yair's CTRL+SHIFT+Drag trick.

I can't look at your screenshots now, but my book recommendation would LabVIEW for Everyone by Jeffery Travis & Jim Kring. Also, you shouldn't post screenshots in a Word doc - just save them off as an actual image (using Microsoft Paint, if that's all you've got) or maybe even upload your actual VIs.

QUOTE (Black Pearl @ May 21 2009, 02:50 PM) I found likewise:

QUOTE (Black Pearl @ May 21 2009, 11:59 AM) An aside, but this is only true if you were to use tunnels. If you initialize the shift register with the reference, you'll get that same reference out of the loop even if it iterates zero times.

You're probably not going to get people writing code for you, especially for a school project. NI ships LabVIEW with examples for tons of things, you should look through there before posting here for answers. You're going to need a while loop and a wait, or an event structure.

I thought that might be the case, but decided to throw it out there anyway. There isn't a way to give permission per-process, so obfuscation/checksum/encryption is the way to go.

With BSD licenses, only the copyright notice must stay intact - the code can be distributed in either source or compiled form at the will of the developer.

Is your code being run by the same user who is mucking around? If not, both *nix and Windows will let you tweak read/write privileges on per-user and per-group basis.

Two people before me have told you to look at the examples - you really need to start taking their advice. There's an example of how to do a login dialog and already includes outputs indicating the result of the login attempt.

I tested by checking out a repository one revision back, then checking out again with the same target and no revision specified - it was, in fact, smart enough to update the working copy instead of re-checking out everything.

QUOTE (Aristos Queue @ May 14 2009, 08:34 PM) If this isn't exposed anywhere, how has it made it into non-NI VI's? Moreover, *why* isn't it exposed? :ninja:

Maybe they're just trying to impress you .. :ninja:

You should mention that you're cross-posting: http://forums.ni.com/ni/board/message?boar...ssage.id=407852 You can accomplish this without having to mess with any APIs or registering for events like Ton mentioned in the opposing thread; check out the Input Device Control palette. All you need is Initialize Keyboard, Acquire Input Data, and Close Input Device.

QUOTE (Justin Goeres @ May 8 2009, 08:40 AM) Which is why I often wish LabVIEW had some convention of NULL implemented ...

Some ideas I've stumbled across: - Dump everything into a subVI and paint the VI's icon to look like a wire. - Put everything in a sequence structure, turn off Auto-Grow, and resize it to hide what you don't want seen. - Paste a plain-white bitmap over top of everything. Like jdunham said though, if you're looking to protect code, use proper methods like passwording the BD.

QUOTE (PaulG. @ May 6 2009, 09:06 AM) I've used these before and I think they're fantastic - with a few short comings. A) There's no way to "clean" an INI file against a cluster. If your typedef changes and you're using an older INI file, you'll have deprecated entries floating around that have to be removed by hand. B) It's not easy to get a list of entries missing from the INI but are present in the cluster - one of the methods will throw an error if the two don't line up and I ran into this. I toyed with solutions for these for a bit, but have bigger priorities so I never really came up with anything solid.

labviewnoob, go to the Help menu and select the Find Examples item. NI has a phenomenal number of examples showing how to accomplish many different things in LabVIEW. Give a man a fish ...

What format is the file? Perhaps you could attach it to post for us to look at?