# To subscribers of the xforms list from jac@casurgica.com :
> Thus, I suspect that if you add a line
> fl_handle_object(obj, FL_MOVEORIGIN, 0, 0, 0, 0);
> to fl_set_object_position then things will 'just work'.
When you get something to "just work" that usually translates to "you
don't know how the stuff works to begin with, so you hacked something in
that will work until somebody changes something". I don't really like
that... heh.
> Best of luck and let us know what happens ;-)
So I've been looking through tabfolder.c. If you look through the code,
you will not find one line *anywhere* that is like "sp->canvas->x =
something" or "fl_set_object_position(sp->canvas, something)". The canvas
X position is never set anywhere except for the fl_create_canvas() call in
fl_create_tabfolder(). Guess whoever wrote this overlooked that part...
Down in compute_top_position(), the end of it is:
sp->canvas->y = sp->y + max_h - (ob->bw < 0);
sp->canvas->h = ob->h - max_h - FL_abs(ob->bw) - 1;
It sets the y position right, just never does it for x. If you insert the
following line before that code:
sp->canvas->x = ob->x;
The problem is somewhat fixed (except the background behind the tab folder
is in the wrong place, so it leaves a little bit of a mess in it's
previous position after you move it). The reason you have to use ob->x
rather than sp->x (note that sp->y is used when setting sp->canvas->y) is
because sp->x is used pretty much as a temporary variable in the loop just
before that code to keep track of incremental tab positions when
calculating where the tabs should be drawn (this should be fixed so that
sp->x is not modified here... the fact that sp->y is used when calc'ing
the canvas position indicates that the purpose of sp->x and sp->y is to
keep track of where the object is, rather than as dummy variables to hold
incremental values).
That *is* the correct fix... or at least, it's consistent with where the
canvas Y position is set. However, two problems now remain:
1) Cleaning up the background box behind the tab folder.
2) Bottom tabfolders are even weirder. Here's the bugs in those:
- The Y position is handled correctly. The X position is only applied to
the tabs, so when you move the bottom tabfolder left or write, only the
tabs move, not the folder itself.
- When total width of all the tabs exceeds the width of the tabfolder,
rather than not drawing the ones that don't fit, it just draws them all
and the tabs go off the right side of the folder.
- When you select certain tabs (can't figure out a pattern yet), the tab
folder moves down! Weird. It's Y position is incremented by it's height.
Must be a typo in the code somewhere.
More to come, then I'll send a patch. I find it hard to believe that the
person that wrote this stuff never tried to call fl_set_object_position on
a tab folder...
Still testing those get_next_event() fixes, btw, then I'll send a patch
for that, too.
Jason Cipriani
_________________________________________________
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 : Fri Apr 25 2003 - 12:51:05 EDT