New to Windows 8 and 8.1 is a volume overlay that sits above all other windows, and displays for 3-5 seconds every time you press one of the special volume buttons present on many keyboards.
Please note that I am not talking about this:
But rather this:
Which appears in the top left corner of the monitor.
I would like an API or something that will disable the display of this indicator when volume buttons are pressed on the keyboard.
Does something like this exist? Programming language doesn't matter, as I can convert from whatever to whatever, but for reference I will be implementing this in C++
There is not a documented method for disabling the UI, and I'd expect that any technique for doing so would rely on potentially risky/unsupported APIs/techniques.
The UI is now provided by Microsoft to enable a standardized experience for volume control across all devices. Some applications like the Microsoft Music application expect the volume control to be present so that they appear together.
In Win 8.1, all Media handling support was moved to the SystemMediaTransportControls. An app has only a tiny bit of control over display: IsEnabled.
If possible, you might consider relying on the built in support -- as they're not likely to go away, and it's unlikely that you'll be able to control them in the manner you want.
Related
I have a scientific instrument that is connected to my computer's graphics card and functions like a monitor. I want to completely define what is displayed on that instrument at all times. Unfortunately, Windows displays all kinds of junk whenever it decides to repaint all monitors and in other cases as well. In 2020, Microsoft announced a Windows Pro/Enterprise feature to "Remove display from desktop", which would stop Windows itself from displaying anything on that monitor, but still allow the programmer to access it from their code. Does anyone know how to do this, programmatically (WinAPI?) or via some trick?
P.S. Currently, I have 2 ways of drawing on my instrument: SetDIBitsToDevice() and a PyQt5-window, but I could also program in OpenGL, for example.
Context: our desktop application is used predominantly by users with significant access issues and therefore some of them use the Windows on screen keyboard. One bit of feedback we've had is that the software is awkward to use with the OSK as too many important bits of the UI get covered up. If we could detect the presence of the keyboard we could adapt the UI to some extent.
Therefore is it possible in code to detect that the Windows in-built OSK is open? And is it possible in code to detect the location of the keyboard?
The application is in WinForms and usually runs on full desktops/laptops - not smaller touchscreen machines.
I'm developing a app that will be available at a regional fair and the public will use it to quickly download "perks" to theirs pen-drives. BUT when you move your mouse to the top-right corner of the screen a "menu" appears (there's a similar thing on tablets) and it enables the user to quit/switch-out-of my app, and that I can't allow! How do I block that?
You have to wait for Windows 8.1 i.e. 18th October. 8.1 offers such thing to manage. Moreover it also offers kiosk mode. Through which you can allow only one app to be open on top most.
Source
This is not under the control of your application, it's a feature of the operating system. And as far as I know, there's no way to block it. Typically such changes would be done through group policy settings, but at least in Windows 8, there's no such control available. I'm not sure about Windows 8.1, although I haven't stumbled upon any mention of such features there, either.
Also, this is not the only way for the user to switch out of your application. He could also drag the app down from the top and close it or go to the lower bottom corner to open the start screen, if he's using the mouse. The keyboard would give him even more options, of course.
When you press Identify button in Screen Resolution dialog then Windows shows you big white monitor numbers on each monitor. It was easy to find them programmatically together with monitor coordinates in Windows XP (with EnumDisplayDevices) but on Windows 7 it's broken. How can I do that?
EnumDisplayDevices and GetMonitorInfo are not reliable anymore for that purpose in Windows 7.
I tried GetMonitorInfo and then extracting monitor number from MONITORINFOEX.szDevice (I.E. \.\Display2) with no success. Another guy did that too two years ago and claimed that getMonitorInfo has a bug. This bug was marked as fixed by Microsoft without any comments but it still can be reproduced on a win7 machine having latest updates. (Btw, can anybody tell me - maybe this bug is absent on win8 ?)
I tried QueryDisplayConfig from new CCD API but didn't find needed info.
Does anybody know the way?
Windows does not provide a function that allows applications to obtain the numbers used by the display settings app. The numbers themselves are specific only to the display settings app and have no meaning in the system or in the CCD APIs used to query/set the display topology.
The best option is for applications to define their own criteria for assigning an index when prompting the user to select a display.
I have never wanted to know in my Windows applications the number of monitors, but you can call GetSystemMetrics function with parameter value SM_CMONITORS to get the number of display monitors on a desktop.
I call in my Windows applications function GetSystemMetrics mainly with the parameter values SM_CXVIRTUALSCREEN, SM_CYVIRTUALSCREEN, SM_XVIRTUALSCREEN and SM_YVIRTUALSCREEN to avoid opening application windows completely or partly outside the display area. An application window could be nevertheless not visible if the user has extended the display area over multiple monitors, but not all of them are turned on.
The SystemParametersInfo function function with value SPI_GETWORKAREA for uiAction parameter is also very useful to know where an application window can be positioned and how large it can be in width and height on primary screen without being partly hidden by other windows (bars) being always on top.
See also GetMonitorInfo function if more informations from the monitors are required in your Windows application.
For Windows versions supporting WDDM, which Windows 7 does, you can simply use DXGI which is part of DirectX. DXGI allows you to very easily enumerate the existing display adapters, the available display outputs per adapter and the supported display modes per display output. While enumerating there's a lot of additional data you can read out, like handles, identifiers and device names. All of this can easily be used to retrieve the working areas as well. The order in which adapters and outputs are enumerated is defined by the system and matches the order of your configuration screen.
See here for more information: MSDN DXGI Overview
I want to get the window handle of some controls to do some stuff with it (requiring a handle). The controls are in a different application.
Strangely enough; I found out that many controls don't have a windows handle, like the buttons in the toolbar (?) in Windows Explorer. Just try to get a handle to the Folder/Search/(etc) buttons. It just gives me 0.
So.. first question: how come that some controls have no windows handle? Aren't all controls windows, in their hearts? (Just talking about standard controls, like I would expect them in Windows Explorer, nothing customdrawn on a pane or the like.)
Which brings me to my second question: how to work with them (like using EnableWindow) if you cannot get their handle?
Many thanks for any inputs!
EDIT (ADDITIONAL INFORMATION):
Windows Explorer is just an example. I have the problem frequently - and in a different application (the one I am really interested in, a proprietary one). I have "physical" controls (since I can get an AutomationElement of those controls), but they have no windows handle. Also, I am trying to send a message (SendMessage) to get the button state, trying to find out whether it is pushed or not (it is a standard button that seems to exhibit that behaviour only through that message - at least as far as I have seen. Also, the pushed state can last a lot longer on that button than you would expect on a standard button, though the Windows Explorer buttons show a similar behaviour, acting like button-style checkboxes, though they are (push)buttons). SendMessage requires a window handle.
Does a ToolBar in some way change the behaviour of its child elements? Taking away their window handle or something similar? (Using parent handle/control id for identification??) But then how to use functions on those controls that require a windows handle?
If they don't have a handle, they're not real controls, they're just drawn to look like controls.
But of course, the toolbar buttons in Windows Explorer do have window handles, they're part of a toolbar. Use the toolbar manipulation functions to interact with them, not EnableWindow.
Or, better yet, use the documented APIs for things like search. Reverse-engineering Windows Explorer has never ended well for anyone, least of all the poor Windows Shell team, saddled with years of backwards-compatibility hacks for certain developers who thought that APIs are for everyone else. Whatever you do manage to get to work is very likely to break on the next version of Windows.
The controls you are talking about are using the ToolbarWindow32 class. If you want to interact with them then you'll need to use the toolbar control APIs/message. For example for enabling buttons you'd want to use TB_ENABLEBUTTON.
You can implement the controls yourself using GDI, OpenGL or DirectX. Try Window Detective on Mozilla Firefox and you will see that there is only one window. Controls in dialog boxes are not windows known to Windows.