Out of curiosity, what's the rationale for the sysAppLaunchCmdCardLaunch
launch code setting the sysAppLaunchFlagNewGlobals and sysAppLaunchFlagUIApp
flags? The SDK documentation says that apps shouldn't present a UI and
shouldn't use globals when they receive this launch code, so are the flags
at all useful in this context?
I'm sure there must be a good reason, but these flags can be a bit annoying.
Many applications I've seen follow a structure similar to:
UInt32 PilotMain(UInt16 cmd, void* cmdPBP, UInt16 launchFlags)
{
Err error;
error = RomVersionCompatible(ourMinVersion, launchFlags);
if (error) { return (UInt32) error; }
switch (cmd)
{
/* ... */
}
return errNone;
}
where RomVersionCompatible is similar or identical to the implementation in
the SDK sample code. The typical version presents an alert only if the ROM
version isn't compatible and if the NewGlobals and UIApp flags are set.
Suppose you try to run such an application from an expansion card on an
earlier version of the OS. RomVersionCompatible sees the flags, thinks it
has a UI, and presents an error alert.
Worse, the system then follows the sysAppLaunchCmdCardLaunch launch code
with sysAppLaunchCmdNormalLaunch, so the ROM incompatible alert gets
presented twice.
It's avoidable, but all the workarounds I've thought of involve making
special exceptions for sysAppLaunchCmdCardLaunch, which rubs me the wrong
way. (Since it's such an insignificant, minor issue, though, I think I'll
put up with the duplicate ROM incompatible alerts.)
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
