Adding to what Dave Lippincott said:
At 8:43 AM +0100 9/3/03, Ben Summers wrote: >I'm noticing some real differences between the Palm emulator >(emulating a Palm Vx) and the real hardware.
Yes, there are differences. In general Poser is a superset of a real device. There are some cases where some underlying hardware is not emulated, but that should be transparent to most well-written applications.
>The most obvious thing is that forms aren't drawn properly -- you >see the previous form "through" the pop up form, as if the >background of the form isn't being drawn before the new form is >drawn over it.
This is probably due to using debug ROMs. They try to flush out applications that don't handle frmUpdate events like they should. Never rely on the "restore previous form contents" mechanism to work! It may not be possible to restore the previous form due to low-memory conditions, and you'll have to handle an explicit frmUpdate event.
I'm actually doing quite a lot of FrmDrawForm() calls. But always on the emulator, it draws the form without wiping the background (not drawing a white rectangle over which the items are drawn) so the previous one shows through.
>And some events seem to be in a different order, so I my application >gets unexpected things happening and dies.
Not sure what you're seeing here. I can't think of any events that are typically sent in a different order, so I can't explain what you're seeing. But it does highlight that you're making an assumption that may not be valid, and that your application may need to be more robust.
I suspect you're right...
[snip]
As the Address Book doesn't do it for the lookup popup form, I thought I'd be OK.>In particular, I do not use FrmDispatchEvent(), but use >FrmHandleEvent() directly, keeping track of which form is currently >active so I can call the right event handler before resorting to >FrmHandleEvent().
I hope you have the Palm OS source code, and are making you aren't chopping out any critical OS functionality by eschewing FrmDispatchEvent. For instance, that function makes sure that FEPs and the Text Services Manager are given a chance at the event; does your replacement do that?
Still, I've changed over to doing it properly (and having to use static data) and I still have this problem.
I was just wondering if anyone else had seen anything like it.
Thanks for the help,
Ben
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
