This is for C++ - win32. Basically I've loaded an image (bmp) into a HBITMAP from a file and bitblitted it to the device context for the main window.
How would I call it again in case I want to change the image?
I've called InvalidateRectangle() and UpdateWindow() but that causes the window controls to flicker.
Normally you invalidate the area (e.g. via InvalidateRect) and let your WM_PAINT handler repaint it. Reasons why you would get flicker often are because you haven't overridden the WM_ERASEBKGND handler, your WM_PAINT handler isn't doing double-buffered painting, or you're invalidating (or repainting) an area larger than you need to.
This page might help: Flicker-free Drawing: Techniques to eliminate flicker from your applications
Related
I am currently developing a kind of "WinMerge" clone, and currently I am trying to implement a custom scrollbar which should later represent both compared files as a rectangle in the background each.
This is what it looks like at the startup:
However, after scrolling around a little bit, this is what I end up with:
As you can clearly see, only those parts look correct which I explicitely paint over in my paint routine:
void LocationPane::OnPaint(CDCHandle dc)
{
DefWindowProc();
dc = GetDC();
DrawLocationPaneFigures(dc);
}
This is how my control is configured in my .rc file:
CONTROL "",IDC_LOCATIONPANE,"Static",SS_OWNERDRAW | SS_NOTIFY | WS_BORDER | WS_GROUP,7,21,91,541
As you can see, it is an owner drawn control.
How can I erase the background for this control while repainting it?
A static control with SS_OWNERDRAW style receives a WM_DRAWITEM message when it needs to be redrawn.
So first you need to replace your OnPaint() handler by a handler for WM_DRAWITEM. Instead of calling GetDC() use the device context supplied to you in the DRAWITEMSTRUCT.
To erase the background it's generally best to do it as part of the regular painting code to reduce flickering (by calling FillRect() for instance).
I suggest to always draw the whole client area of your control. Then you may handle WM_ERASEBKGND to return TRUE without calling DefWindowProc() to reduce flickering even more.
I have outputted an image (bitmap) which is created by Bitblt.
Now I want to get rid of it. How can I do? (Do not use the patch, like FillSolidRect, etc.)
There is no way to "undo" or "erase" a BitBlt or any other drawing output (except in very special cases where you do XOR-based drawing, which you can undo by doing another XOR drawing operation on top of the original).
The only thing you can do is to draw on something else on top of it, which is what you are calling a "patch". Typically, you would draw a solid rectangle of the window's background color. This is precisely what the OnEraseBkgrnd message handler does by default, which runs just before OnPaint. Specifically, it uses your window class's background brush, which is typically a brush that draws using the COLOR_3DFACE (for a dialog) or COLOR_WINDOW (for a window) system color.
Of course, you could always just not do the BitBlt in the first place. All painting code should always go inside of the OnPaint message handler function, so there is no way that you could end up with "stale" graphics. Whenever the window needs repainting, it is going to call this function, and your code inside of that function will repaint the window. If you don't want it to be painted with a bitmap, don't call BitBlt.
If you've done a BitBlt on top of your window using a temporary CDC object (which you generally should not be doing), you can force this to be erased by triggering a repaint of the window. The easiest way is to use the window's InvalidateRect() member function; passing NULL as the pointer to the rectangle to be invalidated will invalidate the window's entire client area, or you can just invalidate the area that you blitted.
I'm working on a program that requires WM_ERASEBKGND to be disabled (to avoid flickering).
The problem comes in when my main window loses focus, and another window (another program) gains the focus.
The window that has the focus (not my program) invalidates MY program's window every time it passes over it! The result is, my window's screen turns white everywhere that another window has passed by it, leaving it almost totally blank afterward. Obviously, I cannot have a program where the screen turns white every time it loses focus.
Is there any way to continue my window's drawing operations, (continue calling wm_paint, for example) even after my window has lost focus (WM_KILLFOCUS)?
First of all, from the comments above, never send the WM_PAINT manually with SendMessage or PostMessage. Use InvalidateRect to instruct the window to be repainted.
About the WM_ERASEBKGND, the return value is used to indicate the WM_PAINT handler that the background has been erased, in case the paint procedure can be optimized. To actually prevent the background from being erased, simply do not call DefWndProc() for that message. Or even easier, set the hbrBackground to NULL in the window class.
As others mentioned the focus has nothing to do with repainting, and your window should paint normally even while in the background.
I am wondering in which cases does a widget receive its paint event, and how does it vary with the OS.
Qt documentation for paintEvent says only
A paint event is a request to repaint all or part of a widget. It can happen for one of the following reasons:
repaint() or update() was invoked,
the widget was obscured and has now been uncovered, or
many other reasons.
So far, I've put some traces in the paintEvent,
void Widget::paintEvent(QPaintEvent *e)
{
static int count = 0;
qDebug("paintEvent, %d", count++);
}
and this is what I've found out (on Windows 7 at least):
The paintEvent is called when the widget loses/gains focus. The paint event is not called when another widget passes over our widget. I don't know if that's because of Windows 7 compositing. The paintEvent is also called when a minimized window is restored. The paintEvent is called when resizing.
So is the behaviour dependent on the OS?
Yes, in the sense that you describe, it's dependent upon the operating system.
The Desktop Window Manager (DWM), found in Windows Vista and 7, the doohickey that is responsible for desktop composition, the Aero glass effect, and all kinds of other eye candy, works a bit differently than the model used in previous versions of Windows. As you suspect, it caches the bitmaps for your windows, even when they are not visible because they're obscured by another window. That means it doesn't need you to repaint them (and thus it doesn't raise a paint event) because it can just blit them from the cached bitmap. Not only is this a potential optimization over having each application redraw itself, it also allows the DWM to implement things like Aero Flip, for which it uses its cached bitmap.
The exception to this is as it has always been for, say, the CS_SAVEBITS class style. If the bitmap that the DWM has cached has become invalidated (e.g., because your window image has changed), it will discard it and ask you to redraw the window.
Test this theory by turning off DWM composition (switching to the "Windows Classic" theme), and then obscuring your window to see if you receive a paint event. You should, just like you did in all previous versions of Windows.
But the larger point is that you should not rely on receiving paint events in any particular order. The only thing you should assume about paint events is that you'll receive one when the operating system needs you to repaint your window. Otherwise, it won't bother you. I'm sure that's why the documentation is content with being vague on this point, beyond possible technical constraints.
This is why logic should not go inside of the paint event handler. The only thing that method should be responsible for is repainting the window by its current state. That state needs to saved elsewhere. This rule is also commutative: you should not do any painting outside of the paint event handler.
Of course, you can always force a paint event to be raised by invalidating your window (I'm sure Qt has an invalidate or refresh method for this, check the documentation), but that still doesn't mean it's a good pattern to place application logic in the method that handles this event.
I inherited an MFC app, and it has a window that has several owner-draw widgets that respond to OnPaint and do various drawing.
I noticed that in order to force the controls to redraw in response to various user actions, there was the following code:
CRect rect;
m_myControl.GetWindowRect(&rect);
ScreenToClient(&rect);
InvalidateRect(&rect, FALSE);
I thought this could be simplified like so:
m_myControl.Invalidate(FALSE);
But, in practice, when I do it this way, the control paints sometimes but not others. Specifically, when I'm interacting with controls in the window, sometimes myControl ends up just painting as solid gray. I changed the code back to the more-complicated InvalidateRect style and it's working great again.
Why would there be a difference here?
When you invalidate a window, you don't invalidate the window underneath it. If the parent window is responsible for drawing the control it won't get triggered because you didn't tell it that it needed updating. The original code does the right thing in that case.