I would suggest processing all events between processing NetLib calls. Then you don't drop out of your loop with unprocessed events left in the queue.
Matt ----- Original Message ----- From: "Greg Rivera" <[EMAIL PROTECTED]> To: "Palm Developer Forum" <[EMAIL PROTECTED]> Sent: Saturday, November 02, 2002 11:07 AM Subject: Progress Dialog events occur after PrgStopDialog (bad memory reference) > We are getting ctlEnterEvents to draw the "Cancel" button on a progress > dialog, in our main event loop AFTER we have called PrgStopDialog (and after > the original dialog has been erased). The emulator is catching it as it is > accessing released memory. > > What works: > We call PrgStartDialogV31, loop doing NetLibReceive(till we get enough > data) and EvtGetEvt/PrgHandleEvent (keep system happy), then leave the > routine with PrgStopDialog(prog, true). When left alone, the dialog pops up > for a few seconds, NetLibReceive eventually gets us enough data, progress > dialog closes, and no weird extra events. > > What is weird: > If we click on "cancel": NetLibReceive returns immediately with whatever > data it has so far (ok?), we call PrgStopDialog and the dialog is erased > (ok), we exit the routine and go back to our normal event loop (ok), and > then we see a ctlEnterEvent to draw that "cancel" button again (ends up > drawing it about halfway up the screen). Just the cancel button is drawn, > nothing else. (Clue?: it is drawn in highlighted color). Then a ctlExit, > penup, and a bunch of nils. Of course, that ctlEnterEvent is busy reading > unallocated memory (its the old original "cancel" ctl block, so at least > it's trying ...), so that's not good either. > (running emulator, occurs on 3.5 and 4.1, haven't checked elsewhere) > > Side strange note: At the time we call PrgStopDialog, neither PrgUserCancel > nor the Progress structure show "user cancel" as being set. > > a) Sound obvious/familiar to anyone? > b) Maybe we should flush some PrgHandleEvents BEFORE calling NetLibReceive, > so things can be set up properly? > c) Any other ideas? So far, I can repeat it rather consistently, unless I > put breakpoints inside. Then the timing all changes and it works fine again. > > Thanks, > > G > R -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
