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.
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.
Works fine on the real thing, and on the OS 5 simulator.
Saying it works fine on the real thing should never be a defense! :-) Poser catches lots of errors that slide by unnoticed on a real device. For instance, if you hand the following code in your application:
UInt32* myPtr = NULL;
...<300 lines of code>...
*myPtr = 0;You may not notice that myPtr never got initialized, and would end up writing to memory location zero. This would not be noticed on a real device, but it is an error, and Poser will flag it as such.
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?
-- Keith Rollin -- Palm OS Emulator engineer
-- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
