Hello!!
>
> On 5 Feb 2010, at 13:26, 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.
> > 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...
>
> I can't reproduce this - but maybe I misunderstood your set up.
> I think you have written a test harness to generate synthetic
> keyboard inputs at a rate of 50Hz to test your code, but this
> keystroke generator expires after a sort while, for some reason?
>
> How is the timing generated? Is it using the FL timeout callbacks or...?
>
> Anyway, so far as I know, Fl::run() returns when there are no windows
> left open, so perhaps all your windows have closed for some reason?
>
> I'm not sure what you are doing in your handle method, either.
>
> Can you post a small compileable example that shows what it is that
> you are doing?
>
My key generator is done by linux drivers, its external to fltk.
The key generator does not expire, my application exits because Fl:run()
returns from its while loop.
My window class does handle like that:
int MyMainWClass::handle(int aEvent)
{
switch(aEvent){
...
case FL_KEYBOARD:
{
if ( Fl::event_key() == FL_Escape)
return 1;
}
...
case FL_HIDE:
//lint -fallthrough
case FL_CLOSE:
{
TRACE_STR("*** TENTOU FECHAR O SCREENMANAGER ***\n");
return 1;
}
..
return Fl_Window::handle(event);
}
So by my implementation I can't understand how this window could possible be
closed. Maybe something related to window manager... dont know...
> Also - what host platform are you on (not that it should make any
> difference of course.)
I'm running linux(Xfbdev) with fltk-1.3.x-r6581.
>
> > 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. 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.
>
> Again, I don't think I have understood what you are doing - can you
> also make a minimal example of this that shows the effect that you
> are seeing?
This is already solved... one method simple marks to draw and the other could
redraw also the owner window of the widget we are updating.
>
> --
> Ian
>
>
Thank you
J.Marcelo Auler
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
