Dave, My guess is that you are not clear about what FrmEraseForm() does. It does not erase the pixels on the form, but erases the form itself so that there would then be no valid draw window. You do not want to call FrmEraseForm() before FrmDrawForm().
Keith Wolcott Dave Johnson wrote: >Well, I found a solution to my problem, but I don't understand it. The >answer to the subject line appears to be: when you call FrmEraseForm >before FrmDrawForm. > >In my update event handler, that's what I was doing. If I comment out >the FrmEraseform, everything is fine. > >I'm guessing here a bit, but I logged events in Poser, and there's a >winExitEvent for my form that appears after the update is handled, and I >think FrmEraseForm is what generates it. But FrmDrawForm apparently >doesn't generate a corresponding winEnterEvent. > >So the sequence goes like this: I'd do my modal dialog, ande when it was >dismissed, change the list then force an update to redraw the list. The >update handler would call FrmEraseForm, then FrmDrawForm. That seems >perfectly benign to me, but it leaves the form, while perfectly visible >and drawn, in an undrawable state. A subsequent call to LstSetSelection >triggered the error. > >That's as far as I've gotten, but I have to think there's more to it. >Surely calling FrmEraseForm followed by FrmDrawForm should leave things >in a ready-to-draw-further state? Am I missing something obvious? > >I can fix the bug by removing code, but I'd also like to understand why >it was a problem, and why this fix works. Any insights/explanations >appreciated. > >Dave Johnson > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/tech/support/forums/
