> here's the deal: when the user hits the "filter" button on my gui,
> i'd like a new window to open, presenting some filtering options;
> then the user hits "run" on that window, and image filtering is in process.
If you want your app to block while the FilterDialog
is open, similar to say when a file browser is posted, then
you could show() the FilterDialog, have the run button apply
the settings to internal variables and then hide() it.
Then to open the dialog, just have Filter_callback() simply
show() the dialog, then block in an Fl::wait() loop for it to
become non-visible (eg. if the user hits 'Run' or 'Cancel')
void Filter_callback(){
// Deactivate filter button to prevent recursion
filter_button->deactivate();
// Show filter window, wait for user to hit 'Run' or whatever
filterWindow->show();
while ( filterWindow->shown() ) {
Fl::wait(.10);
}
// At this point user has hit 'Run' or 'Cancel', causing dialog to hide()
image->Filter(filterWindow->GetFilterParameters());
// Re-enable filter button
filter_button->activate();
}
> 1. some way to interrupt the current callback (Filter_callback)
> in order to actually show my filterWindow and wait for this
> filterwindow callbacks. The rest of Filter_callback would then
> be executed as user hits 'run' on the filterWindow, which then
> disappears. Is there a way to do that with fltk ?
Ya, I think that's the above.
Though I think it's better OOP wise to have the 'Run'
button in your FilterDialog hide() the dialog then
invoke the Filter() operation directly. This way
you can have a "Cancel" button that just hide()s the
dialog, and you don't have to block.
The main() function can tell the FilterDialog what the
callback for the Filter() function is, and pass the
parameters as 'callback data'. This way the FilterDialog
needs no knowledge of the Filter function, or the class
its associated with, or any data it needs. That's how
things are usually done with callbacks.
> 3. pass a pointer to my main class when creating my filterWindow;
> i tried this, but still getting compilation errors (i'll be more
> specific if that's the solution i have to choose, but i'd rather avoid that)
You should identify and solve the compilation errors, so that
you know how to do this, as that is the normal way. You
should be able to pass the pointer to any callback as a void*
that your filter dialog can invoke when "Run" is hit, and
optional 'userdata' if the filter callback that "Run" invokes
needs info that the Filter Dialog can't pass itself.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
