Matthias Melcher wrote: > As for the width and height, yes, they can be negative. We have never > documented on what should happen in this case, so it is simply "undefined".
Yes, that's what I think, too. > There are really only three possibilities: > - if width or height becomes negative, the widget behaves as if it was > hidden in every respect > - the widget draws just like usual, but flipped (graphically flipped, or > just shifted to the top left) > - we don't allow it > > I would tend to the first solution, but that means tat we would have to > check all drawing and positioning functions and event handling for all > widgets! We would have to add code to cehk for the relatively unlikely > negative sizes everywhere. > > So practically, light, and fast would be solution three (or two - no special > handling). I tend to _define_ that it is _undefined_ ;-) That means that each of the two solutions would be possible. No. 3 (we don't allow it) is okay, but we can't prevent the user from setting negative width and height values. My problem with STR #2130 is the following: the code in Fl_Group.cxx decides depending on fl_not_clipped() if the widget is to be drawn or not. The current resizing mechanism makes the size (height) 0 or even negative, but _if_ the Fl_Pack is draw()n, it resizes itself to its normal size within draw(). But if draw() is not called at all, there is no chance that Fl_Pack can resize itself :-( , and thus it is invisible. I'll check if I can separate resize() and draw() in two different methods, so that this can't happen at all, but anyway we should know what to do if... Depending on my further investigations I'll decide if we can fix this in 1.1 or if this would only be done in 1.3. Thanks to both of you for your opinions ! Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
