Alan Pinstein <[EMAIL PROTECTED]>m wrote:
>Yes, this is a very interesting issue! It totally makes sense:
Geez, I wish I'd seen Keith's original reply in its entirety. For whatever
reason, perhaps because of the listserv changeover, I'd never seen anyone
from Palm responding to this issue before. So please allow me to correct
my previous statements: apparently Palm *has* replied to this issue, I've
just never seen the response. ;-)
>>But I am wondering how you plan on updating a window when there's no form
>>handler for it and so no frmUpdateEvent can be sent to it.
Keith maybe I'm missing something here (in fact, I'm almost certainly
missing something here...). I'm calling a FrmAlert to the screen when my
application may or may not be current. AFAIK, that's legal. And I'm
testing the result of which button the user pushed, also legal, isn't it?
I don't try to update, repaint, or change the alert. Heck, it's not even a
custom alert. ;-)
>that it's an assert for a UI condition which could be bad (as I think the
3.5 debug ROMs NEVER restore windows under forms in order to show
developers where redraws are not being done correctly). However, MANY MANY
apps do this, and there needs to be an approved solution for this! I don't
recall seeing any warnings to NOT use windows in apps, and thus I've done
this, and now appear to be painted into a corner! In Launch 'Em, the entire
icon rendering area is a window, as the Window manager conveniently does
all of my draw clipping for me! I thought that this was totally legit....
Alan, forgive me for being thick, but are you doing something similar here?
I'm simply using a standard API call, FrmAlert() to slap a message on the
screen. As far as I can tell, there's no legal way to do this when there's
a List open on screen.
>Any Palm-originating advice would be GREATLY appreciated on this issue!
I'd be happy with a more complete explanation of what bad behaviour I've
programmed into my app when Palm's own Date Book application (version 3.5
on OS 3.5) does precisely the same thing.
Keith Rollin wrote:
>> "Form.c, Line 801, Windows cannot be under forms because
>> they can't be redrawn"
>>
>>When you see messages in this form, it's not because of Poser. It's because
>>some application or part of the OS has called ErrDisplayFileLineMessage. In
>>this case, it's obviously the Form Manager.
Sorry. Should have included more of the message obviously. And yes, it's
obvious that the assert is from Form.c.
>>Just so you know it's not a case of Poser being overly enthusiastic.
POSE is rarely, if ever, wrong in my experience.
>>As for what's causing that message and how to avoid it, I'm no expert on
that.
>>But I am wondering how you plan on updating a window when there's no form
>>handler for it and so no frmUpdateEvent can be sent to it.
I don't. I'm doing the same thing that Palm's Datebook application is
doing. And Palm's own Datebook fails in exactly the same way with exactly
the same message:
"Date Book" 3.5 reports "Form.c, Line:801, Windows cannot be under forms
because they can't be redrawn." If this is the latest version of "Date
Book", please report this to the application author.
So what I'm asking is, will Palm be changing its Date Book code to prevent
this error and if so, how? I'd like to know so that I can make the same
changes. I don't have the OS 3.5 source to look at.
Cheers,
--
Andrew Ball
[EMAIL PROTECTED]
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
