In Windows 8 Win Store apps started by default in full screen mode.
In Windows 10 Desktop Mode apps starts in windowed mode, and app title bar has additional icon, which allows to switch to full screen mode (first icon, note that it's different behavior than maximizing window, third icon).
Is there a possibility to maximize this window programatically, e.g. via WinAPI call? Alternatively, is there any option (other than switching to Tablet Mode) to start it in full screen by default?
Question is not about changing app sources, I want to switch running app to full screen as a part of automated testing process.
Yes you can try to make the app runs in full screen by:
ApplicationView.GetForCurrentView().TryEnterFullScreenMode();
And try to play and check the methods available in ApplicationView.GetForCurrentView().. You'll love it :)
Related
Background
We are building a cross-platform application with "popup" reminders, they are custom windows/dialogs which uses QWidget.setWindowFlags like this:
self.setWindowFlags(
QtCore.Qt.Dialog
| QtCore.Qt.WindowStaysOnTopHint
| QtCore.Qt.FramelessWindowHint
)
These popups show up on the systems we have tested (MacOS, Lubuntu (LXDE)), even when we switch between different virtual desktops the dialogs are still shown in the current desktop. However:
Problem
When the user is in fullscreen mode on MacOS (Sierra 10.12.6) the dialog instead is shown in the last virtual desktop that was used
Question
How can we show our "popup" dialogs to the user even when the user is in fullscreen mode on MacOS?
The short answer is that you can't and neither can any other app.
Here's why.
The idea is that when you select the fullscreen view for an app, you want to focus exclusively on that app, to the exclusion of all others. So the app not only expands to fill the entire screen, it removes the menu bar and creates its own desktop space.
You can see how this works using Mission Control (by default, swipe up with 3 fingers). You will see all the apps and all the desktops across all your monitors. Next, set an app to full screen and swipe up again. You'll see that the app has a dedicated desktop (which I believe doesn't even have wallpaper).
The bottom line is that macOS fullscreen view does not support pop-ups.
I need to do a pre-purchase evaluation of a Flash application that is intended for a touch screen.
Since I still don't have the touchscreen now, I need to run the application on my desktop computer and the application is unusable without a visible cursor.
I am using Windows.
Is there a way to unhide the cursor without asking the developers to change the application?
I've previously used remote access software (such as Windows Remote Desktop or TeamViewer) for this purpose. Another option is a virtual machine - in both cases you'll be able to see the cursor on the local/host machine.
If you happen to be on a Windows 8 machine, you might give a try to the Windows Simulator (http://blogs.msdn.com/b/visualstudio/archive/2011/09/29/first-look-at-windows-simulator.aspx, available for free with Visual Studio Express) that additionally simulates multitouch gestures such as pinch/rotate with only a mouse.
A few other ideas:
1) You can try using the "Show location of pointer when I press the CTRL key" mouse visibility property (Control Panel - Hardware and Sound - Devices and Printers - Mouse - Pointer options). Although not entirely convenient, it might help you if the application doesn't require quick response times.
2) If the application is distributed as a .swf file and the right button hasn't been disabled, sometimes right-clicking (anywhere in the application) to bring up the context menu will cause the cursor to show up and remain visible.
On Windows 8 they've replaced the Start Menu with a Start Screen using Metro GUI.
Desktop applications can be run from this screen, but when they exit the user is left at the desktop.
Is there a Windows setting that will return to the Start Screen automatically when the application is closed, if it was launched from Metro?
Or is there an API available so that the application itself can detect whether it was launched from Metro and then switch back to it as it is shutting down?
(I want something automatic or programmatic. "Press the Windows key" is not an acceptable solution.)
Window 8 metro GUI is working like Start menu so I will change my application's setup program to put some command line options for desktop menu shortcut and pick it up from Param array.
When closing I would try sending Windows button combination (Ctrl+Esc) to windows. Actual code to do that depends on the language used to develop your app. If developed in .Net following class can be helpful
System.Windows.Forms.SendKey.Send
http://msdn.microsoft.com/en-us/library/system.windows.forms.sendkeys.send.aspx
following library may also be useful
http://inputsimulator.codeplex.com/
My application is causing the following strange behavior on Windows 8:
Conditions:
My native WinAPI application is started automatically upon Windows 8 startup.
Windows remains at the Start screen immediately upon startup.
When my application creates a window, Windows switches to desktop away from the Start screen. The window created is toolbar window, it does not steal the user focus, used as status display.
This only happens when the window is being created not immediately after the startup, but some seconds later.
My question: How can I prevent Windows switching to desktop when my window appears?
Well, you can manage start up applications. Turn it off for your application. And it should work.
I have a hidden process that waits for non-standard hardware button messages and runs an application (with CreateProcess). No problem with the user disturbing, it's an action that the user approved himself. Everything is fine when it's usual layout with taskbar shown and multiply captioned and non captioned- windows. But the situation is different in XP and 7, when the current application is full-screen. Full-screen application in this case is window without borders having exactly the same dimension as the screen. Windows hides taskbar for such application even if it's always on.
In Xp, it's ok, the taskbar is being shown in this case and appication (for example calculator) also, the full-screen app is still visible in areas other than the launched app's and taskbar'. But in Windows 7 nothing visual happens, the full-screen app is still on and if I switch to taskbar, the executed application is there. I tried to solve it with SetForegroundWindow, BringWindowToTop, even AllowSetForegroundWindow(GetCurrentProcessId()) call for a window handle found with CreateProcess-WaitForIntputIdle-EnumThreadWindows, no change. So did something change since XP related to full-screen windows that officially documented?
Thanks,
Max
I would imagine that, if you have your own hardware device, that there is some API for generating "real" user input. Clearly the legacy keyboard and mouse, and now USB HID drivers (many of which are usermode I think?) have access to an API to do so.
Synergy+ for example can generate fake keyboard and mouse events on connected PCs, and the consequence of the faked input is windows switching activation normally.
So, my initial idea is for your usermode "Device" application to synthesize actual keyboard messages - SendInput seems a likely candidate for "the API that can "fake" real user input events.
Then, use an API like RegisterHotKey in your "UI" app to respond to the hotkey combination your device app generates.
Now, (assuming that SendInput IS generating user input events at the correct level), you should (from within the WM_HOTKEY handler in your UI app) have permission (because everything was "user initiated") to change the foreground window (to yourself).
Vista introduced the desktop composition feature. In short, all windows are drawing to a memory bitmaps and the Desktop Window Manager is then composing these bitmaps and drawing on a full-screen Direct3D surface. Full-screen windows do not participate in the desktop composition and get to draw directly on the screen (mostly because the majority of full-screen apps are games that need real-time screen updates).
In particular, this means that when a full screen app is up and running, it is covering the DWM composed image and the user needs to switch to a DWM-managed window for the DWM to start drawing on top of the full-screen app.
I don't have a good solution for your problem, unfortunately. One way to solve it would be to add the WS_CAPTION style to your app and then handle WM_NCPAINT/WM_NCCALCSIZE/WM_NCHITTEST yourself. This would allow you to lie to the DWM that you are a regular windowed application, but change visually your NC area to look like you have no title. However, this does require certain amount of additional code and might be a bit more effort you want to invest.
Another way you can try to solve your problem is to explicitly minimize your full-screen application window when launching the new process. However, you will then have to solve the problem of when to maximize it back again.
Btw, you might find the comments on this post from Raymond Chen interesting.
Windows supports multiple desktops and my guess would be that the full screen up is using a different desktop than the default one (where your application will be shown). A desktop object in Windows is "a logical display surface and contains user interface objects such as windows, menus, and hooks". For example, screen savers normally are started on a separate desktop.
You can find out which desktop an application is running on using Process Explorer:
Set Process Explorer to replace Task Manager and to run always on top.
When your full screen up is shown, launch Process Explorer by pressing Ctrl + Shift + Esc
Within Process Explorer, select the full screen process and press Ctrl + H to display the handles of this process
See the value of the Desktop item in the list. Usually this would be set to Default
If you know what desktop this app is running on you can start your process on the same desktop by first calling OpenDesktop to get a handle to this desktop and then pass it into the STARTUPINFO of your CreateProcess call.