Fl_Hold_Browser

[holm.h...@gmail.com]

Hello,

I have the following code :

      { Fl_Hold_Browser* o = new Fl_Hold_Browser(xs+200, ys, 200, 300);
        for (i=0;i<100;i++){
          char s[256];
          sprintf(s, "number %d\n", i);
          o->add(s);
        }
        o->end();
      }

The scrollbar will however only scroll the 73 first items.
If I loop to 1000 (instead of 100) the I can scroll the 734 first items.

The code work fine in a small example code, but not in my application.

Do any have a tip of what may cause this / how to fix ?

Best regards
Håvard

[Albrecht Schlosser]

Please post complete (compileable) example code and your FLTK version.
This may be important.

That said, I have a vague recollection that this can have to do with the
line height and/or line spacing in the browser.

Some ideas what/how to test:

You may want to set one or the other (sorry, I don't know exactly which
methods right now). Order can be significant!

Make the window resizable and see what happens when the window (browser)
gets resized. Does this "fix" it?

If it's something like that a small demo program would help us to test
and fix it (together with your findings and maybe test instructions).

[holm.h...@gmail.com]

Thanks, you pointed me to the right way: it seems to be related to font/sizing. I still have not made a working small example where the problem is exposed, but will try to make one.

Best regards
Håvard

[Greg Ercolano]

On 2020-09-10 04:18, holm.h...@gmail.com wrote:
> Thanks, you pointed me to the right way: it seems to be related to font/sizing. I still have not made a working small example where the problem is exposed, but will try to make one.
>

I couldn't replicate, but I did make this which seems to work OK.

#include <stdio.h>
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Hold_Browser.H>
int main(int argc, char *argv[]) {
Fl_Double_Window *win = new Fl_Double_Window(250, 350, "Simple Browser");
win->begin();
{
// Create Hold Browser
Fl_Hold_Browser *hold = new Fl_Hold_Browser(10, 10, 200, 300, "Hold");
char s[256];
for (int i=0; i<100; i++) {

sprintf(s, "number %d\n", i);

hold->add(s);
}
hold->end();
}
win->end();
win->resizable(win);
win->show(argc, argv);
return(Fl::run());
}

[holm.h...@gmail.com]

Here is a small program, where my problem is exposed. I use the Set_Font routine to recusively set font in my program.

Do anyone see the problem in my code ? The browser do not show all entries.

#include <stdio.h>
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>
#include <FL/Fl_Hold_Browser.H>
#include <FL/Fl.H>
#include <FL/Fl_Double_Window.H>

#include <FL/Fl_Button.H>
#include <FL/Fl_Input.H>
#include <FL/Fl_Counter.H>
#include <FL/Fl_Preferences.H>
#include <FL/Fl_XPM_Image.H>
#include <FL/Fl_XBM_Image.H>
#include <FL/Fl_Tiled_Image.H>
#include <FL/fl_draw.H>

Fl_Double_Window *Win;
Fl_Hold_Browser *B;

void Set_Font_Size(Fl_Widget* pWdg, int Labelsize, int Textsize, int lev){
  int i;
 
  pWdg->labelsize(Labelsize);
  if (Fl_Browser_*          pB= dynamic_cast< Fl_Browser_* >(pWdg))        pB->textsize(Textsize);
 
  if (Fl_Group* pG= dynamic_cast< Fl_Group* >(pWdg)){
    for (int i= 0; i< pG->children(); ++i)    Set_Font_Size(pG->child(i), Labelsize, Textsize, 1);
  }
 
  return;
}

int main() {
  char s[256];
  int i;
 
  Win = new Fl_Double_Window(200,400);
  { Fl_Hold_Browser* o = B = new Fl_Hold_Browser(0, 0, 200, 400);
    for (i=0;i<1000;i++){

      sprintf(s, "number %d\n", i);

      o->add(s);
    }
    o->end();
  }
  Win->show();
  Set_Font_Size(Win, 20, 20, 1);
  return Fl::run();
}

[Paul Hahn]

On Thursday, September 10, 2020 at 11:45:08 AM UTC-5 holm.h...@gmail.com wrote:

Here is a small program, where my problem is exposed. I use the Set_Font routine to recusively set font in my program.

Do anyone see the problem in my code ? The browser do not show all entries.

FYI I built and ran your program and see the same thing. My *guess* about the FLTK internals here is that changing font size does not cause a resize of the widget *nor* its child components -- in this case, the internal area that is scrolled. If so, then possibly a clumsy workaround ("kludge"?) for your application when changing font size, is to create and add a new instance of the browser with same X,Y,W,H and with new font size, then copy in the text lines from the old browser, the scroll to the old line, then show the new browser, then hide / delete the old browser, then call the parent container group's init_sizes() method. Occasionally I have to employ tricks like this when reconfiguring things in a UI.  Just part of programming life. But normally, I only manipulate font size in the other direction, ie. in *response* to resizes, rather than resizing in response to font size changes.

[Ian MacArthur]

On 10 Sep 2020, at 17:45, holm.haavard wrote:
>
> Here is a small program, where my problem is exposed. I use the Set_Font routine to recusively set font in my program.
> Do anyone see the problem in my code ? The browser do not show all entries.

I haven’t actually tested your code, but just from looking at it I’m pretty sure the issue is that the height of widgets added to a Fl_Browser is measured when they are added to the browser, so if you then change their height after they were added, the height dependent calculations (like scrolling) will go a bit awry.

If you change the height of a widget, I think you need to remove it and then re-insert it (if you want it at the same place) or re-add it (if you don’t mind it going to the end) to get the browser height updated to use the new height.

Or just set the text size to the desired height before you add the widget to the browser in the first place should work too.

[Greg Ercolano]

On 2020-09-10 09:45, holm.h...@gmail.com wrote:
> Here is a small program, where my problem is exposed. [..]

There's a bug in your code; you're calling Fl_Browser::textsize()
instead of Fl_Browser::textsize().

Change this line and it should work:

BEFORE: if (Fl_Browser_*pB= dynamic_cast< Fl_Browser_* >(pWdg)) pB->textsize(Textsize);
AFTER: if (Fl_Browser*pB= dynamic_cast< Fl_Browser* >(pWdg)) pB->textsize(Textsize);

On 2020-09-10 11:46, Paul Hahn wrote:
> My *guess* about the FLTK internals here is that changing font size does
> not cause a resize of the widget *nor* its child components

No, it wouldn't change the size of the widget, that should remain constant.

It does update the internals, or seems to anyway when I made the above modification,
and looking at the code for Fl_Browser::textsize() it seems to be doing the right
recalculations.

But the base widget doesn't do that sort of thing, only the top level class does.
There's a reason there's an underbar on the end of "Fl_Browser_", meaning unless
you're deriving a class, on probably shouldn't be calling it directly.

[Greg Ercolano]

CORRECTION:
On 2020-09-10 14:34, Greg Ercolano wrote:
> There's a bug in your code; you're calling *Fl_Browser_::textsize()*
> instead of Fl_Browser::textsize().