Steve Patt wrote:
>Now that you mention this, I look at code in several of my apps and
>sometimes I'm returning true after processing frmUpdateEvent and
>sometimes false. I have no idea why, and I can't say that it has
>mattered, at least so far as I've noticed. Anyone care to shed any light
>on why this might (or might not) matter?
I've done more research. It does matter - a lot.
Prior to 3.5, you probably seldom saw your form handle an update event.
Usually the form gets automatically redrawn using the saved bits. 3.5 (at
least the debug version) seems to force your update handler to get invoked
more often.
The default update event handler calls FrmDrawForm. Since FrmDrawForm
erases the form, your update event handler will not work properly if you
draw your custom items and then return false to let the default handler
draw the rest of the screen. The FrmDrawForm will erase all your custom
items.
The proper way to handle an update event is to call FrmDrawForm first
(which erases the form and draws the standard form items) then draw your
own custom items, then return true so that the default handler doesn't call
FrmDrawForm.
I have a new problem for which I have not found a good solution. I use
gadgets in some dialogs to draw some custom items. To get the gadget to
draw initially, I have been calling FrmUpdateForm before FrmDoDialog. I now
realize that this has the unfortunate side effect of erasing and drawing
the form twice when it is invoked. I haven't found another way to get my
custom items drawn in the initial display.
Bill Goodman
Cyclos
