Bob, Thanks for your response.
> And, if you have more than one user > reporting that then it's likely your app. Unless I'm really confused on the way the launch codes work, my app does not respond to the reset launch code. In my app, unless the launch code is sysAppLaunchCmdNormalLaunch, PilotMain simply returns zero. Do I not understand this correctly? The program that is freezing is PDA-TECH's Synclite. I don't think there is any reason for Synclite to respond to a reset launch code but I'll ask him specifically. If I was to fathom a guess as to what's happening, it would be that Synclite is "indirectly" writing to some system file that gets corrupted when the app freezes. I say indirectly because PDA-Tech assures me it's not explicitly doing any such writing. Synclite is written in Sat Forms. I don't know anything about Sat Forms but I suspect there's a lot that goes on under the covers that's hidden from the programmer. Do you know if corruption in one of the preferences database or the network database would cause the flashing logo? > You MUST run the app through its paces > on an emulator/simulator, with all the debugging > turned on, to look for memory issues. My app is written in CodeWarrior. Not only have I configured POSE to complain about everything, I treat all compiler warnings as errors. My app runs absolutely clean on POSE. Because Synclite is a Sat Forms app, POSE complains a lot about the behavior of the Sat Forms RED. I was told, this is "normal" and will not cause problems. > This almost always works. Sometimes you have to keep holding, or taping > the Up button. I've seen it take a dozen tries, and I've also seen it > NOT work, leaving no recourse than a hard reset. So far, I haven't had any success with a warm reset. Maybe I've just not been creative enough with the holding or tapping. Bear in mind that the warm boot attempts have been via phone with an already frustrated user in the field. After the first couple of times, I just figured a warm boot wasn't going to work with this problem and stopped asking them to try. > That technique will stop the loop, but it's only a band-aid, as you > still need to locate, and fix, the memory problem. I'll pass this info on to PDA-TECH but, as I said earlier, I can't think of a reason why Synclite would need to handle a reset either. John C. Christensen "Robert Moynihan" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Jeffry Loucks wrote: > > >It's likely that code flagged to run after system reset, is in a bad state > >and is causing a repeating fatal exception. Thus, the flashing logo > >(repeated resets). > > > >Yes, I know, duh. But, it may be something you or the other package is doing > >improperly on reset. Is any of your software flagged to run at reset? > > > > > This is almost assuredly the case; that some app is responding to the > reset launch code, and is crashing at that point. And, if you have more > than one user reporting that then it's likely your app. This sounds > very intermittent, so troubleshooting it will be hard. You MUST run the > app through its paces on an emulator/simulator, with all the debugging > turned on, to look for memory issues. This may be hard to find though, > as it may be difficult to simulate all the communication stuff, but > reset crashes can be effectively found. > > >You may be able to interrupt the repeating reset by holding the uparrow. > >This will tell it to reset without extensions. Then, at least you'd be able > >to look over the system without a hard boot. If holding the uparrow doesn't > >interrupt it, well... > > > > > This almost always works. Sometimes you have to keep holding, or taping > the Up button. I've seen it take a dozen tries, and I've also seen it > NOT work, leaving no recourse than a hard reset. > > Since the presuption is that your code (or some function that your code > calls) is responsible, my suggestion would be to put in a catch to > prevent the reset loop. This is what I've done in the past... > > As soon as your app starts to process the reset launch code, as the 2nd > thing you do, set a flag in memory (I've used the prefs database before, > setting a small flag that says "I'm handling a reset"). When you've > finished handling the reset launch, and the last thing you do before > returning, clear the flag. The 1st thing you do when processing the > reset launch code is to check that flag. If that flag is already set, > then it means that you did NOT complete the last reset properly, so it's > likely a crash happened, so DON'T do it again. Just bail out and return > control to the user. If you get into this situation, it should only > loop once, then stop, which is greatly superior to an endless loop > requiring hard reset. > > That technique will stop the loop, but it's only a band-aid, as you > still need to locate, and fix, the memory problem. > > Bob. > > -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
