>The usually reliable David F. wrote:
>
>> And no, it
>>doesn't support allocating something >64k, but since the offscreen window
>>is always 1-bit, it'd have to be a pretty large window to go past that.
>
>However this isn't correct. As documented in WinCreateOffscreenWindow,
>and I can attest to the documentation being correct,
>WinCreateOffscreenWindow "creates a new bitmap in the same depth as the
>current screen". I.e., will be 1-bit if you have the screen in 1-bit
>depth, but it ain't necessarily so (as the song goes).
Ah, so it turns out to be an even more mysterious and alarming story than
just a case of me contradicting the docs. There are differences between OS
versions, unfortunately, and I hadn't looked at all of them before
answering.
In 2.0, WinCreateOffscreenWindow would always use 1-bit.
In 3.0, WinCreateOffscreenWindow would use the same depth as the draw window.
In 3.1, same as 3.0.
In 3.2, same as 3.0.
In 3.3, I'm not sure (I don't have those sources handy) but I bet it was as
3.0.
In 3.5, it would use the display window's depth. (Not the current drawing
window, but the display.)
In 4.0, same as 3.5.
Furthermore, in 3.5 and earlier, the actual bitmap buffer is limited to
64k. A licensee could and might have circumvented this limit, but I don't
know for sure. In 4.0, it can be >64k.
My main mistake was looking at 3.2's Window.c instead of WindowNew.c :-(
Thank goodness we got rid of the "New" suffixes when we went to 3.5!
Anytime you call something New, you regret it in a little while when you
have to worry about whether something is the old new, or the new new, or an
experimental new like ControlNew.c was...
Oh well, I guess that was my mistake for the day, taken care of at noon.
Usually I wait till later in the day, but what the heck.
-David Fedor
Palm Developer Support
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
