STR #3170

GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]
 

Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | Prev | Next ]

STR #3170

Application:FLTK Library
Status:5 - New
Priority:3 - Moderate, e.g. unable to compile the software
Scope:2 - Specific to an operating system
Subsystem:Core Library
Summary:Fl_Table_Row callback not called
Version:1.3.3
Created By:AlainBandon
Assigned To:greg.ercolano
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]

No files


Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
 
#1 AlainBandon
08:47 Dec 26, 2014
When declaring a callback with a Table_Row, the following situation doesn't trigger the callback, either with FL_WHEN_RELEASE or even FL_WHEN_RELEASE_ALWAYS set :

- Clic on any row of a table configured on Fl_Table_Row::SELECT_SINGLE.
- While the clic is still pressed, move the mouse on another row
- Finally release the mouse on another row

What occurs is that the display function using row_selected() to highlight the currently selected row will change while the mouse is pressed without any call to the callback.

void FilterTable::event_callback(Fl_Widget*, void* data) {
  FilterTable *o = (FilterTable*)data;
  o->event_callback2();
}

void FilterTable::event_callback2() {
  int R = callback_row(),
      C = callback_col();
  TableContext context = callback_context();
  printf("'%s' callback: ", (label() ? label() : "?"));
  printf("Row=%d Col=%d Context=%d Event=%d InteractiveResize? %d\n",
      R, C, (int)context, (int)Fl::event(), (int)is_interactive_resize());
}

What is really strange is that the callback is called if the mouse is released over the same row as the one pressed (moving (out and then in again) or not), whatever the value FL_WHEN_RELEASE or FL_WHEN_RELEASE_ALWAYS being used.

For now I have no workaround to fix this inconsistency between the behaviour and the display axcept moving the code of the callback inside the display (erk!). This is why I raised the priority to 4. But feel free to change it.


My system used is Windows seven using fltk 1.3.2. I didn't test the parent Table class but I suppose the bug could be similar.
 
 
#2 AlbrechtS
06:10 Dec 27, 2014
Reduced priority to 3 (Moderate).

Please test with FLTK 1.3.3 or current svn. ISTR that something related to item selection and maybe callbacks has been changed in 1.3.3, and 1.3.2 is really outdated now.

I can't say anything to the details though. I'll leave this to others.
 
 
#3 AlainBandon
07:04 Dec 27, 2014
Tested with 1.3.3 and the bug is the same : changing row while click is maintained changes the inner selection of the table (obtained with row_selected(R) ) without calling the callback of the table.

void FilterTable::draw_cell(TableContext context, int R, int C, int X, int Y, int W, int H) {
  char s[1024] = "";
  sprintf(s, "%d/%d", R, C); // text for each cell
  
  switch ( context )
  {
  case CONTEXT_STARTPAGE:
          fl_font(FL_HELVETICA, 16);
          return;
  
  case CONTEXT_COL_HEADER:
          fl_push_clip(X, Y, W, H);
          {
                  fl_draw_box(FL_THIN_UP_BOX, X, Y, W, H, col_header_color());
                  fl_color(FL_BLACK);
                  fl_draw(s, X, Y, W, H, FL_ALIGN_CENTER);
          }
          fl_pop_clip();
          return;
  
  case CONTEXT_ROW_HEADER:
          fl_push_clip(X, Y, W, H);
          {
                  fl_draw_box(FL_THIN_UP_BOX, X, Y, W, H, row_header_color());
                  fl_color(FL_BLACK);
                  fl_draw(s, X, Y, W, H, FL_ALIGN_CENTER);
          }
          fl_pop_clip();
          return;
  
  case CONTEXT_CELL:
          {
                  fl_push_clip(X, Y, W, H);
                  {
                          // BG COLOR
                          fl_color( /*(callback_row() == R)*/row_selected(R) ? selection_color() : cell_bgcolor);
                          fl_rectf(X, Y, W, H);
  
                          // TEXT
                          fl_color(cell_fgcolor);
                          fl_draw(s, X, Y, W, H, FL_ALIGN_CENTER);
  
                          // BORDER
                          fl_color(color());
                          fl_rect(X, Y, W, H);
                  }
                  fl_pop_clip();
                  return;
          }
  
  case CONTEXT_TABLE:
          fprintf(stderr, "TABLE CONTEXT CALLED\n");
          return;
  
  case CONTEXT_ENDPAGE:
  case CONTEXT_RC_RESIZE:
  case CONTEXT_NONE:
          return;
  }
}


void FilterTable::event_callback(Fl_Widget*, void* data) {
  FilterTable *o = (FilterTable*)data;
  o->event_callback2();
}

void FilterTable::event_callback2() {
  int R = callback_row(),
          C = callback_col();
  TableContext context = callback_context();
  printf("'%s' callback: ", (label() ? label() : "?"));
  printf("Row=%d Col=%d Context=%d Event=%d InteractiveResize? %d\n",
  R, C, (int)context, (int)Fl::event(), (int)is_interactive_resize());
}

The only way I found to fix the problem is to use callback_row() == R instead of row_selected(R) in the draw function to keep consistency between the callback and the display.

For me the click release processing in the callback is just totally broken, doing the same result whatever the value you set in the when().
 
 
#4 greg.ercolano
13:38 Dec 28, 2014
(Changing subject from Table_Row -> Fl_Table_Row so dev search for
"Fl_Table" finds this msg)

Looking into this. Yes; Fl_Table does need some attention
with respect to how the callback() is invoked on events more
complex than simple click/release.

Workarounds would I think involve subclassing Fl_Table, and implementing
your own handle() method to intercept and handle events, using e.g.
Fl_Table::cursor2rowcol() to determine the row/column the event
occurred on, similar to what Fl_Table::handle() does.

Be sure not to eclipse events from Fl_Table and/or Fl_Table_Row's
own handle() methods; pass all events through to the subclass.

Will follow up.
 
 
#5 greg.ercolano
13:47 Dec 28, 2014
Assigning to me, changing "Software Version" 1.3.2 -> 1.3.3
since the issue can be replicated in the more recent release.
 
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]

 
 

Comments are owned by the poster. All other content is copyright 1998-2020 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to 'erco@seriss.com'.