I am trying to capture screenshot of inactive window with PrintWindow. It works correctly for calculator and for capturing Google Chrome, but for some other applications, like games, it saves white area.
What could be the reasons for PrintWindow to fail and how to validate them?
EDIT: I want tool to report why window can not be captured
Every window has a default implementation for WM_PRINT, you will use it if you call PrintWindow() and don't use the PW_CLIENTONLY flag. Provided by the default window procedure, DefWindowProc(). It is pretty straight-forward, it creates a memory DC and sends WM_PAINT. So what you get in the bitmap is the same you get on the screen. Everybody happy.
But that only works for windows that actually use WM_PAINT to render their content. The chips are down when it doesn't, most any game actually renders with DirectX and does so at a high rate, not relying on WM_PAINT messages. A program that uses a layered window with alpha transparency doesn't either, you can typically recognize them from a fancy blended border.
What such a program should do is write their own message handler for WM_PRINT/CLIENT and render their surface into the device context. Necessary because the default implementation doesn't know beans about DirectX surfaces.
Games just don't do this, that's extra code they have to write that just about nobody ever actually uses. You'll inevitably end up with an empty bitmap. Nothing you can do about it of course.
The documentation for PrintWindow provides information on its implementation:
The application that owns the window referenced by hWnd processes the PrintWindow call and renders the image in the device context that is referenced by hdcBlt. The application receives a WM_PRINT message or, if the PW_PRINTCLIENT flag is specified, a WM_PRINTCLIENT message. For more information, see WM_PRINT and WM_PRINTCLIENT.
Whether or not PrintWindow returns a window's content is subject to the window procedure handling the WM_PRINT or WM_PRINTCLIENT message[1] appropriately. If a window doesn't handle either of those messages, it will not render anything into the provided device context.
[1]Standard window implementations provide a message handler for WM_PRINT/WM_PRINTCLIENT through DefWindowProc. Custom window class implementations need to provide their own.
Related
So I`m very new to win32ui, basically just starting. I was once using BitBlt wit python win32api module and as far as I remember to draw on top of display (so any application - if they are opened) I had to get specific context handle. But my memory is hazy on whether it simply was NULL or was it some specific context? Null doesn't seem to work, so I wonder how to obtain that general context? I really want to avoid to create fully transparent un blocking window.
The GetDC API allows you to get a device context for any given window. Alternatively,
If [hWnd] is NULL, GetDC retrieves the DC for the entire screen.
You can use the device context for the entire screen to read from, reliably (with restrictions). Rendering into a device context for a window you do not own won't be reliable, though. While it won't fail straight away, the window owner can overwrite your rendering at any point. There's no way for you to even be notified about this.
If you need to render on top of the screen you will have to create a top-most (transparent) window yourself, and use its device context. Make sure you ask the question: What if two programs did this?
I need to know if it is safe to store some calculated non-client area RECT (not the window rect neither the client one, it is a based on some calculation) from the WM_NCCALCSIZE message and use it later in the WM_NCPAINT without the need to do the whole recalculation process again in WM_NCPAINT!?
i.e. is WM_NCPAINT always called immediately after WM_NCCALCSIZE?
I need to save the hassle of doing the recalculation process in WM_NCPAINT message, because DefWindowProc from WM_NCCALCSIZE already does all what I need to start my calculations based on what it does.
TIA.
i.e. is WM_NCPAINT always called immediately after WM_NCCALCSIZE?
I test this sample which provided by krsi, we can find that WM_NCCALCSIZE is always called before WM_NCPAINT, but this does not mean that no other messages were called in the middle. For example, when testing, after receiving WM_NCCALCSIZE, WM_PAINT will be called first, and then WM_NCPAINT will be called.
You seem to be customizing the non-client area, I think you can first read Nonclient Area.
In general, processing these messages for standard windows is not
recommended, because the application must be able to draw all the
required parts of the nonclient area for the window. For this reason,
most applications pass these messages to DefWindowProc for default
processing.
An application that creates custom nonclient areas for its windows
must process these messages. When doing so, the application must use a
window device context to carry out drawing in the window. The window
device context enables the application to draw in all portions of the
window, including the nonclient area. An application retrieves a
window device context by using the GetWindowDC or GetDCEx function
and, when drawing is complete, must release the window device context
by using the ReleaseDC function.
If you just consider whether the size of the custom client area will change when WM_NCPAINT is called, I can't give a suitable answer because I haven't seen your code and I don't know what kind of project you need to complete.
I just tested the sample in another link, the non-client area will always maintain the border size of 4pixel, and the calculation is also performed in WM_NCCALCSIZE.
I'm trying to prevent my rendering from stopping when my window is out of focus or resizing. In addition to the resizing, if I resize my window smaller, then bigger again anything that wasn't visible when it was smaller is now black. Is there any way to fix this?
There are really two distinct things going on here. The moving/resizing problem is caused by the windows DefWindowProc function which applications use to handle messages that aren't explicitly handled by the application itself. In the case of moving or resizing, it blocks, creating a new message queue to handle most messages, but there are a few that it will still dispatch to the application's main event queue, like WM_TIMER. You can find lots more information in this answer.
The second issue is that your program only "owns" the pixels inside your window, and only those that are not covered up by other windows. When you make the window smaller, the pixels at the edge need to be overwritten to show the window border or whatever's behind the window. When the window is made bigger, some drivers automatically set the newly acquired pixels to black, while others leave them at whatever they were before (usually part of the window border). The OS doesn't remember if those pixels had some specific color the last time the window was that size, because most of the time the program doesn't care. Instead, windows sends a WM_PAINT message to indicate that the application should redraw the window. Your program should either directly handle this, or use a library like GLFW that abstracts it. In addition, you need to handle resize events by calling glViewport with the new size of the window.
I am trying to emulate simple mouse movement in a window belonging to another process. My app uses global hooks to inject DLL into the target process (WH_CBT and WH_GETMESSAGE) and the injection works like a charm. The intention is to fool the target process into thinking the mouse went over a portion of the screen. When I do a movement with the physical mouse, this triggers a certain app behavior (e.g. a tooltip is being shown). I would prefer if the actual mouse pointer remained in its current position when I perform the "trick".
I have established message monitoring with Spy++. Sending (or posting) plain WM_MOUSEMOVE messages to the target HWND is registered by Spy++ but has no desired effect. When the mouse is physically moved, the app does its thing. I have tried sending some other messages in conjunction to WM_MOUSEMOVE (e.g. WM_SETCURSOR) but things didn't improve. I have even hijacked GetCursorPos in the target process to return the same coordinate as posted in WM_MOUSEMOVE (former is screen, latter is client) but this didn't help either.
When I do a simple SetCursorPos, the app does what it's supposed to do. What other magic am I missing that the SetCursorPos is doing? The messages captured by Spy++ look more or less the same in both scenarios.
Any suggestions on how to send mouse movement are welcome. I do not want to use SendInput, mouse_event or other APIs. I need to target a specific HWND for a very brief period of time.
Usually a tooltip is shown as a result of the WM_NOTIFY message, which is sent with the TTN_SHOW notification code. Have you tried it?
I've just got a fresh device context (DC):
GetDC(someForeignHwnd)
Most normal people now want to paint on this. I don't. I want to display the context in my own program. Or duplicate, I wouldn't even mind the window I stole the context from beeing empty.
In my case, I want it in a TPanel in Delphi, but anything else helping me understanding goes.
Afterwards, I'll probably find the DC invalid by the time I get to display it.
My main problem is: Showing the content of another window in my own. But that isn't important. First of all, I want to know how these DC are of any use. Can I do something like the following?
Canvas.Draw(0, 0, MyNewDC);
The answer can be in Java, C, or Pascal. Is it just not possible or just a stupid idea?
While it's possible to use a device context that you retrieve via GetDC() as the SOURCE for BitBlt(), etc., you will likely not get the results that you're looking for. When you call GetDC() for a specific window, Windows essentially returns a device context for the screen, but with a clipping region set to exclude any portions of the screen where the window is not visible. For example, if there happens to be another window overlapping the source window, the portion of the source window that is covered is clipped from the device context. Therefore, you can only "retrieve" the bits that are actually visible.
You may have better luck sending a WM_PRINT or WM_PRINTCLIENT message to the window. However, not all windows respond to these messages, so this isn't a universal solution.