# 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
This archive was generated by hypermail 2b29 : Tue Apr 08 2003 - 16:59:05 EDT