Re: [fltk.general] Re: How do I avoid crash during my widget init thanks to NULL fl_graphics_driver pointer in FLTK 1.4? - Forums

On Saturday, January 21, 2023 at 12:01:05 PM UTC-6 er...@seriss.com wrote:

    I think the OP's problem (which he's since corrected) is probably one of assuming
    a font had already been set, as I *think* what he's saying is he called the getter
    version of fl_font(), e.g. "fl_font(void)", without having first called fl_font(face,size) to set it,
    which probably would have yielded "undefined behavior".

Yes that is my case.

    It's certainly a valid use (and documented) to call fl_font() outside of draw(),
    such as to measure text with fl_measure() during widget construction, before graphics
    has been initialized. I'm guessing fl_font(face,size) checks if graphics has not yet been
    initialized, and initializes it.. but fl_font(void) does not (and perhaps shouldn't)

Yes exactly. My code was calling fl_font(void) without ever calling fl_font(face,size) at all, assuming that the font (and size) were initialized to some reliable "default" within FLTK (i.e., in the Fl_Window class constructor). Again, this happened when my text-oriented class was instantiated as a member of my class derived from Fl_Window. That text-oriented class calls fl_font() to set up sizes of things - again, assuming a default font + size is good.

From now on, to be rigorous, I will no longer assume there is such a thing as "default" font + size in FLTK, and that I must initialize it.

However, at least in my case, if the Fl_Window class constructor had indeed initialized all of this to some kind of defaults (including opening the display?), my code would have continued to sail smoothly on. But I understand that if opening the display fails in the constructor, about the only option is to throw an exception for the sake of the programmer who can catch it if desired.

On the other hand, maybe some other toolkits (Qt?) take care of this kind of initialization issue in a global initialization routine that programmers are required to call at the start? Like as with Fl::lock() in FLTK when we need to use MT and locks. Or, as it now appears, fl_open_display(), which might essentially fill that role now in FLTK, so calling it at the start of their program is what everyone should do as boilerplate.