I thought that you all might be interested in something that I have found out about the sysAppLaunchFlagSubCall launch flag and the state of the A5 world (globals). The header file that describes sysAppLaunchFlagSubCall states, "This tells the launch code that it's OK to keep the A5 (globals) pointer valid through the call.". While the launch code can assume that its ok, it does not always keep A5. This can end up being drastic for your app. For example, suppose app A calls app B and then app B calls app A. This can happen and when it does, sysAppLaunchFlagSubCall is indicated by the called A's launch code. Thus, if the called A routine attempts to do anything with globals then all hell will break loose. The above scenario of A calling B, B calling A again happened to my app where A called upon B to perform some inter-app function, and then A's alarm went off. An alarm going off results in a launch of A again and, although the launch code indicates sysAppLaunchFlagSubCall given the suspended presence of A, globals were not setup. To get around this problem, you should obtain the value of the A5 register under normal launch conditions. I store the A5 value as a feature when my app is launched normally. When processing a routine that tests sysAppLaunchFlagSubCall for globals, you should also obtain the feature with A5 against it, then (while remembering the current value of A5) set A5 to the value obtained. Then you do your normal processing and restore A5 back to what it was prior to setting to the feature's value. I'll publish the source code for this if there is any interest; just let the forum know. Thoughts, comments, suggestions, corrections etc... -- Christopher Hunt Class Action Pty. Ltd. Are you a time zone traveler that owns a Palm(tm) connected organizer? Check out http://www.classactionpl.com/TimeTraveler/index.htm
