Steve Lamont wrote:
>
> # To subscribers of the xforms list from spl@szechuan.ucsd.edu (Steve Lamont) :
>
> > In other words what I saw was expected behaviour. That just leaves one
> > question in my mind. If it's not giving away too much about the form
> > library code, how does the browser get away with resizing itself and not
> > causing the form to be redrawn? In other words taking out the
> > fl_set_object_size line in my example code doesn't cause the yellow
> > triangle to disappear, so the browser must be doing something other than
> > a fl_set_object_size when it needs to resize itself.
>
> First of all, I don't think any of the internals of XForms are
> particularly secret or proprietary -- it's just that TC and Mark want
> to keep tight control of the source -- that's why source isn't
> released.
>
> I may have slightly misinformed you or misspoke if I led you to
> believe that it's the fl_freeze_form() and fl_unfreeze_form() that's
> causing your triangle to disappear. It's the fact that if you have
> the fl_set_object_size() function call, this requires a full redraw of
> all objects in the form -- thus causing the Window to be cleared. So
> anything drawn with the fl_drw*() functions will be erased.
>
> > The reason why I'm asking is that I was going to take your advice about
> > using the browser instead of the fselector object(see my message "Using
> > fselector for other than files"). But I realized it couldn't do
> > something I wanted it to, or at least I don't think it can, please
> > correct me if I'm wrong. 1) I wanted to be able to use symbols in the
> > browser, I tried doing a fl_add_browser_line with the text set to "@>"
> > but the triangle didn't get output. 2) I wanted to use text of different
> > colors in the browser, more specifically I wanted a symbol at the
> > beginning of the line in one color and the text in a different color.
>
> This is something that I've been toying with as well -- at least
> conceptually. No, the browser can't do what you want so you'll have
> to cruft up something on your own.
>
> You'll have to create your own object.
>
> In this case, using the fl_drw*() functions *will* work if you use
> them properly. They should be called from your FL_DRAW event
> handler. That way they'll be called every time the browser needs
> updating.
>
> Refer to the manual section on creating your own objects (and, also,
> the section on Free objects, since "roll your own" objects and Free
> objects are quite similar in design and nature.
>
Ok. I have to apologize I realize I cluttered up my question with too
much extraneous information. Furthermore, after more testing I realized
that my problem comes down to how to create a composite object. I
realize the API to composite objects isn't really finalized and so I
don't really want to use that scheme. In fact I had started this before
I read anything about composite objects. What I really would like to
know is how the current browser manages the sizing and display between
its "text" area and its scrollbars.
I have more than a couple of problems with this but these two are a good
start. Let's just start with something simple. In my test form I do a
call like this,
fl_add_fancybrowser(....)
this call makes a call to
obj = fl_create_fancybrowser
fl_add_object(fl_currentform,obj);
fl_add_scrollbar(....) /* add vertical scrollbar */
fl_add_scrollbar(....) /* add horizontal scrollbar */
There's some details missing above but the gist is this. Without doing
anything else, if I don't hide the scrollbars the form comes up with a
"text" area surrounded by 2 scrollbars. But as soon as I click on one of
the scrollbars I get a weirded up display, the scrollbars disappear but
I can "find" the little slider and directional buttons if I move the
mouse over them. Note that I don't change the bounding box size when I
create my fancybrowser so maybe this is causing a problem. So... is the
bounding box of the browser supposed to remain the complete size of the
browser or is it only the size of the "text" area? In fact the only
success I've had with this comes when I shrink the bounding box of the
browser to the "text" area in which case the scrollbars will show
correctly but then that leads to problem 2.
If the form my browser is on is resized than my browser will get
resized. If I don't respond to any low level X events how in the world
do I communicate the size changes between my objects without making
calls like fl_set_object_size or fl_redraw_object etc.
when responding to the FL_DRAW event. I put this restriction on myself
since the manual says you must stick to only fl_drw type commands. I
thought of adding a free object area for the "text" area and sticking
everything in a group. This seemed to hold some promise until I
remembered the manual says you can't nest groups which would mean that I
couldn't do something like this,
fl_bgn_group()
fl_add_fancybrowser(...) /* internally makes a group */
/* add some other objects */
fl_end_group()
or am I mistaken?
I just don't seem to get it.
Note that I've already written all the code necessary to make the
browser work in a static form, i.e. as long as the form doesn't get
resized I can make the browser work perfectly. It's when I try to
account for external resizing that I can't see my way clear.
Help with this would be greatly appreciated as I'm at a total loss.
Thanks.
-- Gerald Gryschuk(ggryschuk@scf.sk.ca) Programmer Analyst Saskatoon Cancer Centre ((306)655-2746) _________________________________________________ To unsubscribe, send the message "unsubscribe" to xforms-request@bob.usuf2.usuhs.mil or see http://bob.usuf2.usuhs.mil/mailserv/xforms.html XForms Home Page: http://bragg.phys.uwm.edu/xforms List Archive: http://bob.usuf2.usuhs.mil/mailserv/list-archives/