Re: Differences between Palm Emulator and real hardware
At 11:29 AM +0100 9/7/03, Ben Summers wrote: I've made a few changes to the way my application works, and added "save behind" to all my forms, and now it seems to be working fine. Make sure to uncheck that option and retest. Your application should still work without drawing problems. If it doesn't, there's still some bug in there, hidden by the "save behind" option. Remember that the "save behind" option is an optimization flag, and that the OS does not guarantee that it will save the underlying bits (for instance, there may not be enough memory to do so). In that circumstance, your application should still draw correctly. If it doesn't, you've got a bug. -- Keith -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Differences between Palm Emulator and real hardware
Ken Krugler <[EMAIL PROTECTED]> wrote: >I'm noticing some real differences between the Palm emulator (emulating a >Palm Vx) and the real hardware. > >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. And some events >seem to be in a different order, so I my application gets unexpected things >happening and dies. > >Works fine on the real thing, and on the OS 5 simulator. As Keith noted, one big difference is that "the real thing" is using a release ROM, while I'm guessing you're using a debug ROM with POSE (or you should be). There's an old problem I'd also run into with the order of events on debug vs. release ROMs. My notes are below. -- Ken Summary: On debug ROMs, you get a frmOpenEvent, then a winEnterEvent. On release ROMs, you get a winEnterEvent, then the frmOpenEvent. Ah, I think that might have a bit to do with things. I've made a few changes to the way my application works, and added "save behind" to all my forms, and now it seems to be working fine. 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/
Re: Differences between Palm Emulator and real hardware
I'm noticing some real differences between the Palm emulator (emulating a Palm Vx) and the real hardware. 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. And some events seem to be in a different order, so I my application gets unexpected things happening and dies. Works fine on the real thing, and on the OS 5 simulator. As Keith noted, one big difference is that "the real thing" is using a release ROM, while I'm guessing you're using a debug ROM with POSE (or you should be). There's an old problem I'd also run into with the order of events on debug vs. release ROMs. My notes are below. -- Ken Summary: On debug ROMs, you get a frmOpenEvent, then a winEnterEvent. On release ROMs, you get a winEnterEvent, then the frmOpenEvent. Explanation: 1. I call FrmPopupForm(1200), and that enqueues a frmLoadEvent and then a frmOpenEvent. 2. When I get the frmLoadEvent, I call FrmInitForm(1200) and then FrmSetActiveForm with the resulting form pointer. 3. On a release ROM, FrmSetActiveForm calls WinSetActiveWindow with the form handle, which sets up the low-memory EnterWindowID global. On a debug ROM, the call to WinSetActiveWindow only gets made if the form is already visible, which is not the case for my form. 4. The next time I call EvtGetEvent, it sees that EnterWindowID is non-NULL, and returns back a winEnterEvent. This occurs even though the frmOpenEvent is still sitting in the queue. -- Ken Krugler -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
Re: Differences between Palm Emulator and real hardware
Keith Rollin <[EMAIL PROTECTED]> wrote: 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] >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? As the Address Book doesn't do it for the lookup popup form, I thought I'd be OK. 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/
Re: Differences between Palm Emulator and real hardware
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. 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/
Re: Differences between Palm Emulator and real hardware
Pose attempts to break your app on purpose. If you fix your code so the dialog displays correctly on Pose, it will always work on the device. You've just lucked out that your non-standard methods don't break on the actual device. - Original Message - From: "Ben Summers" <[EMAIL PROTECTED]> To: "Palm Developer Forum" <[EMAIL PROTECTED]> Sent: Wednesday, September 03, 2003 3:43 AM Subject: Differences between Palm Emulator and real hardware > > Hi, > > I'm noticing some real differences between the Palm emulator (emulating a > Palm Vx) and the real hardware. > > 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. And some events > seem to be in a different order, so I my application gets unexpected things > happening and dies. > > Works fine on the real thing, and on the OS 5 simulator. -- For information on using the Palm Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
