On 07.10.2010, at 02:38, Ben Stott wrote: > >> Hmmm...that's interesting. Ben: I built a minimal project using only the >> code you provided and the cursor worked correctly. However, when I add the >> GlWindow to a parent Window, I get the aforementioned cursor error. > > So I'm not currently able to test this - in a couple of hours I will, but I'm > not surprised this happens. > Basically, you create a window, and then declare your GlWindow as a child of > this window. > > Now, I'm not *entirely* certain, but I'd be just about willing to bet that > what happens is that your subclassed GlWindow doesn't get to eat all the > events, and/or the Window is getting the events passed *first*, and since the > event most likely has a non-zero return value, your GlWindow doesn't get a > chance to eat these events.
I tried the test program on my Win7 system, and I can confirm that the odd cursor behavior can be seen with a GL subwindow. I also added a few printf's and could see that the "normal" events arrived at the subwindow. I also moved the call of GlWindow::handle() to the default case (as it should IMHO be in most cases) to prevent any interaction with the GL Window's default behavior (i.e. after processing events in the subclass like ENTER and MOVE I did *not* call the base class's handle() method). No change. Then, being curious (and a FLTK 1 user/dev.), I ported the test program to FLKT 1, and ... it worked as expected (I mean as it should: the cursor keeps its cross shape in the GL window), and adding the missing (FL_)LEAVE event to change the cursor back works as well. Thus, I don't think that the GL driver is to blame, it's more a FLTK 2 issue. That said, I'm not going to debug FLTK 2 code, but I hope that my tests and insights are helpful... Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
