> >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.

Exactly! There is no legal way to do this. From what I can tell of your setup, you're 
not doing anything wrong, as you can't control what it on screen when your FrmAlert() 
is invoked.

I am sure that I do something similar in some instance. In fact, as far as I can tell, 
any application which uses a Popup list is at risk, as an alarm or something behind 
its back could be triggered. In my case, I use the WINDOW manager to have an EXTRA 
window on screen to handle a certain aspect of rendering UI in my app.

> >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.

Here's the idea; there's the WINDOW manager, which allows apps to use windows in their 
apps to draw things. Also, the OS uses them for things like Popup Lists...  there is 
no messaging in the window API, such as the ability to tell a WINDOW to redraw itself.

Now, FORMS are specialized structures which 'own' windows. Thus, if the OS can 
reasonable assume that a form's contents have been altered outside of the form's 
knowledge (as what happens when a MODAL form doesn't restore the screen underneath 
itself on dismissal), the OS sends a frmUpdateEvent to the FORM, which knows how to 
redraw the window (the event handler's response to the event is to redraw the form) 
that contains its contents so that the UI is restored.

Forgive me if you already understood this difference b/w forms and windows, but this 
is the difference which causes the problem in the first place!

Hope this helps... actually I know it doesn't help the situation, but maybe it helps 
you understand it!

Alan

>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


-- 
For information on using the Palm Developer Forums, or to unsubscribe, please see 
http://www.palm.com/devzone/mailinglists.html

Reply via email to