DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2639 Version: 1.3-current Hi, I'm running on Ubuntu GNU/Linux, fltk-1.3-rc5, and re-checked the uploaded program to be the right one (download/fresh compile). I wrote Matt about this a couple of months ago. Funny how he also couldn't reproduce it in the first try, but succeeded later: [Matt wrote:] > [jcid wrote:] > > It's even possible to continue growing/shrinking using the same > > trick. e.g.: > > > > 1.- start with a small window > > 2.- hide "Group 2" > > 3.- maximize window > > 4.- show "Group2" > > 5.- shrink window to original size > > 6.- hide "Group 2" > > 7.- maximize window > > 8.- show "Group2" > > > > Here, "Group 2" has grown near four times in height. > > OK, now I see something too. The maximizing did the trick. It > seems that g2, when hidden, lies within the area of the > resizable. So when it is shown again, the entire "resizable" > mechanics are messed up. Now that I can replicate the issue, I > will fuz around with it for a bit an let you know when I get an > idea. The most likely correct solution will be to manually > recalculate the g3 position and sizes when you show or hide g2, > and the call init_sizes(). After a deeper analysis, he came with this detailed diagnose: > [Matt wrote] > OK, I think I am getting there: the gist of it is this: Fl_Pack > does not have a resize() function at all, so resizing it will > fall back to Fl_Group::resize() which correctly resizes all > widgets, visible or not, to keep the integrity of the layout. > > Fl_Pack however recalculates the widget layout during > Fl_Pack::draw(). At this point, Fl_Group::resize() has already > resized your G2 because it clearly is within the range of the > resizable(). > > I did the following changes in your code: > > static void b1_cb(Fl_Widget *w, void *data) { > Fl_Group *g2 = (Fl_Group *)data; > > if (g2->visible()) { > g2->hide(); > g3->resize(g2->x(), g2->y(), g3->w(), g3->h()+g2->h()); > p1->init_sizes(); > g2->window()->redraw(); > } > } > > static void b2_cb(Fl_Widget *w, void *data) { > Fl_Group *g2 = (Fl_Group *)data; > > if (!g2->visible()) { > g3->resize(g3->x(), g3->y()+g2->h(), g3->w(), g3->h()-g2->h()); > g2->show(); > p1->init_sizes(); > g2->window()->redraw(); > } > } > > An also added a resize function to F_Pack. It is very simple > because Fl_Pack::draw() does the actual layout, as mentioned > above. > > protected: > void draw(); > void resize(int X, int Y, int W, int H) { > int dx = X-x(), dy = Y-y(); > int dw = W-w(), dh = H-h(); > Fl_Widget::resize(X, Y, W, H); > Fl_Widget *r = resizable(); > if (r && r!=this && (dw || dh)) { > r->size(r->w()+dw, r->h()+dh); > } > // let redraw() do the rest of the layout process > if (dx || dy || dw || dh) > redraw(); > } > > > Maybe we should propose to add this to Fl_Pack? This is the time > to break such things, before we release 1.3! > > What do you think? Also, does this solve the issue? And yes it solved the issue, but OTOH, the workarounds were simpler, and at this point it was clear that something was going wrong in the resize mechanics of Fl_Pack. HTH Link: http://www.fltk.org/str.php?L2639 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
