Alvin wrote: > Hello all, > ... > My problem is that the toolbar buttons, that would be covered up when View > is selected, sometimes get their value set to 1. > ...
I found my problem. When my custom Fl_Scroll detects the right-click and calls its callback, it did not "return 1" saying it had used the event. Adding "return 1" after do_callback() fixed the problem. I did do some investigating as to what was happening. What I discovered is that the mouse click (i.e. selecting a menu item from the context menu) results in a FL_PUSH event. By not having my Fl_Scroll return 1, the FLTK main-loop (?) tried to propegate the FL_PUSH event to all of the widgets in the app. The FL_PUSH eventually makes it to the Fl_Group that I have acting like a toolbar. The FL_PUSH is eventually sent to one of the buttons and is mistakenly seen as occurring inside the button. I have whipped up an example of this. Again, I'm not sure if this is a bug in FLTK or is simply classified as undefined behaviour since my Fl_Scroll did not return 1? I made the attached example using purely FLUID. All you need to do is generate the .cxx and .h using FLUID. Then, to compile, use: fltk-config --compile contexttest.cxx To reproduce the "bug", do the following: 1. Run contexttest in a shell so you can see the printf statements 2. Right-click in the area "Right-click in here" 3. Select "item2 def". 3.i. When selecting item2 I find you can see the bug if you click on the "i" or on the "2" in the label. What you should see is that one of the buttons (b1, b2, b3, b4) will change colour. Since the buttons are Toggle Buttons, this means that their value has been changed to 1. If you repeat these steps, the printf will show the proper value. The printf statement shows that the value doesn't change to 1 until after the context_menu() returns; Again, is this simply a matter of undefined behaviour or is this a bug? Thanks, -- Alvin
_______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
