Yair

LV 7.0, Win XP pro. When minimizing a LabVIEW window using the FP.State property and then restoring, the Mouse Enter and Mouse Leave events stop firing until you enter another LV window and then return to normal. This doesn't happen if you use the window's minimize button. An example is attached. Download File:post-1431-1126430850.vi

OK, here's another version. It becomes opaque when you enter the window (I had to replace the checkbox for that) and uses a string instead of the array, which looks better. Implementing the resizing will be more complicated, because it involves making sure that the window does not become too small and will probably require turning the VI into a state machine. Download File:post-1431-1126426494.llb

Actually, I think it even existed in 6.1. This VI already uses the mouse leave event. You can copy the transparent VI with the input into the mouse leave event and then duplicate the case for the mouse enter event and feed 255 into the VI. The problem is that the white backgrounds remain transparent when you do this and only return to white when you stop the VI. This VI would actually be portable into 6.1, but that didn't include the mouse input VIs used to move the window around. Those could probably be worked around using mouse events (move, up, down, leave), but I don't feel like it. Like I said, this program was written rather quickly, so the result isn't perfect, and there are some problems porting. One example is that I now opened it on another computer and the minimize and close buttons have different sizes (They could be replaced with buttons with images). Some other improvements could be making it resizable, getting rid of the taskbar button, maybe adding a taskbar icon and using a string instead of the array for display (again, quickly written).

You might wish to search for Greg's presentation from one of the NIweeks (I think it was 2000) called "The good, the bad and the Ugly", where he shows a nice example of how to analyze the problems with a UI and correct them. The things I write are usually not for scientists and engineers, but for simpler people, and can involve running complex systems, sometime with touch screens, which are harder to design for (you need larger buttons, can't really use menus). A favorite technique is taking a relevant picture and using that as part of the interface. If the picture is too colorful, reducing the amount of color helps to make the indicators stand out (the same thing that happens when winXP's shutdown dialog pops up, and I swear I thought about it before them, or at least before they published XP). That makes it much clearer to the operator, better than any text label can. I agree that using gray as the background is usually good, because it helps make your stuff stand out, and that using too many colors is usually bad, because then nothing stands out. A good UI should be clear to the operator.

Since this is a LabVIEW board, here is a quickly written clock similar to that one, windows only. It includes transparency, a round window, the ability to be always on top, and the ability to be moved by clicking anywhere inside the VI. I used code from LTR, LVWutil32 and LAVA to do the window shape, always on topping and transparency, but since they all call user32.dll (as far as I could tell), I think it should work as is. I don't use it myself (I believe in a clean computer. If I want the time, I have it in the corner of the screen), but if anyone thinks this is nice and would like to improve it, I wouldn't mind seeing the results. Download File:post-1431-1126381117.llb

If you have the reference to the loop, wire it into a property node and get the Loop End Ref>Reference property. Wire it into an invoke node with a Create Control method.

That's not entirely accurate. You can use the VI class method Fake Exec State to trick LV into thinking that the VI is idle (state 2), but you should be aware that many features will either stop your VI, cause it to crash or cause LV itself to crash, because modifying LV code while the VI is running is almost a sure way to do that.

For those interested, this presentation can be found here.

Yes, you can only run an EXE on the platform it was built in, and I remember seeing a fairly detailed explanation from Rolf somewhere on exactly why this is so. An OS emulator (like wine) would probably work if you don't use hardware, but I don't know how fast or reliable it would be.

You can use the VIs you wrote in windows, but if they call windows specific code (DLLs, registry VIs, ActiveX), that code won't work. All the code that is pure G should work.

Build a three-frames sequence structure. In the first and third frames place the tick count VI and in the second frame place your code. Subtract the value of the counter in the first frame from the value of the counter in the third frame and you have your time (in ms). Note that updating front panel controls can create some serious jitter, so unless this is part of your test, you should not update any control inside the second frame.

There should be some overhead when converting to variants. As a neater solution, if you have the professional version of LV, you can create a polymorphic VI, which is basically a collection of VIs with similar connector panes, but where some of the input data types are different. Once you wire in an input which exists only in one of the subVIs, that subVI is selected, similar to what happens when you wire an array of a certain type or size into an array function. To create a polymorphic VI go to File>New and select Polymorphic VI. Now you can have one VI which will save a DBL, another which will save booleans and so on. Don't forget to include a variant one. You can save all of the VIs in a single LLB and have the polymorphic one as the top-level VI. You can also look at some of the VIs from OpenG for examples (like the Data Changed? VI). This should at least remove the overhead involved in the conversion.

For example, having the ability to set the execution highlighting to run only in certain parts of the VI, or only when certain conditions happen (like using a BP\Conditional BP, but having LV turn HE on and off automatically). Or, like having a slide speed control which will allow us to play with the speed of the flow, so we can tell it to move fast when we see it gets to a boring loop, or tell it to go slower or fully stop when there's data we want to examine more closely.

Which VI gave you this error? Are you trying to explicitly include it in the application? You should have no problem building executables that use the picture functions, and you shouldn't have to explicitly include them. They should be installed with the run-time engine if you create an installer for your application. If you call them dynamically and want to make sure the application knows about them, place them in a VI and include that VI in the build.

Your question is very general, but I would say use a for loop with some waiting and place the indicator in the loop. Here are 2 examples, one using shift registers and one using calculation.

The easiest way is to use a global. Drop a global from the structures palette on the diagram and double click it to open a Globals VI. All controls in these VIs can be accessed through the globals. Create the control you need, wire the data into it in one loop and copy the global to the other VI and read it there. You should note that using globals can be dangerous if not used properly, because you can easily get race conditions. Another global option you can look for is LV2 style globals, which are somewhat safer in the race conditions department. You should look up some LV tutorials which explain these things.

Hi Joel, welcome to the LAVA forums. I think you will find out if you put some time into the LAVA forums as well you will find it even harder to reach 1000 replies. Plus there are no s here. I use LV for various control applications, also in agricultural and semi-industrial applications (like growing fish or sorting corn), while providing advanced communication (wi-fi, ethernet) and various interfaces (PDAs, cell phones)... Ditto for the games comments.

Yes, for the exact reason I mentioned before. People think it's "programming for non-programmers" so they just go ahead and do it. I know what you mean about bad diagrams (and FPs). I never could figure out how so many new users manage to find the Value property before they find local variables. I see that very often users use it extensively (usually without refs, because they don't know what they are), and have the terminal put somewhere on the side. I have no idea how people can read such code, with wires going to the left, overlapping objects and so on. Then again, I never could figure out why certain members of my family have a tendency to leave a mess whereever they are when tidying up the room takes about 30 secs. I'm sorry, you're right. I should have said "a properly written diagram is much easier to grasp in a single look..." and I still consider this to be true, as I'm sure you do. The color coding and the fact that you can clearly see structures really help when you look at large piece of code (more than 6 or so nodes). This doesn't negate my previous claims about documentation. I still think that it's preferable to read a comment that tells you what the code does than to start figuring out by reading the code. This also helps when debugging, reviewing or modifying the system later, because you know what the programmer intended for the code to do.

