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/
