Thomas Guiot wrote:
>
> yes image->Filter() is time consuming.
> i indeed assumed that fltk couldn't handle another window callbacks while one
> was still running.
It does not even handle _events_ while a callback is running (only some
events trigger your callback functions).
> actually, at first i had a separated MyCallback.cpp file, where all my
> callbacks, from any window, were implemented. I changed that because i had to
> declare my classes global to use them in the callbacks. As i try avoiding
> globals, i reimplemented callbacks as member functions, but now i'm having
> the problem to make callbacks communicate between classes...
> Maybe i should go back to the first idea, and find a way to gather all
> callbacks in a single file while avoiding global...
No, that would be a bad idea. However, if there are two classes that
interact somehow, then there must be a way that they "know" each other.
>
> it does get tricky :-) Even with add_timeout, if i have:
>
> [filterWindow.cpp]
> ..
> void filterWindow::run_cb()
> {
> SetParameters();
> Fl::add_timeout(10, Filter_callback);
> }
> ..
>
> i still have to let my add_timeout function know that the Filter_callback is
> a function from my main GUI class...
>
>
> another idea: if filterWindow is declared as a child of my main Fl_window,
> can't he use his parent's callbacks ?
I don't think that filterWindow could be a child of your main window,
because it would be included in the main window and not another seperate
window. You would need a method in your filterWindow class to learn
about its related main window:
> i'd have stg like:
>
> [in main class.cpp]
> void myGUI::Filter_callback()
> {
filterWindow->register_window(this); // store main window pointer
filterWindow->set_modal(); // force window on top
> filterWindow->show();
> }
>
>
> [in filterWindow.cpp]
void filterWindow::register_window(Fl_Window *w)
{
window_ = w; // save main window
}
> void filterWindow::run_cb()
> {
window_->RunFilter(this->filter_params());
// this-> is only for clarity.
hide(); // close parameter window.
> }
>
> .... what do you think ?
This would start your RunFilter() method from the filterWindow callback,
but there is still the time consuming problem. Your interface won't be
active while RunFilter() is running. You may use Fl::check() to be able
to support a cancel button or similar.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
