On 10/27/2011 02:35 PM, Ian MacArthur wrote: > > On 27 Oct 2011, at 16:57, Jim Jozwiak wrote: > >> NUT is a huge application from I have excerpted only two rows and and a >> single "column" from a single screen in order to show the error. Each >> row is a horizontal pack, the column is a vertical pack. >> >> Packs only resize all their contained widgets if set to resizable. If I >> can't set the inner horizontal packs to resizable, then the widgets the >> inner packs contain won't resize. >> >> Ultimately, my application depends on widgets that appear to retain >> their position although in the actual code, wizards are changing. >> >> Are you telling me that nested packs aren't allowed to be resizable? > > No, I was trying to say I was struggling to visualize what it is that you are > trying to achieve with Fl_Pack. > > In particular, based on my (limited and presumably flawed) understanding of > the description you gave, I wonder if you need the packs at all. > > A simple Fl_Group will scale it's children as it resizes, retaining their > relative positions and dimensions in proportion to the initial layout, so by > judicious use of groups (nested or otherwise) I *think* you can get the > desired effect more simply than you are currently doing. > > So, anyway, Fl_Pack may be overkill, and I find them tricky to use. > Fl_Group is simpler to use and for most purposes I find it a much more > amenable widget to work with... > > But, as I say, I'm probably completely missing the point of your question and > there may be a genuine need for Fl_Pack in your usage.
Thanks for addressing it, Ian. My application takes a huge relational food composition database and tries to make the relationships between food, nutrients, and meals comprehensible. To do that, I need to present widgets that represent something and yet change the wizards that contain these widgets as necessary to show other facets of the food tables. Fl_Group would work if the screens in the wizards all had the same constituent widgets, but they don't, so I need packs to keep the widgets that are common to two different screens in the same place so they look like the same widget to the user. In most nutrition programs, there are endless tables and popup windows that truly make it challenging to understand what you are looking at. But none of these issues are addressed by the example I presented. If you are curious, the whole application is at http://nut.sourceforge.net , and the application currently does not resize at all, because I couldn't get it to work. Also, the actual resizing is perfect. I am not questioning the way fltk resizes anything. All I am noting is that when I nest two horizontal packs in a vertical pack and mark all three packs as well as the main window resizable, the widgets in the second horizontal pack stop working although they do resize correctly. The first issue I would like to explore is does this happen on other platforms, or is it unique to my platform; and if it happens everywhere, is it my coding error or a bug in fltk; and if it is a bug in fltk, can it be fixed, or should I shrug off my users who want my application to resize? Thanks, Jim _______________________________________________ fltk mailing list fltk@easysw.com http://lists.easysw.com/mailman/listinfo/fltk
