On 10.12.2010 15:23, Paul R wrote: > Just to put my mind at ease, as I feel certain this must be a system > specific bug: > > There often seems to be a slight lag in the mouse being 'available' > inside my FLTK windows after a button click to start or whatever.
What actions does a button click start, i.e. what do you do in your callback(s)? And what does 'available' mean? Is the mouse invisible (as describe below), or does it not react on movement? > This behaviour i had ignored as acceptable and most probably system > specific. > Then just now it would not take the mouse at all, the main window > border was the only place the pointer would appear, it would not show > on the FLTK surface and i had to kill program. This should never happen. Do you change the mouse cursor by calling functions like window->cursor(FL_CURSOR_*) ? > I am recording my actions via stdout for bug hunting so i > went back and recreated the steps, same values and everything and > the problem did not reoccur, > > Should i discount this as suggested or could it be code related? I assume that this is (user) code related. We could better answer such questions if your description were more precise, if you wrote about your FLTK version used, and the OS, and if X11, then whether it happens in local or remote use. Anyway, if you can replicate it with a small, standalone, program so that we can compile and test it, please post such a program here. We should be able to use 'fltk-config --compile' to compile and run it. If the problem occurs only in your application, and you can't strip the program down to a short version that only uses FLTK calls, then it is very likely that your program is at fault. You could probably try to use valgrind on Linux to find some subtle bugs overwriting data etc.. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
