BitBlt without underlapping windows

Paul Thomas
01-27-2005, 05:02 PM
I understand how to use BitBlt to capure an image and transfer to an fro device/compatable. But how do I make sure that I transfer only what I have drawn within the DC bounds and nothing else (say the parent window is resized over the DC when transfering)?
att example

zelg37
01-27-2005, 10:59 PM
I understand how to use BitBlt to capure an image and transfer to an fro device/compatable. But how do I make sure that I transfer only what I have drawn within the DC bounds and nothing else (say the parent window is resized over the DC when transfering)?
att example
The only way I know to workaround resize clipping that's part of a screen DC is to use some kind of backbuffer.

A picturebox has such a backbuffer if you set it's Autoredraw property to True, but in your case a memory DC backbuffer may be easier to work with.

Demo with code for setting up a Memory DC backbuffer:
http://www.xtremevbtalk.com/t157310.html

Drawing to Memory DC, some additional links on this post:
http://www.xtremevbtalk.com/showpost.php?p=757961

passel
01-27-2005, 11:45 PM
...A picturebox has such a backbuffer if you set it's Autoredraw property to True, but in your case a memory DC backbuffer may be easier to work with.


If the drawing is being done to the form's DC, or a Picturebox's DC, then
setting AutoRedraw True would seem to be the easiest to work with, since
there would be a good chance that no other code would need to be changed
from the existing code, except possibly needing to add a .Refresh statement
after the drawing to update the screen image of the control or form.

If using GetDC to get the DC from the form or Control, that would still return
the Screen context, rather than the memory context, so would suffer from
the same problem since it would be writing directly to the screen (or blitting
from the screen) rather than from the backbuffer.
If that was the case, then the code would have to be modified to refernece
the hDC property of the control or form, rather than using GetDC.

That said, using a created memory DC as zelg37 suggested would probably be
more efficient, and since it looks like you're already using the API to do most
if not all of your drawing, would probably not be as much of an impact on your
program compared to someone using the VB drawing methods.
could be almost no code that would need to be modified from
the existing

Paul Thomas
01-28-2005, 05:05 AM
If the drawing is being done to the form's DC, or a Picturebox's DC, then
setting AutoRedraw True would seem to be the easiest to work with, since
there would be a good chance that no other code would need to be changed
from the existing code, except possibly needing to add a .Refresh statement
after the drawing to update the screen image of the control or form.

If using GetDC to get the DC from the form or Control, that would still return
the Screen context, rather than the memory context, so would suffer from
the same problem since it would be writing directly to the screen (or blitting
from the screen) rather than from the backbuffer.
If that was the case, then the code would have to be modified to refernece
the hDC property of the control or form, rather than using GetDC.

.That said, using a created memory DC as zelg37 suggested would probably be
more efficient, and since it looks like you're already using the API to do most
if not all of your drawing, would probably not be as much of an impact on your
program compared to someone using the VB drawing methods.
could be almost no code that would need to be modified from
the existing
Thanks for your quick replies.

Yes I'm using only api, if I could use picturebox.hDC and picturebox.hDC then there would no need to use BitBlt at all. You see this is vba in MS Access. I have created a workaround the graphical limitations caused by the page concept of MSForms, which is almost finished except for this clipping problem. With a message handler every time the ctrl paints I transfer the saved bitmap. I have to use getDC because there is no .hDC or even .hWnd property of the AxtiveX Forms2 Frame. In order to get the hWnd I use Getfocus when ctrl.setfocus (this will not work on a picturebox). Why not enumerate? Well it is notoriously difficult to enumerate all the objects on the access form, and even more difficult to work out what they all are. I have partly done it in order to clip children in another project but there is no real point in this one. Why not draw directly in the client area? Well Access Forms are heavily clipped because of the page handler object and your drawing would bare no relation to a page itself. You see if place a ctrl on an Access form it doesn't have a unique hWnd instead an array objects (one for every record per page) is drawn in real-time and a hWnd is passed to the current record when updated. There are a number of other things but I won't go into them. Therefore it is fruitless to use this with continuous forms (why any one would want to anyway, they take up enough space). I will look at buffering and see if I can make it work. The only other thing I can think of is prevent the form from resizing over the bound ctrl but then again think of the complaints. Right now the GDI memory isn't a problem I just hope the buffering won't cause it to skyrocket.

Paul Thomas
01-28-2005, 05:41 AM
I had a quick glance at the sample code and it seems that I am doing exactly the same using a back buffer. That's the whole point of using BitBaconLettuce&Tomato!!! :chuckle: The problem is the user gets to choose when to draw and Access wants to get this sh*t of its control almost immediately so I transfer to the buffer then when it paints back again. You also have to make sure the ctrl doesn't have keyboard focus while drawing (don't ask :huh: ). You would think If you can include overlapping windows why can't you exclude underlapping windows? :confused: Isn’t there a way to access the buffer that windows has and draw onto that?

Paul Thomas
01-28-2005, 05:51 AM
:whoops: Sh*t I just worked it out I need to buffer before sizing and draw directly onto the buffer then transfer. lateral t'nk'n :D

Paul Thomas
01-28-2005, 06:00 AM
:( I can't buffer resize when the size is already too small. Maybe i should make it temporarily visible over everything, extend parent clipping or use transparency or something.

EZ Archive Ads Plugin for vBulletin Copyright 2006 Computer Help Forum