# To subscribers of the xforms list from bpm@direct.ca :
To : Angus
Please remove us from your mailing list.
Thank You !
----- Original Message -----
From: "Angus Leeming" <angus.leeming@btopenworld.com>
To: <xforms@bob.usuhs.mil>
Sent: Tuesday, April 08, 2003 2:53 AM
Subject: Re: XForms: Drawing in the browser prehandler (bug?)
> # To subscribers of the xforms list from Angus Leeming
<angus.leeming@btopenworld.com> :
>
> On Tuesday 08 April 2003 12:47 am, jac@casurgica.com wrote:
> > - Browser prehandler called from fl_handle_it(). This is the one that
does
> > not behave correctly.
> > - Browser's textbox prehandler called from fl_handle_it, which in turn
> > causes browser's prehandler to be called (via tbpre). This is the one
that
> > *does* draw correctly.
> >
> > Note that that's twice that the browser's prehandler got called.
>
> As I understand things, xforms was designed for "simple" widgets and these
> "composite" ones were added later. There are lots of small iritations
still
> present. F.ex, tooltips are not displayed in the browser (I have a patch
> which will propogate into cvs presently). The most complex of these
> "composite" widgets is the tabfolder and _lots_ of things go wrong with
it.
> F.ex, resizing it does _not_ lead to a resize of the widgets on it. Again,
I
> have a patch which works but exposes the tabfolder's internals to forms.c.
> This is the wrong thing to do IMO, but we probably need new FL_DO_XYZ
> additions to the event enum to move stuff back into tabfolder.c.
>
> > It's very confusing to me because this is the first time I've ever
looked
> > very hard at the forms library source. Maybe this is a better way to
> > explain what is going on: The browser is made up of a textbox and some
> > scrollbars. When you repaint the browser explicitly (like you do it
> > yourself, or it gets repainted by the scrollbars changing or whatever),
> > FL_DRAW events are sent to only the component parts (the textbox and
> > scrollbars), NOT to the "browser" itself (which doesn't actually have
any
> > drawing code of it's own... it's all done by the component parts).
> > However, when the browser is exposed, since the browser (when I say
> > browser, I'm referring to the parent object of these component parts),
is
> > an object, and since it's on a form, an FL_DRAW event is sent to the
> > *browser*, too (along with all of it's component objects). This FL_DRAW,
> > sent to the "invisible" browser rather than directly to it's component
> > objects is the one that is causing the problem.
>
> I'm sure that it is something like that. Actually, I bet that FL_DRAW _is_
> passed to the browser's handler (but it just passes through). This is the
> right thing IMO. forms.c should know nothing about the internals of the
> browser.
>
> The problem lies in calling the correct prehandler (this is sort of
bolt-on
> code and probably hasn't been as well tested). We may need to encapsulate
the
> calls so that the browser itself does it. Ie, add FL_CALL_PREHANDLER to
the
> event enum and handle it in the browser's handle_it.
>
> I'm learning too...
> Angus
> _________________________________________________
> To unsubscribe, send the message "unsubscribe" to
> xforms-request@bob.usuhs.mil or see
> http://bob.usuhs.mil/mailserv/xforms.html
> XForms Home Page: http://world.std.com/~xforms
> List Archive: http://bob.usuhs.mil/mailserv/list-archives/
> Development: http://savannah.nongnu.org/files/?group=xforms
>
_________________________________________________
To unsubscribe, send the message "unsubscribe" to
xforms-request@bob.usuhs.mil or see
http://bob.usuhs.mil/mailserv/xforms.html
XForms Home Page: http://world.std.com/~xforms
List Archive: http://bob.usuhs.mil/mailserv/list-archives/
Development: http://savannah.nongnu.org/files/?group=xforms
This archive was generated by hypermail 2b29 : Wed Apr 09 2003 - 10:23:33 EDT