Advanced MFC Programming

Chapter 11. Sample: Simple Paint
Problems
Now we have a very basic graphic editor. Before the editor becomes perfect, we still have a lot of
things to do: we need to add new tools for drawing curves, rectangles, ellipses, and so on; also we need to
support more bitmap formats, for example: 16-color DIB format, 24-bit DIB format. We can even add
image processing commands to adjust color balance, brightness and contrast to make it like a commercial
graphic editor.
Besides these, there are still two problems remained to be solved. One is that after loading an image
with this simple editor, if we switch to another graphic editor and load a colorful image then switch back,
the color of the image contained in our editor may change. Another problem is the unpleasant flickering
effect when we draw lines with the grid on.
Message WM_PALETTECHANGED
The first problem is caused by the change on the system palette. Because each application has its own
logical palette, and the system has only one physical palette, obviously the system palette can not be
occupied by only one application all the time. Since the operating system always tries to first satisfy the
needs of the application that has the current focus, if we switch to another graphic editor and leave our
editor working in the background, most entries of the system palette will be occupied by that application
and very few entries are left for our application. In this case, the system palette represents the logical
palette of another application rather than ours, so if we still keep the original logical-to-system palette
mapping, most colors will not be implemented correctly. This situation remains unchanged until we realize
the logical palette again, which will cause the logical palette to be mapped to the system palette.
Under Windows, there is a message associated with system palette changing. When the system
palette is mapped to certain logical palette and this causes its contents to change, a WM_PALETTECHANGED
message will be sent out. All the applications that implement logical palette should handle this message and
re-map the logical palette to the system palette whenever necessary to avoid color distortion.
In the sample, whenever we draw the image in CGDIView::OnDraw(…), function CDC::
RealizePalette() is always called to update the logical palette. So when receiving message
WM_PALETTECHANGED, we can just update the client window to cause the palette to be mapped again.
Usually message WM_PALETTECHANGED is handled in the mainframe window. This is because an
application may have several views attached to a single document. By handing this message in the
mainframe window, it is relatively easy to update all views. The following is the message handler
CMainFarme::OnPaletteChanged(…) that is implemented in the sample for handling the above message:
void CMainFrame::OnPaletteChanged(CWnd* pFocusWnd)
{
CFrameWnd::OnPaletteChanged(pFocusWnd);
GetActiveDocument()->UpdateAllViews(NULL);
}
This function is quite simple. With the above implementation, the first problem is solved.
Flickering
The second problem will be present only if the grid is on. This is because the grid is drawn directly to
the client window: whenever the image needs to be updated, we must first draw the bitmap, and this
operation will erase the grid. The user will see a quick flickering effect when the grid appears again. If we
keep on updating the client window, this flickering will become very frequent and the user will experience
very unpleasant effect.
We already know that one way to get rid of flickering is to prepare everything in the memory and
output the final result in one stroke. This is somehow similar to that of drawing bitmap image with
transparency (See Chapter 10). To solve the flickering problem, we can prepare a memory bitmap whose
size is the same with the zoomed source image, before updating the client window, we can output
everything (image + grid) to the memory bitmap, then copy the image from the memory bitmap to the
client window.
366