On Jul 6, 2007, at 3:55 AM, D. Zimmer wrote: > Sounds like it might be a simple issue with keyboard focus. If you > can fix this problem interactively by simply hitting the tab key > once or a couple of times to move the focus to the GL window, then > that would confirm it. In this case, simply set the focus to the > GL window when you show the form.
The Fl_GL_Window does not take any focus unless the handle() function is modified accordingly. But the problem is likely as you describe. OP: your keyboard events will not be sent to the OpenGL window if other windows grab them first. It probably worked at first, because your GL window was the first in the list and grabbed the events event though it was not supposed to. There are a few solutions: 1: you can add the code needed to allow the GL window to take focus. It then behaves like any other widget, meaning you can move focus using the tab key, and it will get the arrow keys first, while it does have focus. You implement this by returning 1 for FL_FOCUS events and drawing a dotted rectangle inside your widget if you do have focus. 2: you can avoid any other widget that may take focus and use the FL_SHORTCUT events to grab the arrow key events, 3: you can use arrow keys in your OpenGL window with a modifier, like Alt or Ctrl and capture thise in the OpenGL window using FL_SHORTCUT events or finally, 4: you can use modified text widgets that do not support arrow keys, so all arrow keys end up in the OpenGL widget (but the text widgets will become quite unusable). ---- http://robowerk.com/ _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
