hooovahh

I didn't say I compiled LabVIEW into an EXE, I used ThinApp, it's owned by VMWare. Basically you install XP in a virtual machine, then in your host machine scan the virtual machine's hard drive image, then in the virtual machine install any program you want, then in the host machine scan the hard drive again. It will create an EXE that is a virtual environment for the new files to live in, kind of like a sandbox. So then you have a single EXE with LabVIEW that can be taken to any computer and ran, which will be idential on any machine. ThinApp is very expensive, but it does have a 30 day trial, I doubt it is unlimited use in that 30 days, but if it is we get alot done in 30 days. I don't work directly for Crelf, but he probably has enough persuasion around here, that if he wanted my SSD he could get it, but he would never use his powers for evil. And as for the Miley Cyrus, well he borrowed my external drive and started snooping around, I'm just glad that's all he found on there.

Yeah I like nlite, but if you just want to minimize what things are installed on your Windows machine after a full XP is installed on it, I recommend XP Lite, it's a program that you install on a normal XP machine, then it removes services, and extras to make it smaller and faster. There is a free version and a pro, the pro gives you more access to other services, but most of them break Windows, so I don't recommend it. Not to digress too much but they also have 98Lite which can reduce the Windows 98 install size down to about 50MB with full explorer shell, not always very useful, but fun to play with. You could take that 50MB of files, burn it to a CD, then on boot up copy that to a RAM drive, and boot into a full Windows environment...sure a 11 year old operating system but it was fun to do when the OS was only 6 years old. EDIT: It appears they have the record to 8MB for Windows 98 with explorer.

NI has recently changed how you download LabVIEW evaluations. Instead of having a direct link to a zip file, you first need to download a 1MB downloader program, which will download the 700MB or so self extracting zip file. Here's the page to download the LabVIEW 2009 evaluation. https://lumen.ni.com/nicif/us/lveval/content.xhtml 2009 can open 8.6 files, but remember if you save any thing in 2009, it can't be opened in 8.6, you must perform a File >> Save for Previous Version to open it in 8.6.

Well you don't have to be technically. A while ago (just to see if I could) I made a single EXE that was LabVIEW 7.1, and 8.5. 7.1 because it is my favorite and does just about every thing you could want for most applications, and 8.5 because that was the newest version at the time. So imagine carrying around a 600MB EXE (for 8.5 or 300MB for 7.1) on your drive that you run and you have a full LabVIEW development environment available on any Windows computer. I was going to post how I made it, so others could too but it's been a while and I'm not sure I remember the steps needed, but I do still have the EXEs floating around maybe if I get time I'll try to make it again. The main issue with this is most people don't have just LabVIEW installed, they have several toolkits for projects they are working on. Adding toolkits to this EXE after it is built isn't impossible it just would take alot of work. And installing new packages via VIPM wouldn't be impossible it would just be manual. There could be a directory structure next to the EXE, which the EXE then uses as relative files. So lets say LabVIEW85.EXE and in the same folder is $user.lib$ and what you put in there will be used as extra files in the user.lib. So basically this EXE would only be useful for making quick VIs, or opening small ones and seeing what's going on, but if the VI needs any toolkits it will be broken.

THOSE AREN'T PILLOWS!!! (sorry for the caps but he was actually yelling)

Get use to constantly needing to clean up the hard drive. My drive is only 64GB, my National Instruments folder alone is over 10GB. Then there's Windows, other Program Files, several SVN repositories, and several gigs of music. I tend carry around a a 2.5'' external drive that I keep larger files on (like virtual machines)

I did a very un-scientific test and timed how long it took to startup LabVIEW in the different versions. I did not reboot after every start of a version, so I don't know that if opening 8.0 then closing it, would have any effect on how long it may take for 8.2 to startup. But I did restart several times and here's what I got. With my installed versions of 6.0, 6.1, 7.1, 8.0, 8.2, 8.5, 8.6, and 2009, the longest taking 18 seconds was version 8.5. On average it took 10 seconds to start a version of LabVIEW on the first start of that version. The shortest time was 6.1 with 2 seconds If I opened 8.0, closed it, waited then opened 8.0 again the times were significantly less with the longest being 5 seconds with 8.6, the shortest 6.1 with 1 second, and the average being 3 seconds. It should be noted that 8.6 had DSC and FPGA toolkits installed, all other versions don't have any. Also no options on the startup procedure was changed on any of these versions. And my PC is a laptop with 2 GB of ram, a Core2Duo at 2.2 GHz and a SSD. I assume the SSD is what makes the startup time relativly quick. For the heck of it I also decided to run all versions of LabVIEW at once, and it took 12 seconds to load all of them, after starting them once already I'll reboot and try a fresh start of all of them at once later today.

Yeah that windows character size limitation is a bugger. We hit it several times when dealing with SVN. If you do a checkout in your my documents then it starts out a C:\documents and settings\[user name which may be long]\[user name which may be long]'s documents\ That eats a large chunk of the possible 255 characters. Then if you have a long path in the SVN it will become a problem. It can also become a problem with VIPM if you are building a project with a long package name, and have long file names in the VI. Once all the VIs are saved they are put into a LLB so as long as the package is built there shouldn't be a problem with the package being installed on another machine. I am very glad to see that LabVIEW now has a more useful error message. Previously LabVIEW would return a General I/O error. To avoid this problem I would say use the advanced build option of Use 8.x layout. It will build the EXE in a flat structure like in previous versions of LabVIEW.

(raises hand) Pick me! I know this one. As luck would have it I already made a clock program when I was first learning about how to use LabVIEW and its draw features. Here's a clock that works with the OS time, or user specified time. http://brian-hoover....k%20Program.zip I do have a disclaimer. I made this code several years ago and while it works, there are several coding advancements that I did not know about and did not use. First I would have created a state machine, and an event structure instead of polling every 200ms. In any case hope this works for you, here's a screen shot. EDIT: I'm sorry I didn't read the post closely enough, what I provided is not what you are looking for, but it still may be useful.

I may be wrong about this, but I don't believe that there are 32-bit VIs and 64-bit VIs. The only thing that changes is the LabVIEW compile is optimized to use 64 bit. Someone correct me if I'm wrong I've never used 64-bit 2009 with 64-bit Vista.

Nope I'm not an architect, maybe I should've had a V8. Does anyone else thing it's odd the first result in google was yahoo answers for this?

New? I'm sure you know this isn't exactly a new feature. Before the project explorer you could go to Tools >> Build Executable. Then in 8.0, and 8.2 you could still go to Tools >> Build Executable but it would make a quick project and build the EXE for you. 8.5 and 8.6 require you to make your own project to build an EXE for it. I don't believe that any software should remove features between versions unless there is some really go reason to do so. Removing the ability to quickly build an EXE was a poor choice and I'm glad they brought it back.

I'm pretty sure crelf was being facetious. There is a rumor that on more than one occasion our IT guy has throttled crelfs network because of torrents. I'm sure he was just downloading some large linux distro, and not any copyright protected video content.

Do you mean if any VI in the project doesn't have a front panel or the top level VI? Either one I would consider a bug, but one more severe than the other.

As weird as it sounds I really liked that video. One of my co-workers was watching it and showed everyone that was around because it looked so cool. My only worry would be that people would be more interested in the zooming and effects than the actual content of the video. If you don't mind me asking what did you use to edit that video?

Yeah that works but it has the same flaw that mine had where things don't work right if the 2nd array has more rows than the 1st, but it is an improvement over my code.

Yeah I remember running sequences in TestStand in my sleep. The dream didn't end well, the code still didn't work. That was one of those 85 hour work weeks (in 6 days) I had alot of odd dreams.

There's always many different ways to skin a cat. So here's one option I did which doesn't use any transpose array functions (since I was under the impression that it was bad on memory usage) I just realized that this doesn't work in all use cases. If Array 2 has more rows than Array 1 then the output will not be exactly what you want, I guess the code could be modified to work properly. It's not often I need to concatenate horizontally but I wouldn't mind having it be a feature.