Just some minor nitpicking, not disagreements - I don't know about SCC, but LV has a built in comparison option, at least on a single VI level. The files are tens of Ks, because unlike the small text files, they also include the front panel and the compiled code, which allows each VI to be fully executable by itself. As far as I know, the building into an executable produces different code because the builder adds some information to the file (date\time and such). I don't think it affects the building of the executable code.

The simplest way is to use the built in remote front panels feature. All versions other than the base version have it and you should get 1 or 5 licenses with LV. You will need to activate the license using the license manager (Start>Programs>NI). This will allow anyone to view the VI. If you want someone to control it, they will need to install the LV run-time engine, which should be a free download from NI's site. You should also consider the fact that only one person can control the VI at any given time. Read the LV help for more details on this feature. Another option, which does use JAVA and is free, is LabVNC (search google for it). It basically translates your FP into a JAVA applet, so you don't need to install the RTE on remote machines. The main down side to it is that it wasn't a commercial project and that its development was stopped several years ago, so it may not be fully finished and it may have bugs.

Does your firewall filter ZIPs which have been renamed to have a different extension? It should be easier for people to download one file and rename it. Also, an important tool is the LLB, which allows you to save many VIs to a single file (although you need to be careful in how you use it). You can save as an LLB by going to File>Save with Options>Development Distribution. Just a tip for next time. :arrow:

I had no problems hearing it with windows media player 10 under XP. I also tried the mplayer2.exe (that's version 6.4) and it worked fine.

The podcast (about 30 minutes, 18 MB) has been posted to NIs FTP server here. The file is called LabVIEW Architecture Podcast Project.zip

I suggest you try posting to NI's forums. At least 2 regular users there (Unclebump and Donald) have some experience with these things and can probably help you.