Jeffry Loucks wrote:
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.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?
You may be able to interrupt the repeating reset by holding the uparrow.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.
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...
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/
