FLTK logo

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

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 All Forums  |  Back to fltk.general  ]
 
Previous Message ]New Message | Reply ]Next Message ]

Re: Re: How do I avoid crash during my widget init thanks to NULL fl_graphics_driver pointer in FLTK 1.4? Albrecht Schlosser Jan 21, 2023  
 
On 1/21/23 21:00 Paul Hahn wrote:

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.

This has always been wrong, because measuring text w/o explicitly setting the font would access undefined font data. An FLTK convention is to use a font after setting it (which is fast if it has been done at least once before) and leaving the font as-is. Hence even during runtime you must always set the font you want to work with because you would otherwise use the font used before which could for instance be a bold italic 36 pix font.

    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.

To be precise (sorry for nitpicking): there *is* a default font and size, but it is not initialized at program startup automatically. There are chances that your program never uses the default font, so why bother and load 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.

That said, before commit 4b945a308 (Nov 5, 2022) there was an unwanted initialization of the graphics driver in the constructor of Fl_Widget (and hence also Fl_Window) which was removed with the mentioned commit. This was necessary for the hybrid X11/Wayland FLTK platform on Unix/Linux, but this early initialization of the graphics driver had been problematic anyway.

This *may* have hidden the problem to access uninitialized font data in your program because it crashed now with the missing graphics driver initialization.

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.

fl_open_display() is called internally in many places when needed, e.g. Fl_Window::show() but also Fl::font(face, size), Fl::get_system_colors() and some (many) more functions. The rule is not to call it if it's not needed (as in fluid in command mode `-c`) but if you're sure your program needs it because it's a GUI program, then it's not wrong to call it at the start of main(). Our goal is to open the display only when necessary and that's usually when Fl_Window::show(...) is called.

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/1d00113d-ba30-e149-aa7f-b98c82f888a8%40online.de.
Direct Link to Message ]
 
     
Previous Message ]New Message | Reply ]Next Message ]
 
 

Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.