On 13.11.2011 02:40, Greg Ercolano wrote:
> I should describe it more clearly: Fl_Table_Row()
> is currently doing this (pseudo code):
>
> int Fl_Table::handle(int e) {
> switch ( e ) {
> case FL_PUSH:
> ..stuff..
>
> if ( user's event_callback defined ) {
> do event_callback() //<-- A
> }
> ..thinks we're still handling original FL_PUSH..
> if ( button == leftmouse ) { //<-- B
> handle_row_selection_behavior //<-- C
> }
> ..
>
> So if the user has an event_callback() defined,
> it's called at point A during the initial right-click
> FL_PUSH event, then at point B checks if the current button
> is leftmouse, and if so, handles cell selection at point C.
>
> This code does not take into account the user's callback
> might post its own menu (with it's own blocking event loop
> to service handling the entire popup menu interaction),
> such that by point B, different events have been processed,
> and the user might have left out of the posted menu
> with a /left click/, which is then mistakenly processed
> at points B and C.
Okay, I understand. So the problem is (was) in Fl_Table's code and
not in FLTK's internals (I mean: event handling, menu code, ..).
> I think to fix this is probably to /record/ the mouse button
> state above the switch(), so that the check at point B isn't
> confused by the different state of realtime mouse buttons
> caused by the posted menu.
>
> I'll try that and see if it solves the OP's issue.
I saw your fix. Thanks for taking care of this.
Albrecht
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk
