hooovahh

That's why I said "I don't believe any version of LabVIEW...." I can never be completely certain that a feature isn't in LabVIEW.

I don't believe any version of LabVIEW's development environment has user management or logins. Can you show a screenshot of the dialog you are seeing?

I'm sure you're probably aware of this, but what I've done in the past is use the Mouse Up event on the control, and then check to see if the ROI has changed from what it was previously. Still nothing wrong with catching this event.

One thing I noticed is that when running LabVIEW as the shell, the Aero theme doesn't load (I'm guessing that is a service started by Explorer). So if you develop with Aero turned on, then deploy where it is off, many fonts will be wrong. And it is likely your controls in the windows won't line up right. My fix was to let Explorer start (starting Aero) then kill it with my LabVIEW application. This also will kill any shortcuts like Win + E, Win + D. I never tried but it is likely you could just start the right theme service and have it work properly but I never tried that. EDIT: I also found that command to allow operators in the Users group, access to write files.

If I had to guess I would say this is a behavior of the operating system. I say that because I cannot seem to find a instance, where a single application, that has more than one window, will behave differently than the one we experience with LabVIEW where all other windows are brought up. (I did a quick test with Microsoft Word and IE) Well there are windows DLL calls that allow you to manipulate window Z-order. So one could certainly modify the order of all your applications' windows manually. I don't think I've ever had a case, where my application would have multiple windows, in the same application instance, and want to the operator to see one, without bringing the others in front of all other applications. I guess I just don't know your use situation well enough.

So that means that an operator can simply navigate to the built application and delete the EXE. Now I realize if an operator does this that it would probably be considered malicious behavior. In my opinion giving a user, who likely doesn't fully understand the system, the ability to break a test system so easily is a very big deal. But then again I don't know the type of environment that the system is in, and this may be a fine setup.

This is not the case at all. I can't seem to find the stupid batch file I created, but it would run an installer (with some silent switches) then run the command line program Icacls (built into Windows 7) to allow the INI file that got installed to be written by anyone in the Users local group. This batch file of course would need to be ran by someone with elevated privileges the first time. But then again only someone with those privileges should be installing updates anyway. Then the application (stored in the Program Files) could modify the INI file that was in the same folder as the EXE, even when the logged in user only had limited rights. This also only modifies the security of the INI file, the directory it self still cannot be modified by someone in the Users group.

Just a thought (and probably not a good one) but what if you install to program files like always, and have the ini file in program files along side the EXE, but then during the install run function that will set the privileges of the INI to be written by any level user? The EXE doesn't need to have elevated privlages, the file can just have lower ones. I know there is a Windows command line function to set file permissions but I can't seem to find it at the moment. One downside is the file isn't as hidden as other places, but it also feels like a patch when it sounds like the proper way would be to store the data in ProgramData.

I was curious so I wrote a quick VI to see how fast I could get a loop to run that performs some calculation. Now this is a very simple VI that doesn't call a subVI (so no overhead there). But I wanted to see how fast I could get a loop to run. Please pardon my crude code, but on my machine running 100,000,000 loops, each loop takes about 42 nano seconds to execute. Much faster than I would have expected, but again there isn't really much going on. As soon as you add any communication VIs, loop rate will increase. EDIT: I removed everything in the loop and the loop now runs at less than 2 nano seconds...but again what good is a loop that doesn't do anything? Other than a dwell I guess, which won't be very consistent.

I believe this is an issue with the ActiveX control it self. You have similar issues when you put ActiveX controls like this into tabs. It works just fine, but changing between tabs you'll see a flicker of the ActiveX control on top of the tab, and then moved back into the tab. I don't know of a work around. For the tab it's annoying but doesn't change functionality. For your application it sounds like more of a show stopper.

Or in Windows 7 press [Windows Key] + [P], and choose Extend. This is normally used for projectors to clone or span.

gb119 you have more patience than me. Copied from the LabVIEW help.

