a) (caveat: I hate hacking timing sensitive problems, because I can't tell
if I've actually solved it, or just temporarily hid it for this test case
...)
b) Old code did just one EvtGetEvent/PrgHandleEvent per NetLibReceive call,
so I'm guessing that's not enough for the OS to fully set up the
ProgressDialog stuff. So I've replaced the old PrgEvent code with:
while (... NetLib not done and no Cancel ...)
{
(... NetLibReceive stuff ...)
do
{
EvtGetEvent( &event, 0 ); // netlibreceive is delaying enough for both
of us, will get nilEvent when empty
PrgHandleEvent( prog, &event );
}while (event.eType != nilEvent); // keep going till there's nothing
significant to do.
}
and now it works (ahem, "now I can't repeat the problem").
c) Any comments? Should I flush through 20 or 100 nilEvents just in case a
decent event is hidden amongst them?? Should I put a loop limit of 20 or 100
to keep me from hanging if there's some nasty events going on??
G
R
"Greg Rivera" <[EMAIL PROTECTED]> wrote in message
news:99870@;palm-dev-forum...
>
> 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/
