Okay. I've been a bit confused by this for some time. I know it is "not recommended" to include colortables in your bitmaps. Instead, to WinPalette to the desired palette (stored external to the bitmap), draw the bitmap stored without a colortable, and then set the palette back after.
But why can't I simply store the "palette" as a colortable in the original bitmap resource, but blit from an offscreen window that doesn't have a colortable? In other words, access the bitmap's colortable to set the main window's palette to that (WinPalette), then draw the bitmap into the offscreen window (which doesn't have a palette), and then just blit like crazy from the offscreen window to my main window? Unfortunately, when I try to WinDrawBitmap() from my colortabled bitmap resource into the offscreen window (with no colortable), I get several rows of garbled junk (the colortable) blitted into the offscreen window (incorrectly) and the rest of the bitmap shifted down/right as a result. Which sucks. I guess maybe I could just MemMove the bits from the stored bitmap into the offscreen window, but I'd have to uncompress them first, which WinDrawBitmap takes care of (if it worked right). I know I could store a separate palette resource and make all this work, but it seems ridiculous to separate a colortable from it's related bitmap, all to avoid processing overhead that is easily avoided anyway. Am I missing something?...Does this behavior from WinDrawBitmap not seem wrong?... Thanks, zane -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
