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)

My first blog post on scripting:

Weekly Scripting Nuggets ... ?

QUOTE (ShaunR @ Jun 2 2009, 03:56 PM)

Like this one

<snip>

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)

For those who dont bother to wait for NI, i recommend to upgrade your mouse to "Mighty Mouse" as shown:

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)

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)

The device I connect via RS232 is not changing it's baude rate if I branch any wire. So I expect that splitting a wire and setting the baud rate on one branch would effect the other branch as well. It isn't a OOP clone, because that time, we didn't know what oop is alike.

I found likewise:

QUOTE (Black Pearl @ May 21 2009, 11:59 AM)

So 'best practices' are a matter of personal taste. The only issue you might run into is when passing the wire through a for loop that migh iterate 0 times.

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)

Use the Create New Object primitive which is not found anywhere in the palettes and is not addable through any ini token magic. You have to find an unpassword protected block diagram somewhere that has that primitive on it and copy it. I think OpenG has some scripting tools that expose this prim.

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)

I agree that it's sort of counterintuitive at first, but what would you expect the result to be instead? Even though the For Loop executes zero times, there has to be a data value on the I wire coming out -- that's the nature of dataflow. In this case, what's happening is that wire is taking the default value of its datatype (I32), and that value is 0.

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 think the simplest approach for your application would be using OpenG configuration files and a single cluster. I think you want to stick with a single cluster to keep data encapsulated and keep it simple. And the OpenG vi's have already been worked out for you. I use it all the time. It's just too convenient.

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?