> I have a little problem and would like to hear your comments. When
>executed during standard frmLoad event, the following code (the only one in
>a new PalmOS project) causes crash on the Visor ROM and on an actual
>Platinium, while working perfectly fine on all other tested roms, including
>the OS40DR5Dbg.
>
>static void MainFormInit(FormPtr frmP)
>{
> ListPtr lst;
>
> LstNewList((void**)&frmP, 5010,
> 10, 40, 100, 40,
> stdFont, 2, 0);
>
> LstNewList((void**)&frmP, 5011,
> 10, 40, 100, 40,
> stdFont, 2, 0);
>}
>
> This is not the only, but probably the best sample of the problem when
>dealing with dynamic UI on that particular ROM. My investigations lead me to
>believe the problem is in the ROM build and not in the program. Any comments
>from others with similar experience? As far as I can tell, all programs
>doing dynamic UI [form controls] must be affected.
1. Problems with dynamic UI occur when the form chunk has to move due
to not being able to grow in-place in the dynamic heap. So one
possible explanation of why it dies on the Visor, but not on other
devices, is that the Visor's memory configuration is such that the
form chunk needs to move when you're testing on a Visor ROM, but not
on other ROMs.
A quick way to check would be to flag whether the address of the form
chunk is indeed changing when (and only when) you get a crash.
2. The Visor Platinum ROMs have a patch to the dynamic form UI code,
to fix some of the known bugs in 3.5. Unfortunately this patch
doesn't fix all of the problems, and actually adds one new case where
Poser catches it reading beyond the end of the form chunk. So you
might have come across a Visor-specific bug.
3. You say that the code "causes crash". What kind of crash, and
where exactly? On the second call to LstNewList? Someplace else in
your app? Is this a Poser warning or an OS fatal alert?
4. One gotcha with the dynamic UI is if you're adding objects to a
form when it's first created (before the main event loop has had time
to realize that a new window is getting activated), then there's a
bug in the ROM where a low-memory global isn't getting updated if the
form chunk has to move. So what happens is that during a subsequent
call to SysHandleEvent, WinSetDrawWindow will be called with the old
(invalid) form address.
The work-around I'm using is to catch the case when the form ptr
changes as a result of adding something (during this specific
initialization case), and call WinSetActiveWindow(NULL), then
WinSetActiveWindow(FrmGetWindowHandle(mFormP)), where mFormP is the
new form ptr.
5. A common source of dynamic UI bugs is to have a stale UI object
address. For example, if you previously called FrmGetObjectPtr to get
a field or control pointer, then added anything to the form that
caused it to move, these object addresses are no longer valid.
6. Finally, I'm assuming that the caller of MainFormInit isn't
relying on the form address it's passing in. Your calls to LstNewList
will update the value of the form pointer that's on the stack frame,
but the caller's copy won't be getting updated.
-- 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/tech/support/forums/
