Hi Greg,
>My company has an application that, among other things, allows
>the user to convey an address from its own database to the Palm
>address book, for which we use the Exchange Manager.
>
>When this operation is performed under Palm OS 3.5, the Exchange
>Manager's progress dialog is activated (a control bit in
>ExgSocketType, "noStatus", which can suppress this dialog, has no
>effect in Palm OS 3.5), then immediately hidden by the Address
>Book's confirmation dialog ("do you want to accept Xxxx into
>Address?"). When the user dismisses the confirmation dialog with
>a "Yes", the progress dialog is again visible for a moment before
>the Exchange Manager closes it. We use the ExgSocketType flag
>bit "noGoTo" to avoid actually launching the Address application.
>
>Under a very specific set of circumstances, the
>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
[snip]
>We'd be interested in anyone's idea of whether an operating
>system bug might be involved, and would welcome any suggestions
>for a workaround. Not that we're too worried about real users
>performing the requisite weird sequence of operations, but we'd
>like Gremlins to run for a while!
I'd run into a similar bug w/3.5 ROMs. The problem occurred the
second time I called WinCopyRectangle, when I was copying from the
screen to a bitmap window that didn't have a color table. The bug was
in the low-level blitter code, where a color translation table was
getting improperly disposed of at the end of the first call, thus the
second call failed. My call stack looked like:
>Current UI App stack: size = #3536, amount never used = #2528
>Calling chain using A6 Links:
> A6 Frame Frame Size Caller
> 0003D27A #0000000044 00047092 PilotMain+001C
> 0003D208 #0000000114 00046F86 EventLoop__Fv+005A
> 0003D1DE #0000000042 10C697F8 FrmDispatchEvent+0046
> 0003D1C2 #0000000028 10C65E64 PrvSendEventToForm+0024
> 0003D1AA #0000000024 000496A2 SignatureFormHandleEvent__FP9Ev+006E
> 0003D176 #0000000052 000494AC HandlePenDownEvent__FPC9EventTy+009C
> 0003D14C #0000000042 10C55E52 WinCopyRectangle+0170
> 0003D0EC #0000000096 10C4E0C2 BltCopyRectangle+0152
> 0003D0B2 #0000000058 10C518A6 PrvMisAlignedForwardInnerBitBlt+0860
> 0003CFD4 #0000000222 10C53EDE PrvConvert8To1+0030
There are enough similarities that it _might_ be the same bug. The
way I worked around it in my code was that I created the bitmap used
by the destination window with a color table that had two entries,
with white at index 0 and black at index 1.
-- Ken
--
Ken Krugler
TransPac Software, Inc.
<http://www.transpac.com>
+1 530-470-9200
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/support/forums/
