David Fedor wrote:
>The two messages about creating offscreen windows without a valid draw
>window aren't errors, but they are warnings about doing things which are
>quite likely to be mistakes or error-prone.
>
>Why are these error-prone? Well, without an active window, the system has
>to guess what bit depth you wanted when you called
>WinCreateOffscreenWindow. On the debug rom, therefore, it gives you a
>warning. On a release rom it'll use the depth of the display window, which
>hopefully is right, but isn't necessarily. You should update your code so
>that you're guaranteed of getting what you want.
According to the docs, the draw window is set at the same time the active
window is set. Since I am doing this in the frmOpenEvent handler, I think
the active window has already been set. Therefore, the draw window should
also have been set. Is that not right?
What additional steps should I be taking to create the offscreen window
correctly?
It seems like this might be a flaw in the current API. I don't think
WinCreateOffscreenWindow should be looking at the current draw window to
determine the bit depth of the offscreen window I'm creating. What if I
WANT a different bit depth? How could I specify that? I think you need a
new variant of WinCreateOffscreenWindow which allows you to specify that
you want the current screen depth or some other bit depth.
>It is also the case that sometimes (defined later) calling FrmDrawForm will
>erase the contents of the form before drawing it. This means that if you
>draw on your form and then call FrmDrawForm, what you drew might well be
>erased. This erasing will happen on release roms when bringing up a form
>which has the 'save behind' bit set, and for custom alerts, and modal
>forms. It'll always be cleared on debug roms, and you should update your
>code to do the drawing after calling FrmDrawForm so that your app will work
>right in the past as well as the future.
In my frmUpdateEvent handler, I currently do any drawing necessary and then
return false (not handled) from my event handler. Does the default handler
call FrmDrawForm which would then erase my drawing? Is the proper way to
handle frmUpdateEvent to call FrmDrawForm, draw my items and then return
true?
Bill Goodman
Cyclos
