On 02/05/2010 08:26 AM, Jose Marcelo Auler wrote: > I've made a key generator in order to automatic test stability of my > software, and turned out that Fl::run() returns(exits) after a while. I first > tried a key generator of 20Hz, and it takes a lot of time to be in this > condition, but with 50Hz(50 keys per second) it's very quick.
Hm... Sounds like a circular keyboard buffer has overflowed and something (in FLTK or the underlying libraries) has noted this problem and decided to recover by terminating your program with extreme prejudice. This is not an unreasonable strategy for this type of error. > In my mainscreen I overwrote the handle to not do anything with FL_CLOSE or > FL_HIDE and it goes there, but even with the return 1;(in FL_CLOSE and > FL_HIDE) it returns from Fl::run(). Is there another way to return from > Fl::run()? I'm pressuming FL queue reached a maximum size or something like > that... In most programs, Fl::run() won't return. It continues until no windows are shown or until some unrecoverable error occurs. Note that you may actually be lucky. FLTK is quite ill behaved when faced with memory starvation and may not exit in such an orderly fashion. Of course in most common environments, your application will become completely unusable long before you see this bug. > Another interesting fact, is that using Fl_Box(or even Fl_Label or Fl_Button) > to draw label could be slow(at least in my software). I will explain better. > If I use a buffer outside the Fl_Box/Fl_Label and when I change this buffer I > just call (Fl_Box object)->redraw(), it's ok, it's fast. That's because ...->redraw() doesn't do much. It simply adds the area of the subject widget to the area marked as "stale" and schedules it for refreshing at some time in the relatively distant future. No pixels are immediately harmed. > But if every time the buffer gets changed I call (Fl_Box)->label((new string > array)); it gets slow. And in my software this is done in cycles(every > 1/2sec), so it's making difference. Does anyone have a clue what could be or > if I'm not using in the intended way? I could subclass Fl_Label to solve this > problem, but I want to understand what is really happening.> I think the widget's label is intended to be like a tattoo: a more or less permanent adornment for the widget that describes its purpose. In support of this most-common use, changing the label may *force* an immediate refresh. If the label is outside its subject widget, the parent is refreshed as well. In light of your 50 char/sec input, it is not surprising that the response is relatively slow. Rest assured that all GUI toolkits have similar quirks. Because FLTK is much smaller it has substantially fewer. Jim Wilson _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
