Your description triggered my memory. :)
You've found a bug in WinScreenLock that only exposes itself on 8MB devices.
On the DragonBall EZ, the buffer for the LCD mustn't cross a 4MB boundary.
There is one such boundary on 8MB devices. WinScreenLock didn't do anything
to ensure that this boundary wasn't crossed. This was fixed in Palm OS 4.0.
The higher screen depth increases the size of the LCD buffer, making it more
likely to cross the boundary (but it can still happen, even in 1-bit mode).
Allocations in your app will change the layout of available memory, changing
where the LCD buffer gets allocated.
The reason that you're seeing this when beaming (or receiving) is that the
Progress Manager uses WinScreenLock/Unlock to avoid flicker when it
animates.
The workaround is to allocate a small chunk of memory across the boundary
when your app starts. To do this, keep allocating chunks (via MemPtrNew)
until one crosses the boundary. (Touching the boundary is actually good
enough.) Then free all but the last one. You can either free the last chunk
when your app exits or you can set its owner to "system" and leave the fix
in for everyone else. You'll need to handle the possibility that a chunk has
already been allocated across the boundary when your app starts too. Pretty
ugly, but a workable workaround. :)
The bug probably doesn't appear in Poser because it's not emulating the
behavior of the EZ down to that level of detail. What the EZ does when you
place the LCD buffer across a 4MB boundary isn't documented; you're just not
supposed to do it. So Poser can't emulate the weird effects you see on a
real device without knowing "too much" about the EZ. What Poser could do is
complain when it sees an LCD buffer that doesn't conform to the processor's
rules. Of course, that would expose the bug in Palm OS 3.5, but that's the
whole point, after all.
--
Danny @ Palm
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palmos.com/dev/tech/support/forums/
