On 11/11/11 07:30, Albrecht Schlosser wrote:
> On 10.11.2011 21:30, Greg Ercolano wrote:
>>      I think what's happening (not sure) is:
>>      Fl_Table calls its event_callback() *during* it's handle()
>>      method, and it's probably not expecting the event_callback()
>>      code to start its own event loop.
>>
>>      I'm not sure it's technically possible for the event_callback()
>>      to be used for doing its own event loop (which popping up a
>>      blocking menu implies), so I think the below technique is
>>      probably needed, and the docs for Fl_Table::event_callback()
>>      should warn about this.
> 
> Again, I'm not sure what Fl_Table::event_callback() is designed to do,
> but running one's own event loop in a callback to pop up a menu (or
> fl_message() and friends) is standard. In fact, everything your program
> does after starting Fl::run() is done in callbacks, isn't it?

        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.

        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.
_______________________________________________
fltk mailing list
fltk@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk

Reply via email to