Re: [XForms] Small Bug

[Jens Thoms Toerring]

Hi Serge,

On Sat, Nov 02, 2013 at 08:14:41AM -0400, Serge Bromow wrote:
> I just finished testing 94pre20. All went without incident but for
> these 2 problems;
> 
> 1) Calling "fl_get_browser_topline(" on on empty browser abends. The
> problem is in "fli_tbox_get_topline(" when the var "sp->def_height"
> == 0. The following line is the culprit;
> 
> int i = FL_min( sp->yoffset / sp->def_height, sp->num_lines - 1);
> (div/0) thing.

Uuups, I definittely should have known better:-( Thank you
very much, it's fixed.

> Interesting is the program does not fault using GCC 4.5.1 but does
> under 4.7.2. Go figure.

Possible explanation: it looks like sp->def_height in this case
is used before having been assigned a value. So the random
value it has in that case can depend on lots of circumstances,
one of them being the compiler version (but it also may be
pure chance).

> 2) When using a tab folder the tabs label colors are always BLACK
> even though I have set the color to WHITE in both the folder and the
> forms placed in the folder.
> 
> Any thoughts?

How do you set the label color for the individual forms?
You need to call fl_set_object_lcolor() on the object
returned by fl_addto_tabfolder() (which returns the button
object that makes up the tab rider for that form) - and that
works correctly for me. Calling fl_set_object_lcolor() on
the folder object itself didn't work due to a bug which I
hopefully have fixed now. For the other similar functions
it seems to work properly.

Please note the calling fl_set_object_lcol() (and all simi-
lar functions) on the folder object will (or at least should;-)
set these properties for all the tab riders, even if something
different had been set for individual riders - these settings
get overridden.

> And last, I was wondering if you would mind if we added string
> formatting to certain functions. The same approach as "printf(".
> 
> i.e.   fl_set_object_label(FL_OBJECT *ob, const char *label)  TO
>         fl_set_object_label(FL_OBJECT *ob, const char *format, ...)
> 
> This would save pre formatting strings before submitting them to the
> functions.

> Others would be fl_set_input, fl_set_form_title, etc. Anything that
> takes a string as an argument. This should not disturb current code
> that uses fixed strings but would add flexibility in the future.

Nice idea and probably not hard to implement;-) Well, the only
proble I can see is that there's a huge number of such functions
(e.g. all the functions of the type fl_add_xxx(), where xxx is
an object type). And, of course, the documentation must be
updated accordingly. But I'll take a look, starting with
trying to figure out which functions there are that would
require  modification.

> I can provide the code to you so it should only be a copy and paste
> for you. There is one problem that I can see;
> 
> fl_set_object_label( FL_OBJECT  * obj, *const char *format, ... *)
> {
> *va_list argp;**
> ***
> int need_show = 0;
> 
> *char buf[512], *label;*
> 
> if ( ! obj ) {
>     M_err( "fl_set_object_label", "NULL object" );
>     return;
>     }
> 
> *va_start(argp, format);**
> **vsprintf(buf, format,  argp);**
> **va_end(argp);*
> 
> *label = buf;*
> 
> // Rest of code stays the same
> }
> 
> The problem is the buffer has to be set to some maximum size since
> we do not know the size of the resulting string. I would think 512
> chars would be adequate but can't be sure. Any thoughts on how to
> solve this problem?

I don't like fixed-sized buffers, so I'd prefer something
that allocates memory as needed. That isn't a real problem
since an asprintf() function is already available (and I
somewhere definitely have a function like that if the
built in asprintf() function won't do). I've got to play
around with the idea;-)

                 Thank you and best regards, Jens
-- 
  \   Jens Thoms Toerring  ________      address@hidden
   \_______________________________      http://toerring.de