Scrollable Table Not Rendering Child Widgets Correctly

[Webb Hinton]

Hello all,

I'm experiencing an issue when using the table widget. If you add enough widgets to make the table widget turn into a scrollable table, then it seems like the buttons do not render correctly. When you push on a button in the table, the button seems to redraw in the correct location. 

Steps to reproduce:

• Create a Table Widget
• Put enough buttons in it to make the scroll bars appear 
• Click on the buttons in the table

I cant' tell if this is a bug, or just the way FLTK works, like I need to tell the Table to draw the widget in a certain way or something like that. 

Here's the rust code, so you can see that I'm not doing anything especially abnormal to create this effect:

use fltk::{prelude::*, *, image::*};

fn main() {

    let app = app::App::default().with_scheme(app::Scheme::Gtk);

    let mut wind = window::Window::default().with_size(402, 275);

    let mut table = table::Table::default().size_of(&wind);

    table.set_rows(8);

    table.set_cols(5);

    table.set_row_height_all(90);

    table.set_col_width_all(80);

    table.end();

    let mut img = SvgImage::load("search-24px.svg").unwrap();

    table.draw_cell(move |t, ctx, row, col, x, y, w, h| {

        if let table::TableContext::Cell = ctx {

            img.scale(w, h - 20, true, false);

            let mut button = button::Button::new(x, y, w, h, None);

            button.set_label(&format!("Image {}", row + col));

            button.set_align(enums::Align::Bottom | enums::Align::Inside);

            button.set_frame(enums::FrameType::FlatBox);

            button.set_image(Some(img.clone()));

            button.set_callback(|b| println!("Selected: {}", b.label()));

            t.add(&button);

        }

    });

    wind.make_resizable(true);

    wind.end();

    wind.show();

    while table.children() == 0 {

        app::wait();

    }

    app::redraw();

    app.run().unwrap();

}

[Greg Ercolano]

On Friday, June 11, 2021 at 4:04:08 PM UTC-7 caroli...@gmail.com wrote:

Hello all,

I'm experiencing an issue when using the table widget. If you add enough widgets to make the table widget turn into a scrollable table, then it seems like the buttons do not render correctly. When you push on a button in the table, the button seems to redraw in the correct location. 

 

Steps to reproduce:

• Create a Table Widget
• Put enough buttons in it to make the scroll bars appear 
• Click on the buttons in the table

I think most of us can't read rust, but offhand it looks like you're creating the buttons in the table's draw code which I wouldn't recommend: the table's draw function only triggers for visible items, and are called repeatedly during redraws.

Please look at the example program examples/table-as-container which creates button and input widgets that extend beyond the window borders, where scrollbars appear and work normally during scrolling and column/row resizing.

Note that you may not actually NEED an Fl_Table widget if you're just making one widget per 'cell' in the table. You could just use an Fl_Scroll and create the table of buttons in the needed positions and that should work fine. You might only need an Fl_Table if you need e.g. resizable rows/columns or something.

[imm]

On Sat, 12 Jun 2021, 00:22 Greg Ercolano wrote:

I think most of us can't read rust, but offhand it looks like you're creating the buttons in the table's draw code which I wouldn't recommend: the table's draw function only triggers for visible items, and are called repeatedly during redraws.

I agree with Greg, the rust code's probably not the primary skillset around here. Maybe Mo Al can pitch in? I think the rust port is his thing... ?

And, again, it does *look* (to my C programmer eyes) like you are creating widgets inside of the draw method... Which is just wrong...

--
Ian
From my Fairphone FP3

[Mo_Al_]

Yes. I originally had posted similar code in the fltk-rs examples folder. I realize now it's wrong. Replacing things with a scroll widget and maybe a pack of packs would be better.