UAC elevation dialog minimized
Our application launches a separate executable that requires elevation. Everything works fine except that the UAC elevation dialog always comes up minimized, blinking in the taskbar (users tend to miss the blinking taskbar and think the operation failed).
I believe this is a problem with Vista, as I have seen the same behavior in the Windows Explorer (Computer) when right-clicking on a hard drive and selecting "Format...".
Is there a way to force this UAC dialog to gain focus immediately? Or is this a bug that will be fixed in future Vista builds? Running Vista build 5472
[708 byte] By [
fergar] at [2007-12-22]
You should check that you have specified a handle of your window in the hwnd parameter for ShellExecute/ShellExecuteEx function.
Hi Michael,
Thanks. It seems you hit the nail on the head. Nice and simple.
Hey Fergar,
How did you make the Elevation dialog come up in the first place? Does shellexecte automatically brings that up?
or do we have to do something special?
use ShellExecuteEx() and to specify the parameter ‘runas’ in the SHELLEXECUTEINFO structure member lpverb.
SHELLEXECUTEINFO sei;
sei.lpVerb = L”runas”;
Hey Fergar, Thanks for the post, am having the same issue and the problem is i need to specify the handle as NULL, what can i do about it, i just need to execute an exe file but the prompt minimizes.
thanks
Rahul
Using a NULL handle has that side effect. I don't know how you'll be able to get focus on your exe without passing the handle. This so-called "feature" is already absolutely ridiculous:
1. The hwnd should not have anything to do with whether the dialog comes up minimized - that should be based on whether the current thread generally has the global focus, i.e. whether any new window it opened would become the globally foreground window or not.
2. The minimized dialog is quite inconspicous. Most non-expert users will miss it, and the ShellExecute will wind up failing after a timeout.
3. It is unreasonable to demand that a non-NULL hwnd be passed, since in many cases it is not so easy to obtain an appropriate window's hwnd.
4. Many existing applications use ShellExecute with a NULL hwnd. Thus, application compatibility is compromised.
But it gets worse. Being a good boy, I changed my code to pass the hwnd of some window belonging to the thread. In one case, an ordinary exe, this worked - the elevation dialog came up in the foreground. But in another case, in an ActiveX dll loaded into the browser, this did not help. I got the hwnd of the browser window just fine (by getting the IServiceProvider, then doing QueryService for an IWebBrowser2, and then getting its HWND property; I know that this worked because I logged the value I got - it was indeed the browser's hwnd), but the elevation dialog still came up minimized. I tried turning off protected mode, using the hwnd returned by GetDesktopWindow, passing the hwnd of some other process, using ShellExecuteEx, all with the same results. I simply can not get the elevation dialog to come up in the foreground from my ActiveX dll in the browser. This is a major problem for me, since one of the methods exposed by my object requires admin privileges. Help!
There's one key here though, as this page mentions:
http://blogs.msdn.com/uac/
"UAC prompts will not “steal focus” from the user’s task. If the operating system cannot determine that the prompt was generated from the foreground window the current user is using, we will alert the user with a highlighted operation in the taskbar that an application is requesting elevated privileges. The user can select to elevate at his or her convenience and not be disrupted by an unplanned application elevation."
So instead of calling GetDesktopWindow() to get the HWND or passing the HWND of some other process, pass it the HWND returned from GetForegroundWindow().
-Kevin
There are several issues here.
1. GetForegroundWindow is indeed an interesting approach. I have not tried it, and am a little worried that it might return NULL for no good reason, but it might work very nicely as a way to "obtain an appropriate window's hwnd".
2. In Vista RC1, the ShellExecute bug (whatever it was) that caused the elevation dialog to be minimized when passed the HWND of an the active browser window (see above) appears to have been fixed. My ActiveX now works properly.
3. I still think that ShellExecute should be able to decide whether the elevation dialog should be minimized or not on the basis of the identity of the thread calling it, not on the HWND. If SetForegroundWindow can do it without taking a second, "validation" HWND parameter, why not ShellExecute? As I said, this would improve compatibility with existing apps.
