Greg wrote: >>> Don't forget to set the font ;) eg. fl_font(). >>> FLTK will crash if the font isn't set before the fl_draw() call.
I wondered: >> Is there some reason why this is acceptable behaviour and not an >> STR? You don't need to call fl_font() before setting titles and >> labels, so why is it needed before fl_draw()? Can't the same font >> be used? Albrecht replied: > I imagine that fLtk doesn't call fl_font() for you before calling > your draw() method because of the 'L'(ight) in its name. Calling > fl_font() can probably be expensive (X server communication, ...), > and doing this w/o knowing that you need a font for (text) drawing > (and which one) would be ineffective and/or wasting resources. OK, good, there's a clear reason why you have to set a font before calling fl_draw(). That's really what I wanted to know. > OTOH, if you call fl_draw() and didn't set a font before calling > it, then we could probably set a default font ... I think the simplest would be to have an assert or other check that a font has been set, so that the user isn't left scratching his/her head wondering why there's a segmentation fault. > Duncan, on which platform (and if Linux: w/ or w/o XFT) did you > run your program? I installed fltk-1.3.x-r7677 on my work box back in July, with XFT. It's a 64-bit box, with CentOS 5.5 installed, but it's taken several updates to get to this point. My home box is 32-bit, running Lunar Linux which is a rolling distro but I haven't updated it since August, and I just re-installed fltk-1.1.10 on it to develop the example. Off the top of my head I don't know whether XFT is installed, but I would imagine so. Cheers D. _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
