Leaderboard

Yep. The password can't encrypt the diagram. The whole point is that the diagram is still readable so that it can be recompiled. If you want security, you have to save your VIs without diagrams and give up the ability to recompile for different platforms and different LV versions.You're just lucky no one has build an equivalent of Reflector for LabVIEW. It can regenerate C# source code from the binary compiled DLLs or EXEs, even without the debug info being included. In the modern world, you have three choices: don't share your code in the first place only give it to users who aren't dedicated to getting into your code or for whom it is cheaper to buy it than to crack it get a lawyer to enforce your copyright and terms of use. Small claims court is your friend here. Those are your options. Let's just say his next PXI chasis will be "calibrated differently" and leave it at that.

Actually, I can confirm that the basic concept does apply in 2009 and probably in later versions as well. The reason for this is simple - LV needs to access the source code in order to compile it to machine code. Since the user can't be expected to provide the passwords (since, for instance, some of the VIs in the hierarchy were written by someone else) LV needs to be able to read the code even without the password. That means that the code itself can't be encrypted. Then, as Shaun mentioned, you get a place in the code where you need to check if the user's password matches the VI's password in order to show the BD and if you patch the LV executable to override that check - voila. In any case, it should be pointed out that other IDEs don't have password protection for source code, at least not as far as I know. I understand why NI put it there, but it should be clear that it's not something you can rely on if you expect to protect your code from someone determined.

AAAAAHHHH! I've gone blind in one eye!!!! Put the names away!!!

Should you really be asking that question?

The byte sequence will change every re-compile-so it is unlikely to persist exactly as in that post across versions or even the same versions with different bitness. But at some point you have to say "Is it? or Isn't it? a correct password" and finding it is easier if there is a dialogue since you know where to start. I think most of NIs password protected files are purely to hide the terrible coding. Not that bothered if someone sees mine.

I've renamed the existing function to include DBL, created a polymorphic VI using the original function name and added the INT version. I also added the conversion to/from DBL to avoid the coersion. (see image). numeric.llb.zip

Go Koan: "Beginners and Masters make the same moves. To those in the middle, both appear random. The difference is that the master knows why he made the move."

I have been using a programmable 5 button MS Explorer mouse since they came out. I program the buttons to the three keyboard keys I use the most Shift (Left back) Delete (Left front) CTRL (Center mouse wheel)) Several years ago I went all out and started using my tricked out programmable gaming joystick I programmed it with all the LabVIEW shortcuts and used it with my left hand. It worked great at home but because I couldn't have one at every machine that I worked on it wasn't as effective as I originally had hoped. Fortunately I was able to put the programmable mice at each computer which made for a common platform to work with. Quick drop was a great productivity boost for me and because my right hand can press the ctrl and shift keys my left hand only needs to press one key at a time There are many Quick drop short cuts that make development easier. Here are a few links to QD shortcuts. https://decibel.ni.com/content/groups/quick-drop-enthusiasts https://decibel.ni.c...t/docs/DOC-9573 http://zone.ni.com/r...op_shortcut_db/ http://labviewartisa...p-keyboard.html

I would suggest to make the Upper limit required, and check for the min/max (use the native sort 2 number primitive). And I would make this a polymorphic VI with all the Int/UInts and double. Ton

A) I definitely would not provide default values for those input terminals. Make them required. I can't believe that the majority use case is going to be coin flipping between zero and 1. If you want to write a specialized "Coin Flip.vi", fine, but give that one a boolean output. B) What happens if High is less than Low? Perhaps an absolute value node should be added to the subVI?