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