Thanks you Crelf for helping me offline. I've attached the newer rev. of my WinWaitActive code. It is now considerably small too (not needing an autoit3 exe). It has the same functionality as described in my first post. WinWaitActive.zip

Hello all, so I've created a VI which waits for a window to become active before going on. This is useful for when you are trying to automate something. Have LabVIEW run a exe then wait for its window to become active, then continue with keyboard presses and mouse clicks. I would submit my code to the Code Repository, except for a few things. First it's not clean enough. But more importantly it uses an AutoIt executable. I've embedded the EXE into the VI so to the user the code is seamless, but I was wondering if I could get rid of the EXE by using standard windows DLL calls. The stumbling block is I don't know how to get the title of the active window. I know that using GetActiveWindow from the user32.dll I can get the HWND for the active window, but I don't know how to get the title of that window. GetWindowText only returns the size of the string of the title. Attached is what I have so far, along with the AutoIt code. Any suggestions?

Very impressive, not sure if you've thought of this before, but with this you could possibly be able to create our own open source VI file format. Pass in a VI into a program and get the SWF equivalent. Then take the SWF put it in another program and get the VI back. Of course there's alot of issues associated with that, like subVIs. But for basic stuff I think it could utilize the quick drop function to find code.

Not that I know of, that's how I would have done it.

When I took microcontrollers 1 and 2, I remember the professor telling us over and over again never to modify your own code while the program was running. By this I mean you have a set of instructions that start at 0x1000, and as the program ran you shouldn't use any thing from 0x1000 to the end of your program, as temporary memory space. I always thought he told us not to do that because you would be changing how the program would operate after the first run, but now I realize he didn't want us creating code, that could become self aware.

I like this idea. I think we could do some testing with a small subset of rules. Say you must start with 2 booleans, and a numeric indicator. Then have it randomly write code, dropping primitives and wiring them up, until the state of the 2 booleans gives you the numeric results you want. To make it easy you could say OFF OFF = 0, OFF ON = 1, ON OFF = 2, ON ON =3. Now having intelect we know the easiest (or at least an easy) way to write a VI that does this, but for it to do it randomly would be interesting. How long would it take? How big would it be? Then you could try the survival of the fittest idea, where the smallest fastest VI that performs the task properly, is the one that gets modifed to do a similar task. Maybe add a 3rd boolean. But even this simple task may take a very long time for a successful VI to be created. I imagine alot of system resources too. It would be nice maybe to have an indicator saying how many VIs were able to get OFF OFF = 0...now that I think about it maybe one boolean is a better start.

File Name: Windows Environment Variable Reader Writer File Submitter: LAVA 1.0 Content File Submitted: 02 Jul 2009 File Category: General LabVIEW Version: 8.2 File Version: 1.0.0 License Type: GNU Public Potentially make this file available on the VI Package Network?: Undecided Windows Environment Variable Reader Writer Vc Copyright © 2006, Brian Hoover All rights reserved. Author: Brian Hoover **see email address in readme txt** Description:: Purpose: This Vi was made so that you can easily view and create environment variables from within Windows XP. Features: You are able to read all environment variables which you have available to you at the command prompt by typing "set". It also can write environment variables by writing them to the registry in the following location: HKEY_CURRENT_USER\Environment Also for added safty it will check the name you are trying to use, and won't allow its creation if a variable with that name already exists. Usage: To use this VI you need to be using Labview version 8.20. With Labview 8.20 installed open the VariableReadWrite.vi file, then click run. While it's running open the View Variables tab and click "Refresh Variables" to view all your command prompt variables. Two String arrays are created, the Name of the variables, and their values. A text window is also displaying what the user would see if they typed "set" at a command prompt. To create a variable open the Create Variables tab and fill in the information for Variable Name and Variable Value; then click Create Variable. Please note that you may need to log off then back on for the new variable to take effect. If needed there is a "Run Regedit" button which will open the registry. From here you can see the newly created variables in the location mentioned in the Features section. When you are done click stop to end the program. Version History: 1.0.0: Initial release of the code. Click here to download this file