Is there a way to temporarily disable the display during a Windows 10 PC restart?
Background: we have a software, which is set to start up automatically after a PC restart. Upon startup (after Windows has booted) this software starts in a console window and then opens a WPF screen, which is displayed fullscreen and always resides in front of everything else. I would like to black out the screen ideally as early as possible during the Windows startup up to the point in time when our software WPF window is set and ready on the screen. This way the console window (as well as the desktop showing for a short period of time) would be hidden from the user.
In an ideal world I would hide the fact that Windows is running on the PC from the user, but I assume this is not possible over a restart...
Is this possible with the help of registry settings/command line tools/batch file commands or similar?
I need that one of our computers, when it boots, automatically opens Internet Explorer. IE should be Full screen (without the border and the address bar.. totally full screen) and open a default URL (no problem on this, just set it as homepage). Then I would need that if a textbox inside this page gets focus then the on-screen keyboard should show up.
can this be achived with standard windows settings or do i have to write my own program with browser inside? if i write my own vb.net program, can the program be totally fullscreen (without the X to close and without seeing the task bar)
what we need to do is set up a sort of a internet station where random people can browse a given page without having a keyboard and without having the possibility to access the system.
thanks
I would say it is possible - but I have no idea how to achieve this. There will be a registry setting of some sort which SHOULD enable the keyboard. Sorry - I barely touched this areas :(
Can we open IE in a kiosk mode - but not in a maximized view? We are trying to open an IE instance from a C#.NET app. This instance opens in a kiosk mode but disables the user to select 'OK' on the print preview pop up (as IE is maximized covering the whole screen). We want some way to open ONLY a specific page in IE (thus in kiosk mode) but not covering the full screen so that the user can choose the print options.
Alternatively is there a way to completely disable the print options and print silently using the default options?
Any ideas/suggestions?
It sounds like you're looking for the WebBrowser control, which allows you to embed IE inside your program.
I would take a look into Microsoft HTML Applications:
http://msdn.microsoft.com/en-us/library/ms536496%28VS.85%29.aspx
They are going to give a little more control over how the chrome of the application is displayed, and runs within the context of the currently logged in user.
Is it possible to force the screensaver to appear whenever a computer becomes locked? Specifically on XP, 7 if possible.
Windows has several desktops. You're familiar with the one you are looking at right now. There's another one for the login screen. And there's one for the screen saver. Locking the workstation switches the desktop to the login screen. You cannot switch back to another desktop (like the screen saver one) until you login.
You can however get the screen saver started, that selects the screen saver desktop. Which automatically switches to the login desktop if you configure the screen saver that way.
I believe that the SS is only triggered when the timeout is reached, regardless if the PC is locked or not.
The other way to think of this is to lock the PC whenever the screensaver fired.
Windows 2000 and above has an option to enable lock the PC when the screensaver is active, just enable this, and set the timeout and you are ready to go.
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.