Albrecht Schlosser wrote: > Alvin wrote: >> Albrecht Schlosser wrote: >>> try >>> wnd->resizable(wnd); // the window itself >>> wnd->init_sizes(); // reset internal sizes array >>> >>> instead. >>> >>> Maybe you could/should also call wnd->size_range(...), but I don't know >>> without further analysis or testing. >> >> Yes, that was the missing piece. After resizing the window (and >> temporarily unsetting the resizable widget), the window will only be >> resizable if size_range() is called. That function must do something else >> or make a needed WM call? I haven't looked at the source yet. > > At least one thing is clear: Calling wnd->resize() after setting > wnd->resizable(0) sets the window's size range to the new width and > height (fix, no resizing). Setting the resizable() after this doesn't > change the size range, AFAICS. > >> I've attached a working example. It's a dumby app that contains some >> widgets. Just compile with: >> >> $ fluid -c wndresize.fl >> $ fltk-config --compile wndresize.cxx > > Yes, that works ;-) > > Now I could see that you were right with setting the resizable(0) before > resizing the window, not resizable(wnd) as I suggested, but you found > that. > >>> BTW.: _Currently_ (!) it's a bad idea to remove the resizable widget >>> from a group without calling init_sizes() (or even delete() it!), >>> because there seems to be a bug that the group or window doesn't adjust >>> the sizes array accordingly. I remember an STR filed for FLTK 2.0, but >>> this is true for 1.x as well (it's on my todo list). >> >> >> So, init_sizes() should be called after I (un)set the resizable widget >> (like I do in the example)? > > In the current FLTK 1.x versions, yes. I think that there are some bugs > with handling the resizable(), but I'll have to look at the sources and > docs. Maybe setting the resizable _must_ call init_sizes() internally, > just as it does when add()ing and remove()ing widgets, but I don't know > yet ... > >> The docs for size_range() do mention that the range is automatically >> determined by resizable(). Perhaps calling size_range() in the callback >> forces that algorithm to execute? > > IMHO, the docs are not very clear about what really happens or is > intended. We should check and improve this.
Yeah, I have found several functions that seems to have their documentation missing (they existed in the previous plain HTML docs) and parameters miss-labeled (as in int a, int b, int c and docs say xmin, ymin, xmax, etc.). The miss-labels arguments are mainly caused by missing argument variables in the function prototype/declaration which is valid syntax but makes the documentation sort of cryptic. I've been meaning to prepare a patch that fixes some of that (rather than just complaining about it). Hopefully I can over the holidays. But, to get back on topic, what is the best/preferred way to accomplish what I am trying to do (Dynamically hide a group)? Is it preferred to resize the window (shrink/expand) to fit _or_ to resize the contents to consume the current window's dimensions? -- Alvin _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
