Hi Greg,
I did get Fl_Table_Row performing the way I wanted in the interim of your
response. I'm not sure if it is an elegant solution but it seems to do the
trick...
When the table is constructed I store the initial constructor width in ini_w
and then during resizing compare the current table width to ini_w and resize
the columns appropriately.
The constant allocation of a double is probably sloppy but there doesn't appear
to be any lagginess when dragging the parents window to different sizes. The
row height is kept the same just for the sake of my own application and how I
want it to behave.
Thanks for your help :)
ALAS: Inside draw_cell I put
case CONTEXT_RC_RESIZE:
{
if(this->w()!=this->ini_w)
{
double scale= ((double)this->w())/((double)this->ini_w);
for(;C<cols();C++)
if(col_width(C)!=0)
col_width(C,col_widths[C]*scale);
}
return;
}
> On 06/15/11 14:31, Jeff Paranich wrote:
> > I'm having some difficulty with Fl_Table_Row that is inside
> > an Fl_Double_Window. Fl_Double_Window is set with this->resizeable(this)
> > in my code, however when the user shrinks the window size Fl_Table_Row's
> > column width and row height will stay fixed and scroll bars emerge.
>
> > I am wondering if this behavior can be changed
> > such that the width/height is adjusted dynamically instead of scroll bars
> > appearing.
>
> I believe you can do this the same way you would any FLTK widget
> where you want your own resizing behavior:
>
> Derive your own class that overrides the resize() method,
> and resize the rows/columns with the logic you like.
>
> > Reading the documentation it looks like this->when(FL_WHEN_CHANGED)
> > should be used in Fl_Table_Row for it to accept resize requests
> > but I'm not quite sure what else is required...
>
> No, that sounds perhaps unrelated.
>
> Fl_Table has the concept of interactive resizing of rows
> and columns, which is not related to the resizing of the
> widget itself. Separate issue.
>
> The widget's docs talk about that, it does not talk about
> the widget resizing behavior, which is handled as per the
> usual FLTK mechanism involving the resize() method.
>
> The resize() method is what you want to focus on, and like
> all FLTK widgets, this method is called when the widget is
> being resized, and handles all logic on how the widget
> (and its children) deal with being resized.
>
> So if you override this method in your derived class,
> take care to call the base class's resize() method
> along with your custom logic, so the widget can do
> its internal bookkeeping. eg:
>
> class YourClass : public Fl_Table_Row {
> ..
> void resize(int X,int Y,int W,int H) { // your custom override for
> resize()
> Fl_Table_Row::resize(X,Y,W,H); // call base class's resize()
> // your logic here
> }
> ..
> };
>
> If you still have trouble, show us a simple, compilable
> example of what you've done. (remove all unrelated code of your app)
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
