I think I've finally got it. Thanks again - that was *very* helpful for my actual project and with regard to former problems I was facing when "drawing things in FLTK". And thanks to Albrecht for his example code!
> On 04.02.2012 00:08, testalucida wrote: > >> On 02/03/12 11:21, testalucida wrote: > >>> Hi all, > >>> thank you for your efforts! > >>> It works as you say, but I still can't understand why this doesn't work: > >>> textfont( FL_HELVETICA_BOLD ); > >>> textsize( 12 ); > >>> (instead of fl_font(textfont(), textsize()); ) > >> > >> fl_font() sets the "current font" used for drawing > >> which fl_measure() says it needs in the docs. > >> > >> textfont() and textsize() don't affect the current font > >> used for drawing, they just set the widget's text font. > >> > >>> And why does it work when adding a dummy Fl_Output first? > > By accident, because this dummy Fl_Output's draw() method is called > just before the other widgets' draw() methods, and the former sets > the font. You could try to see what happens with your previous code, > if you set *different* textsize() values for your different widgets. > You would see that they all calculate their widths with the textsize > of the *previous* widget in the group (drawing sequence). > > > let me ask you a last question: > > Albrecht said in a previous post, resizing in the draw method is like > > "asking for problems". > > To answer your question (sorry, this is loong...): > > The correct way to do anything related to resizing is in the resize() > method, because this is called whenever the user resizes the window > and indirectly (maybe) the contained widgets (depending on the set > resizable() widgets in all groups). If you don't have a resizable > window, Greg's suggestion to do it when the value is changed is a > valid and very good solution. > > The reason I wrote the cited text is that you never know *when* draw() > will be called. FLTK calls it whenever the window or a part of it needs > an update. > > When FLTK decides that a part of the window needs an update, it checks > which widgets need to be drawn (dependent on their positions and sizes) > and calls the draw method(s) only for these widgets. But what happens > if you change the position and/or size of a widget or group in its > draw() method? The previous decision might have been wrong, but that > was not known before. One example is that you can make the widget > smaller or move it to another position. Then the exceeding part of the > background is not redrawn, and you will still see the old contents... > > The current FLTK library implements some of its widgets with similar > "features" ( ;-) that can lead to problems. > > (1) Fl_Pack resizes its children during draw(). There are known > problems with nested Fl_Pack's that contain resizable widgets, and > maybe more. > > (2) Fl_Scroll (de)activates its scrollbars (calculates its children's > sizes) inside draw(). The method bbox() returns the internal area of > the widgets w/o the scrollbars, but this is only known and reliable, > if draw() has been called immediately before calling bbox(). But you > never know when draw() will be called... > > These issues are only examples and should (will) be fixed in a future > release of FLTK. You should try to avoid such problems. > > > I tried to figure out another way to solve this issue but didn't find one. > > Do you have an idea how to handle the requirement of making the Fl_Output's > > width fit to its content? > > I believe you've already seen Greg's proposal. See also my additions > for resizable windows posted some minutes ago. > > Albrecht _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
