I have an issue where the Windows 8 User Account Control (UAC) popup is minimized when I execute a command line helper program that requests admin privileges in its manifest. The UAC popup window just blinks yellow in the Windows taskbar, causing a confusing user experience:
After clicking the taskbar icon, then the UAC alert shows:
In Windows 7, the UAC alert is not minimized but shows in the foreground. Any thoughts on how to fix this in Windows 8?
For reference, my main application runs under user privilege and executes the helper program with ShellExecuteEx. I am setting ShellExecuteEx's TShellExecuteInfo.nShow to SW_SHOW.
MSDN says ".. you must pass a parent HWND with a ShellExecute .." and explains,
The UAC elevation mechanism uses the HWND as part of determining
whether the elevation is a background or foreground elevation. If the
application is determined to be a background application, the
elevation is placed on the taskbar as a blinking button. ..
Be sure to supply your foreground window's handle to ShellExecuteEx.
Related
I build a fullscreen GUI application for Windows (using LabVIEW but the language should not matter much) that should start with Windows.
I want it to be fullscreen (hiding the Windows taskbar), so I set the window bounds to the screen's resolution.
When I manually launch the exe from explorer, the window hides correctly the taskbar.
But when I launch it from a scheduled task at Windows logon, it is behind the taskbar, until I click on the application. Same thing when I run the scheduled task manuallay in the task scheduler.
I tried the Win32 API function SetForegroundWindow but without success. Maybe the conditions are not met but I do not understand why, there is no other visible window.
How could I force the fullscreen of the app when it auto-starts?
If this is impossible from the application itself, an external solution to the application's code might be ok (e.g. some script running with the scheduled task), but I don't see one either.
Hey so I was having the same trouble when I scheduled a full screen application to run at login. the way I got around this was by creating a mouse click macro and scheduling it at user login with the app (had to set a 10 second delay to allow for the app to load).
It's a bit dodgy but it got it done for me
I have VSTO addins for Office (Excel / Word / Outlook) 2007 / 2010. Through the use of the NativeWindow the office programs listen for Hotkeys. Upon hotkey recognition a message (WinApi SendMessage) is sent to my own application which then uses the SetForegroundWindow SetForegroundWindow(Hwnd) function to bring Internet Explorer to the front. This works fairly well on most occasions but sometimes it does not. When it does not work the office application is left in front and the Internet Explorer icon is flashing in the task bar.
I am aware that this is by design from Microsoft for the SetForegroundWindow function to stop malicious code.
I do not know exactly why it works sometimes and not others but think it is because the user is using the keyboard to enter the hotkeys and thus the Office application does not want to give up this focus.
My first thought was to simply minimize the Office program but I do not want to do this as some people have multiple screens with Internet Explorer on one and the office application on the other.
When my VSTO addin receives the hotkey signal I would like the office application to relinquish being the foreground or active window, but I do not want it to be minimized.
I know the last paragraph might not be a correct question so maybe more generally as the VSTO addin is working with the Office application process what can I do here so that a call to SetForegroundWindow will work.
Edit: To be clear the only code I am using so far is SetForegroundWindow(Hwnd) where the Hwnd is that of Internet Explorer. As the conditions are now posted I am interested in creating the condition "There is no foreground process"
From the documentation:
A process can set the foreground window only if one of the following conditions is true:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The process is being debugged.
The foreground process is not a Modern Application or the Start Screen.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
No menus are active.
An application cannot force a window to the foreground while the user is working with another window. Instead, Windows flashes the taskbar button of the window to notify the user. [Emphasis Mine]
How do you know if you successfully set the foreground window?
If the window was brought to the foreground, the return value is nonzero.
If the window was not brought to the foreground, the return value is zero.
Without any code to go on, there's no way to know which is causing the problem.
My Goal is to have a kiosk application on Windows that is launched in fullscreen and that user cannot escape. To do that, I replaced explorer.exe by my_fullscreen_app.exe under Configuration\Administrative Templates\System\Custom user interface.
Everything works well, but when user press ctrl+alt+supp and then cancel, the screen becomes black. When I look at the task manager, my_fullscreen_app.exe is processed but not displayed anymore.
How to avoid this problem without disabling ctrl+alt+del ?
When I run the following script via CMD.EXE the display of Word is normal i.e. Maximized.
Set oWord = CreateObject("Word.Application")
oWord.Visible = True
oWord.Documents.open(sTempWordFile)
oWord.Run WScript.Arguments.item(0)
oWord.Activate
When I call the same script as Target in a shortcut .LNK file the display is always minimized!
The .LNK file target is: "%OWNERS_CORP_ROOT%\cmd\RunWord.vbs" memos
Using Windows 8.1, Office 2013. Shortcut .LNK file is set to Run 'Maximized'.
How do I make a 'Maximized' display when using the shortcut?
SetForegroundWindow Function
The SetForegroundWindow function puts the thread that created the specified window into the foreground and activates the window. Keyboard input is directed to the window, and various visual cues are changed for the user. The system assigns a slightly higher priority to the thread that created the foreground window than it does to other threads.
Syntax
BOOL SetForegroundWindow( HWND hWnd
);
Parameters
hWnd
[in] Handle to the window that should be activated and brought to the foreground.
Return Value
If the window was brought to the foreground, the return value is nonzero.
If the window was not brought to the foreground, the return value is zero.
Remarks
Windows 98/Me: The system restricts which processes can set the foreground window. A process can set the foreground window only if one of the following conditions is true:
The process is the foreground process.
The process was started by the foreground process.
The process received the last input event.
There is no foreground process.
The foreground process is being debugged.
The foreground is not locked (see LockSetForegroundWindow).
The foreground lock time-out has expired (see SPI_GETFOREGROUNDLOCKTIMEOUT in SystemParametersInfo).
Windows 2000/XP: No menus are active.
With this change, an application cannot force a window to the foreground while the user is working with another window. Instead, Foreground and Background Windows will activate the window (see SetActiveWindow) and call the function to notify the user. However, on Microsoft Windows 98 and Windows Millennium Edition (Windows Me), if a nonforeground thread calls SetForegroundWindow and passes the handle of a window that was not created by the calling thread, the window is not flashed on the taskbar. To have SetForegroundWindow behave the same as it did on Windows 95 and Microsoft Windows NT 4.0, change the foreground lock timeout value when the application is installed. This can be done from the setup or installation application with the following function call:
SystemParametersInfo(SPI_SETFOREGROUNDLOCKTIMEOUT, 0, (LPVOID)0, SPIF_SENDWININICHANGE | SPIF_UPDATEINIFILE);
This method allows SetForegroundWindow on Windows 98/Windows Me and Windows 2000/Windows XP to behave the same as Windows 95 and Windows NT 4.0, respectively, for all applications. The setup application should warn the user that this is being done so that the user isn't surprised by the changed behavior. On Windows Windows 2000 and Windows XP, the call fails unless the calling thread can change the foreground window, so this must be called from a setup or patch application. For more information, see Foreground and Background Windows.
A process that can set the foreground window can enable another process to set the foreground window by calling the AllowSetForegroundWindow function. The process specified by dwProcessId loses the ability to set the foreground window the next time the user generates input, unless the input is directed at that process, or the next time a process calls AllowSetForegroundWindow, unless that process is specified.
The foreground process can disable calls to SetForegroundWindow by calling the LockSetForegroundWindow function.
Function Information
Minimum DLL Version user32.dll
Header Declared in Winuser.h, include Windows.h
Import library User32.lib
Minimum operating systems Windows 95, Windows NT 3.1
Unicode Implemented as Unicode version.
See Also
Windows Overview, AllowSetForegroundWindow, FlashWindowEx, GetForegroundWindow, LockSetForegroundWindow, SetActiveWindow
I have an application that manages patient demographic information. Along with this data a user can scan a picture of a patient and assign that picture to a patient. When the user clicks the scan button a separate application is opened as a dialog in order to scan the image. When running this on XP everything worked fine. The imaging application loaded up fine and gained focus. On Vista however occasionally the imaging application will not gain focus and will popup behind the main application. When running full screen or through 2008 Application Server you cannot see the application, you only get a locked screen and it appears nothing has happened. Is there any way to change the window focus management on Vista to work the way XP did? I'm looking for a way to solve this without making changes to the actual application if possible.
I think you will have to make changes to your application to allow the imaging application to take the focus. I'm going to assume that your application launches the imaging application through ShellExecute or CreateProcess. If so, you can get the process handle of the launched process either through SHELLEXECUTEINFO.hProcess (for ShellExecute) or PROCESS_INFORMATION.hProcess (for CreateProcess). Immediately after launching the imaging application call the AllowSetForegroundWindow API:
AllowSetForegroundWindow(GetProcessId(hProcess));
This will allow the imaging application to place its main window/dialog in the foreground when it's starting up.
You could try the following steps:
1. Right Click on the exe
2. Select Properties
3. Select the Compatibility Tab
4. Check the Run this program in campatibility mode for:
5. Select Windows XP (Service Pack 2)
You could iterate through all top level HWNDs and identify the scanning application via its window class, then send an appropriate message to raise the window.
I don't believe this is Vista vs XP related. I think that simply this imaging app takes longer to start on Vista.
Since Windows 2000, the window manager has prevented background applications stealing the foreground. When an application is launched, it has a window of opportunity to create and show a window that will take the foreground. If it takes too long, the window manager thinks that the current window should keep the foreground, and inhibits the other app taking the foreground when it does finally launch.
I can't think of any specific way to avoid this... other than using FindWindow to search for the other apps window after launching the app. When you eventually find it, call SetForegroundWindow on it to bring it to the foreground.