Bitmap-based output devices are a pain. I created this nice little class called OutputDevice (OK, I borrowed the concept from something else and improved on it). It's a nice little wrapper for HDC's, so you can draw to the screen in a relatively platform-neutral way. One of the niceties I added was a derived bitmap output device, so you can draw to a bitmap, which is awfully handy. Only problem is the design of the object. Basically it does the following. . .
Constructor: Copy the bitmap to a draw-able temporary space.
Destructor: Copy the temporary space back to the bitmap.
Problem comes when I need to do stuff with the bitmap. Sometimes the object's not yet destructed. For example. . .
Bitmap B(Size(100, 100));
DrawableFont F;
BitmapOutputDevice OD(B); // make an OutputDevice for the bitmap
F.DrawText(OD, String("This is a test"));
Bitmap C(B); // copy the bitmap
Now, if you think C has the text I just drew to B, you'd be wrong. Since OD has not been destructed, the changes have not yet been drawn to it. You could fix that with something like this. . .
Bitmap B(Size(100, 100));
DrawableFont F;
{
BitmapOutputDevice OD(B); // make an OutputDevice for the bitmap
F.DrawText(OD, String("This is a test"));
}
Bitmap C(B); // copy the bitmap
Now C contains the changes, because OD got destructed and wrote the changes to B. Only problem is that this is ugly and hard to remember to do. An only-slightly-better solution is to add a function (besides the destructor) that copies the stuff back.
Bitmap B(Size(100, 100));
DrawableFont F;
BitmapOutputDevice OD(B); // make an OutputDevice for the bitmap
F.DrawText(OD, String("This is a test"));
OD.Commit(); // copy the bits back to B
Bitmap C(B); // copy the bitmap
Like I said, it's not as ugly, but you've still gotta keep track of it.
