hDC 2 hDC problem

[orbb]

Hi mans , i am the problem , create a application of invoice (metod - save to bmp).
if my window small for screen - all OK , else if window below TaskaBar of windows , the image include portion of Taskbar ... not the window and controls , below Taskbar .
GetDC , GetDCEx not working here .
cant get image of my window exclude other windows and taskabar etc ?
sory for my bad english !

[PBrennick]

orrb,

Ron Thomas converted a screen capture utility from C to ASM in 2002 or thereabout. Here it is, run it and try the Active Window menu selection. I think it is what you want. If it is just look at his sources to see how it is done.

-- Paul


[attachment deleted by admin]

[MichaelW]

Paul,

I think what is being asked for here is a way to capture an entire window when part of it is off the screen or overlaid by the taskbar. I did not reply because I could not find a hint of any way to do this. The capture program you posted produces the same result as mine. The attachment contains a capture that I think illustrates the problem. The client area of the captured window is 300x300 pixels.



[attachment deleted by admin]

[orbb]

yes MichaelW , this is a problem .

[sinsi]

Could PrintWindow be used somehow? Or something like WM_PAINT but with a memory DC?

[MichaelW]

The taskbar problem occurs when the taskbar is set for always on top. I think the other part of the problem is a result of the window being clipped at the edge of the desktop. I think the taskbar problem can be fixed by temporarily hiding the taskbar. This test code works under Windows 2000:

Code Select Expand


; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    include \masm32\include\masm32rt.inc
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    .data
    .code
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
start:
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
    invoke FindWindow, chr$("Shell_traywnd"), NULL
    mov ebx, eax

    invoke SetWindowPos, ebx, 0, 0, 0, 0, 0, SWP_HIDEWINDOW

    invoke Sleep, 3000

    invoke SetWindowPos, ebx, 0, 0, 0, 0, 0, SWP_SHOWWINDOW

    inkey "Press any key to exit..."
    exit
; «««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««««
end start


For the problem with the window being clipped, if the window is no larger than the desktop then it could simply be moved. If not, then there might be some way to scale the window to a smaller size, while still maintaining the aspect ratio. Another much simpler possibility would be to increase the effective screen area by going to a higher resolution.

[Rockoon]

If its your window, then the solution is the maintain a back buffer.

If its not your window, then the best methodology is infact to ask said window to render itself into a DC that you give it (for example, with a paint message) This is not foolproof because many programs ignore the hdc supplied by these calls and instead go ahead and use the hdc they already had cached for their rendering purposes. A print message suffers other issues, such as the program simply not responding to that message, or rendering something different than it does when asked to paint.

The primary issue here in that win32/gdi does not maintain the contents of a programs window. Instead, win32/gdi merely facilitates the rendering requirements of that OS interface, such as telling a program when it needs to repaint itself to the primary display surface. This all stems back to the days of win16, when memory was much tighter, where a full screen of pixel data would consume a relatively large chunk of available system memory. The choice was made to always let programs deal with rendering themselves, and its been that way ever since.

If the pixel data is not on the primary display surface then you don't have rights to it. You might still be able to get it, but you cannot cry fowl if you can't.