Kevin: I cannot tell whether the case is as you've presented without disassembling Program B, which I intend to do next. As per your suggestion, the first round of Program A calling Program B, Program A IGNORES an appStopEvent in its queue, which I think is an obvious indication Program B is doing an SysUIAppSwitch. Program A runs merrily for quite a while longer, until it has to call Program B again. When Program B is calling Program A for the second time is when things go wrong, and something is amiss. Are you still in the opinion Program B is calling Program A as a sublaunch? Another thing for your consideration is that the code in Program A that calls Program B is not necessarily in Program A's first code segment! Gabriel.
"Kevin OKeefe" <[EMAIL PROTECTED]> wrote in message news:106656@palm-dev-forum... My guess is that program B is calling you as a sublaunch which is causing you to attempt to use code that is not in your first segment. In non-global launch codes, you can only use code in the first segment. Kevin -----Original Message----- From: Gabriel Rymberg [mailto:[EMAIL PROTECTED]] Sent: Friday, December 27, 2002 4:19 AM To: Palm Developer Forum Subject: An interesting challenge regarding SysAppLaunch Hello all: I post this interesting challenge, that has cause me loose many nights of sleep, in the hope that the Palm OS gurus out there might provide me the clue to pull this off. The entire scenario pertains to a Handspring Platinum, running Palm OS 3.5H2 (with Handspring Extensions). The scenario is simple. It involves two programs, A & B. Program A is mine, and in it I can do whatever I want. However, Program B is fixed, and cannot be changed - it is supplied as a read-only program on a SpringBoard module. Program A MUST call program B with a non-normal launch code (in this case hsSysAppLaunchCmdRemove or hsSysAppLaunchCmdInstall), and thus uses SysAppLaunch to perform the subroutine call. No problems here, as Program B was built to run under non-normal launch codes and thus supposedly uses no globals or statics. Alas, this is where the plot thickens... Program B does not behave as a normal subroutine and does not return normally! Instead, Program B has devised a mechanism whereby, based on setting a feature (FtrSet) with a creator Id, it will invoke the application with that creator id. If Program A sets that feature (with its own creator ID), it will be invoked back by Program B (I'm not sure whether by SysAppLaunch or SysUIAppSwitch). If Program A does not set the feature, it will lose control of the Visor and that defeats the purpose of Program A. Therefore, Program A uses the feature. The interesting part is that the scheme used to work until recently, where Program A become very large (Multi-segments, with around 300K of size). On a very consistent basis, calling the Program B with launch code hsSysAppLaunchCmdRemove causes an address error. The call stack is somewhere in the "System" database, in ROM (I can provide a call stack example upon request). I assumed stack overflow problems and increased the stack to $3000. No change. I need assistance in understanding the mechanism of SysAppLaunch and what happens in the case the subroutine does not return, but instead calls the calling program back! Any help will be greatly appreciated. Gabriel Rymberg. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ ------------------------------------------ The information in this transmittal and any attachments is privileged and confidential and is intended only for the recipient(s) listed above. You are hereby notified that any unauthorized distribution or copying of this transmittal or its attachments is prohibited. If you have received this transmittal in error, please notify Invivodata immediately at (831) 438-9550. ------------------------------------------ -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
