I received a private reply (thanks to Ken Krugler of Transpac Software, Inc.) on this problem, and Ken pointed me to what's evidently the problem, since (a variant of) the workaround he suggested makes the symptoms go away.
I forgot to mention a crucial point in the initial report: we're running in 4-bit color (er, grayscale) mode. Anyway, according to Ken, the problem is a bug in the bit-blit code in Palm OS 3.5, in which a color table incorrectly gets freed under some circumstances when the source in a blit operation is a bitmap without its own color table. I attacked the problem by adding some rather weird code to our application's handler for frmOpenEvent: if the OS is 3.5, look at the "bitsBehindForm" window of the form being opened. If that window's bitmap is of 4-bit depth and doesn't have a color table (it never does), I replace the bitmap with a new one that *does* have a color table (derived from the current color palette). Seems to make the problem go away. So what's my beef now? First, this seems like an awfully heavy-handed solution. Second, I'm not *really* sure that it's right (an awful lot of guesswork went into crafting it). Third, I'm worried that attaching a color table to the bitsBehind form is impacting performance of the app. And fourth, and most importantly, the operation requires direct accesses to the fields of a FormType structure, so to run the app under the Emulator, we now have to turnn off "UIMgr data access" checks, which I'd dearly love to be able to leave on. Can anyone else confirm or deny any of the guesswork, or suggest a better solution? Thanks, Greg Lutz NearSpace, Inc. >[...] >Under a very specific set of circumstances, [a] >send-to-address-book operation results in data corruption. The >circumstances include: > > - Using the application menu (rather than an available button) > to initiate the send. > > - Opening the application menu by tapping the application menu > icon, not the form title. > > - Doing the whole send twice. > > - Following it up by bringing up a Note dialog. > >The symptom, which we observe on the Palm Emulator running a >non-debug Palm OS 3.5 ROM, is this error alert from the Emulator: > > >NearSpace (unknown version) just wrote to memory location >0x........, which is in Memory Manager data structures. > > >The call stack at the time of the alert looks like this: > > >__Startup__ >PilotMain >StarterPilotMain >normalLaunch [part of our application] >AppEventLoop >PrvSendEventToForm >FrmHandleEvent >FrmEraseForm >WinRestoreBits >WinCopyRectangle >BltCopyRectangle >BltCopyRectangle >PrvCompressedInnerBitBlt... -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
