Is there a way to use the Windows APIs to detect if a particular monitor is a projector (beamer) rather than a screen?
(I'm writing a projection mapping desktop application, and I'd like it to automatically detect if a projector is attached and active to allow the user to compare the reality to the preview.)
I've used both EnumDisplayMonitors and EnumDisplayDevices to find the monitors, but I can't find any flag or other indication of the type of the display. I've looked in the DEVMODE and the DISPLAY_DEVICE and the registry keys the latter points to. I don't see a DeviceCapabilities or GetDeviceCaps call that can distinguish between a screen and a projector. I also looked in the device manager to see if there was a property that distinguishes my regular monitor from the projector, but I couldn't find anything. So maybe there's no way to do it.
But, the Screen Resolution control panel applet identifies the projector as "PROJECTOR" while identifying my primary monitor as "Dell U3011." Using EnumDisplayDevices, I can get the "Dell U3011" string from the DISPLAY_DEVICE, but, for the projector, I get just "Generic PnP Monitor." Somehow, the applet must be looking somewhere else to get that "PROJECTOR" string or it shows "PROJECTOR" for any Generic PnP Monitor that seems to be a projector. So where does it look and how does it know?
I believe the answer is that there is no reliable way to do it.
The "PROJECTOR" string that the control panel showed was arbitrary text that the system pulled from the EDID information. As far as I can tell, Windows doesn't actually "know" whether a monitor is a projector or an LCD panel or a CRT tube.
The EDID information doesn't seem to have a flag to indicate whether this is a projector. I saw a note that projectors will typically set one or both of the physical image dimensions (the ones measured in centimeters) to zero. But that was in a description of EDID 1.4, and most of my devices use EDID 1.3. Indeed, none of the projectors that I tried have a 0 for any physical dimension, so it's not a reliable signal.
Related
For Imageprocessing I want to get all pixel information from a given process.
Concrete its for testing an image hashing algorithm for identifying hearthstone cards, so i need to get a screenshot of the given process.
How can I solve it in windows?
My idea so far:
Get the process name.
Get the process ID
Get Window Handle
I have no idea how to go further from this point.
I hope it understandable what I want to achieve.
Unfortunately, there is no general method for getting the pixels of a particular window that I would be aware of. Depending on how the target application draws itself, this task can be very simple or very complicated. If we were talking about an application that uses good old GDI, then you could just get yourself an HDC to the window via GetWindowDC() and BitBlt/StretchBlt the content over into a bitmap of your own.
Unfortunately, the target application in your case appears to be a game. Games typically use 3D graphics APIs like Direct3D or OpenGL for drawing. Assuming that you cannot simply modify the target application to just send the desired data over to you out of its own free will, the only way to specifically record output from such applications that I'm aware of is to hook into the graphics API and capture the data from underneath the API. This can be done. However, implementing such a system is quite involved. There might be existing libraries to aid with writing such applications, but I don't know any that I could recommend here. If you don't have to capture the game content in real-time, you could just use a screen recording application to, e.g., record a video and then use that video as input for your algorithm. There are also graphics debugging tools like NSight Graphics or RenderDoc that you could use. Be aware that games, particularly online games, these days often have cheat protection systems that are likely to get very angry at you if you attempt to hook into the game…
Apart from all that, one alternative approach might be to use DXGI Output Duplication to just capture the entire desktop. While you won't be able to target one specific application (as far as I know), this would potentially have several advantages: First of all, it's only moderately complex to set up compared to a fully-fledged API-hook-based approach. Second, it should work regardless of what API the target application uses and even if the application is in fullscreen mode. Third, since you will have the data delivered straight from the operating system, you shouldn't have any issues with cheat protection. You can use MonitorFromWindow() to get the monitor your target window appears on and then enumerate all outputs of all DXGI adapters to find the one that corresponds to that HMONITOR…
Windows has this little overlay that pops up when you change the volume
I'm implementing a similar notification overlay and I'd like to theme it consistently with this existing overlay without hard-coding magic values. Is there a way to access the colors, font, font color and/or positioning associated with this?
The music information appears to come from the Groove Music application and I'm not sure if that is exposed for user applications to leverage, but the volume bar is a system-wide thing that I would hope I'm able to get some basic information about.
Neither GetSysColor nor GetThemeSysColor appear to have any colors that match.
That music overlay/controller is available to store applications so maybe if you port your application to UWP with the Desktop Bridge you might be allowed to use it.
It would not surprise me if the source of these colors are related to the undocumented GetImmersiveColorFromColorSetEx function in uxtheme.dll.
You can see a list of some of the color names here.
After switching to Windows 10, I've noticed that when selecting a lower than normal screen resolution, the panel fit mode will default to "Maintain Aspect Ratio" meaning black bars appear. Every single time I do this, I have to manually set the panel fit mode to "Scale Full Screen".
I do this very frequently so I'd like to automate the process. I can adjust the resolution fine but cannot fine any API whatsoever to adjust the panel fit. Using a registry monitor, I've found that the setting changes some DWM keys. I'm assuming that some function will need to be called programmatically afterwards to apply the changes.
I've found nothing in the DWM API on MSDN, but I could've missed something.
What am I looking for?
Can pixels be read covertly from a browser window containing flash + HTML?
(Is it possible for flash or the browser to detect a screenshot being taken?)
What about for other methods of capturing pixels? (Like the one described here: How to read the screen pixels?)
EDIT: (background info)
A C++ application is going to read pixels from a browser window (which happens to contain Flash and some regular HTML and JavaScript). The browser window would like, if possible, to detect the fact that it's pixels have been read. The method of getting the pixels could be any (short of taking a photo of the screen itself).
For sure, you cannot detect someone using a framegrabber card to get a screenshot. There is no way you can be aware of this happening, as it happens behind the graphics card output. So for this way, no, no way you can detect it.
Otherwise, it's also pretty simple: Some application can hook your browser and prevent any event from arriving, so the user can press PrintScreen as much as he wants and your browser (let alone your Flash runtime) never gets notified. Your browser app is limited to the browser, while a desktop app has lots of means to hook and do things without notifying the browser.
(Think also about stuff like Linux/X-Windows, which will send the pixels over the wire, or RDP.)
I've seen an application that simulates a fullscreen application by removing the title bar and the window borders. I've done some research and found getWindowLongPtr() for that.
Now my question: How can I find and identify the application and get the appropriate window handle? How can I distinguish multiple instances of the application (running from different locations on disc)?
Just to make "simulate" more precise. If you make an application go fullscreen and you click on a different monitor, it minimizes itself. If the application runs in a window and you click on a different monitor, the window is not changed. If you remove the borders of the window and position it on the left or right monitor, you can still work with the other monitor without minimizing the application. Still it looks like the application running fullscreen on one of the monitors.
As an example: you can set Eve (www.eveonline.com) to fullscreen and windowed mode. In fullscreenmode you can not click on a second monitor without Eve minimizing itself. In window mode you can. There are tools like evemover that allow you to setup your window on one monitor, looking like fullscreen, but being in window mode. That's what I want to archieve. Evemover actually provides some of it's source code, that's why I know that removing the border and setting the position is done using the Win32-API with setWindowLongPtr and setWindowPos.
Many applications use divergent and confusing applications of the phrase "fullscreen".
A fullscreen application simply - occupies the full screen area.
DirectX applications can request a fullscreen exclusive mode. The advantage of this mode to DirectX applications is, with exclusive access to the (full) screen they are then allowed to change the resolution, bit depth etc, as well as gain access to vertical sync synchronized hardware buffering where the screen surface is 'flipped' between display intervals so that 'tearing' does not occur.
Anyway, the windows desktop understands 'fullscreen windows' - windows that occupy the full area of a monitor and have no non client elements. When windows like this are created, things like desktop gadgets and task bars automatically hide themselves. Modern games have come to call this mode 'fullscreen windowed'.
Back to your question: 'FindWindow' is the API used to discover other applications windows. Getting the path to the application that created the window is much harder. GetWindowThreadProcessId can get you the process id of the owning process. OpenProcess will get you a handle that you can pass to QueryFullProcessImageName (implemented on Vista and above) to get the full path to the process.
I think you are refering to applications like window aggregators, that 'plug in' to the system and act from outside the application.
Look at the code for the freeware app PuttyCM (for aggregating Putty (SSH) shell windows as tabs). IIRC, it ensures that the Window pointer passed to the application has the flags already set.
On applications running from different places, you will probably need some way of identifying it - registry entries / install log etc.