Leaderboard

The UAC in Vista and later is designed to prevent even administrator accounts from doing "dangerous" things without user confirmation. Running as Administrator alone is not sufficient to avoid the prompt as Microsoft has tried very hard to ensure that the prompts cannot be worked around. (This is so that virus authors can't go that route.) The "right" way to handle this is to ship a manifest that tells Windows that an application needs elevation. It will ask for it on launch. If there is no manifest, Windows tries to figure out which applications require elevation (for example, an installer named "setup.exe") and request elevation from the user on launch. It is very frequently wrong and this results in cascade of errors later on. I agree with you that disabling UAC entirely on a machine is the wrong approach. I'm no fan of UAC, but it is the world Microsoft wants us to live in. None of them really get rid of the UAC prompt, they just get the user's permission at some more convenient point in the launch process. (I realize not all of these apply to your situation:) Number one recommendation: avoid tasks that Microsoft considers "dangerous". Sometimes elevation is unavoidable but other times it is the result of using deprecated Windows programming techniques like writing a config file to the %ProgramFiles% directory. In these cases I recommend capitulation to the Borg; if Microsoft wants you to write to %AllUserProfile% instead of %ProgramFiles%, just give in and change it. I recommend testing the application in a regular (non-Administrative) user to see where the problems are. If you just want to do a simple SysExec call and you don't mind getting the prompt (i.e. it needs to work, but it doesn't need to work unattended), you can use John Robbins' elevate.exe to run the command (sc start or whatever) with elevation. We use elevate.exe in our installer batch file; the user clicks through one UAC prompt which elevates the batch file that runs multiple installers. (Johannes Passing wrote a version of elevate.exe in regular C; I haven't tried it.) Run your application as a service. Microsoft believes that applications that run unattended should be services. A service running in a privileged account (i.e. LocalSystem) can perform tasks that require elevation without any dialog boxes. The thought here is that since UAC elevation is required to install the service no further prompts are needed. This is how our production application runs. We use FireDaemon to do this and it is quite easy to convert your LV app to a service this way. (There is also the free "srvany.exe" application from Microsoft floating around.) There are other advantages to running as a service, such as automatic restarts when the application quits or crashes. There is, unfortunately, a winkle running an app as a service under Windows 7: starting with Vista, Microsoft no longer allows services to have user interfaces. (This is another security "feature".) Thus to go this route you will have split the functional part of your application from your UI. It's quite doable (especially if you use the VI Server) but if your application has a lot of UI this might be an untenable amount of work. I suppose you could go the other way and have a lightweight helper service that performs just a few tasks that require elevation under the command of your main app. That would be pretty easy. Have your application request elevation on startup. This is the method Microsoft wants you to take. (Well, not really: they want you to have buttons all over the place with little shield logos that only request elevation on the specific tasks that really require elevation.) You can request elevation by embedding a manifest in the application. This is supported by the LV Application Builder, although documentation is extremely sparse. See this PowerPoint presentation on how to construct the manifest. While you are at it, digitally signing the application will avoid another bunch of UAC warnings on installation and launch. You can use self-signed certificate or a "real" certificate backed up by Verisign etc. "Real" certificates cost money but provide traceability. Signing your code shows that your application hasn't been modified since your released it. While we are talking Windows 7, keep in mind that the Program Files directory is now called Program Files (x86) when 32-bit LV is running on a 64-bit versions of windows. So make sure to clean out those hard-coded paths! -Rob

You gotta admit that Norm's kinda cute...

...and some of the men

Hi Since I have almost all my VIs in classes in my app, so when I want to dynamically run a VI (method), I use the Open VI ref using the string name instead of path: "MyClass.lvclass:MyDynamicVI.vi" and as long as I use any VI on this class the whole class will be loaded in memory by LabVIEW and it works without me knowing the absolute path. //Mikael

I can see the problems you're having, but I am slightly unclear on exactly what your goal is, so I'll lay out a couple of options and hope one of them helps. You have some VIs that you want to invoke dynamically. 1) If you're trying to get those VIs to load into memory at the same time as your top-level VI, what you want is a "static VI reference". [Note: "static VI reference" and "strict VI reference" are not the same thing, and, yes, it is possible to have a "strict static VI reference".] It's in the Application palette. This creates a reference to a subVI but does not invoke the subVI. You can then use the reference that comes out of that node and wire it to either the Call By Reference node or the Run VI method. If you *know* that you're going to want to run these VIs as part of your app but you just need to choose among them dynamically as the app runs, you will find it is most efficient to make these static VI references be "strict" by popping up on them and choosing "Strictly Typed VI Reference". That causes the subVI to be reserved for run when the top level VI starts running, the same way all the usual subVIs get reserved. Not doing this means that the subVIs will be reserved before every run and unreserved when the run finishes. Being strict also means that you cannot use the "Run VI" method. Being strict means that the VIs are set up to run as subVIs of another app. The Run VI method executes a VI as a top-level VI. 2) The objection you might have to item #1 is that the subVIs will all load into memory. If you truly want to dynamically load these VIs into memory then you have to use Open VI Reference and supply a path. The easiest way is to put all of your dynamic subVIs in the same directory as the caller VI and then use "This VI's Path" node to get the path of the caller VI, then do "Strip Path" and "Build Path" to replace the file name of the caller VI with the file name of the desired dynamic subVI. From there you can again use Call By Reference or Run VI. Again, if you wire a conpane to the Open VI Reference node, the resulting reference is a strict VI reference which means you have to use Call By Reference to invoke it.

Phillip Brooks (NI) == Phillip Brooks (LAVA) (Used to be LV_Punk on LAVA. A play on the wrestler CM Punk; real name Phil Brooks) And yes, I'm still global free, sequence structure free and BETTER THAN YOU!

normandinf (NI) = François Normandin (LAVA)

I don't post much to NI Forums, but I'm grubin698

dblk22vball = Kenny K NI

When I'm not Ton Plomp, I'm TCPlomp NI Forum / NI Community. Ton