Kevin Cockrell wrote:
> Hi,
> I setup a very simple fltk GUI with Fl_Window that has a Fl_Menu_Bar and an
> Fl_Gl_Window. I have the following items in my menu (which is called mbar):
>
> mbar->add("ChangeSquareColors/Make Square Red", 'r',
> (Fl_Callback*)TopSide_GUI::cb_MakeSquareRed, (void*)0, 0);
> mbar->add("ChangeSquareColors/Make Square Blue", 'b',
> (Fl_Callback*)TopSide_GUI::cb_MakeSquareBlue, (void*)0, 0);
>
> Inside of my Fl_Gl_Window draw() function, I just draw a square that is red
> or blue according to a variable that is set with the callback functions from
> the menu.
>
> But I am running into something that confuses me. If I use a mouse to click
> on the menu and choose one of the items, then it automatically calls the
> draw() function of my Fl_Gl_Window. But if I use the shortcuts 'r' or 'b',
> it changes the local variable but does not call the draw() function. Why is
> clicking on the menu different than using the kayboard shortcuts?
When you click on the menu, the menu is probably posting over the
opengl window, damaging it. When the menu clears, fltk tells the
damaged widget (the opengl window) to redraw.
Keyboard shortcuts don't post damaging graphics,
so no redraw is needed.
If your callback is changing things in the opengl window,
then you'll need to force a redraw for the opengl widget
to force it to redraw; to do that, use yourglwindow->redraw();
in your callback after making the color change. This will schedule
FLTK to redraw the widget, which it should do when you return
from the callback.
> And how does my Fl_Menu_Bar "know" that there is a Fl_Gl_Window
> to draw? This seems very weird to me...
The menubar doesn't; FLTK does.
FLTK knows about all the widgets, and is responsible for managing
redrawing them in the correct order.
_______________________________________________
fltk-opengl mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-opengl