Couple things. Your processor maybe running at the GHz but that is if you are only running one instruction. There is tons of overhead when running in windows when compared to a microcontroller. I would say I could do many operations on a 4MHz micro faster than on a 4GHz windows machine, and more reliably. Which is why when I need determinism, and high speed I move to FPGAs or RT environments. Windows is not deterministic, and should not be used for an application that needs to maintain timing less than 1 ms. What if the antivirus application decides to run a scan and slow down the PC? Or if Windows update decides to install a bunch of crap during a very sensitive time? There are many cases where Windows will not be able to maintain timing and will fail. You can run a VI that has a loop rate less than 1ms. But the overhead associated with measuring that applications rate, will effect your timing and then may run slower. Quantum Mechanics is not my thing but measuring something can effect it so that the measurement is not accurate. Also your loop may run faster than 1ms some times, but again with Windows it may take more than 1ms the next time. There was some code posted on NI's forums that I can't seem to find right now that would calculate the number of clock cycles a VI takes to operator, and then using the CPU frequency would calculate the time it took. But keep in mind that doing these operations takes clock cycles and makes your numbers less accurate. Also if you are trying to do something quick try to remove all of the extra steps that maybe in your way, like queues. There have been times where I had a nice wrapper written with queues or user events, but when I needed to do something fast, it was better to just do it in one VI than it was to pass data around to other VIs.

This doesn't look the right kind of error for this, but be sure and disconnect the communication with HyperTerminal before trying to open the port in LabVIEW. If you run both at the same time LabVIEW will not be able to get a lock on the port because another application is using it.

...I think you'll fit in just fine around here.

Your IT guy was wrong. If Windows Device Manager sees a serial port, its because there is a serial port. This may not be a normal serial port that is exposed to the outside world via a DB-9 but an internal one for diagnostic support. I've seen several PCs have internal serial ports that allows for for intimate access to the PC, or it is possibly a serial port that is only accessible through a dock that the laptop is connected to. In any case it is not going to be a serial port that is going to be available for communicating with other hardware and investing in a USB-to-RS-232 is going to be a good idea. I've heard some cheap ones don't work with all hardware, but I haven't found any hardware my no name cheapo couldn't talk to yet.

So alot of people have their opinions (several in this office) but I use UltraMon to manage multiple monitors. It adds a second task bar to the other monitor, and it can be configured to only show windows on the taskbar that are on that monitor. Additionally I use the Hotkey (setup in UltraMon) to allow the CTRL + Space to move the window to the next monitor. Keep in mind this replaces the quick drop feature in LabVIEW which I don't use. If I need to find something I use search. My left hand is almost always on the home keys, and so hitting this set of keys is a quick way to organize Block Diagrams on one window, and Front panels on the other. I can also use this technique to open two projects and have one on each monitor. UltraMon also adds other not as useful features, like multiple desktop images, monitor cloning (built into Windows 7 now), multiple screen saves, and a few other things I don't use. There are other free alternatives that I hear work just as well. EDIT: Sorry I didn't fully read your post. If you want code to span both monitors, UltraMon can add a Maximize to Desktop button. This button appears next to the minimize button of all windows, and when pressed will maximize over all desktops. I don't recommend coding this way. It is useful in Excel, where you open two workbooks and what to view one on each monitor, so you maximize the master window then position the two workbooks independently.

I think if there was an unofficial patch put out, it would need alot of customization, on allowing the user to select things that it modifies. Because some people may want their VI.lib replaced, and some may not even want the Riffle function replaced. EDIT: Nevermind read his post wrong.

I think there was a T-Shirt that said something like This seems relevant.

I was expecting some neat little nugget from the VI.lib. Instead I found out that Eric needs to update one of his general VIs.

Wait...EVERYTHING...something tells me they should call them something other than "private message". I know we've had some sales guys that will use some features of the website to see what hardware they would want. Using it to recommend hardware and a chassis and make a shopping cart just for a quote. NI has then called our sales guy and tried closing the deal, not knowing it was for a quote. All they see is a shopping cart filing up with tons of stuff, and then nothing.

I just did a test and that is exactly how it works. I did not know that feature either. Normally I would use the OpenG VI "Current VI's Parent Directory" which will keep going up a folder until it finds a real folder (not a directory in the built EXE).

Now if only you could hide it at runtime, or make it 0 pixels in size.

Well my methods may be disgusting but at least spaghetti_developer agrees with my methods...on second thought I'm not sure how I feel about that. In all honesty my method probably has more maintenance, and is probably less obvious to another developer, but choose which you prefer.

UAC is one of those things I turn down right away on my own machines. I think Microsoft knew it would be something people would want to turn off right away because it is in the "Getting Started ->" which shows up in the start menu after a fresh install.