Jonathan wrote:
> I just tried something like this:
I assume you read my post about Fl::grab(). This was not intended to
encourage you to use it, but to explain why you might have seen these
click binding effects (if you used it somewhere). Fl::grab() is
_dangerous_, and you should only use it if you know what you want to
achieve (it's mainly something that is used internally for special
things like menus, and it can lock your full screen (X server), if done
wrong).
> int handle(int event) {
> if (event==1) {
you'd better use FL_PUSH here.
> Fl_Double_Window::show();
okay, this ought to bring the window in front.
> Fl::grab();
This does nothing because it's the _get_ method. *IF* you really want to
use Fl::grab() then this would have to be:
Fl::grab(this); // use with care !!!
> }
> return Fl_Double_Window::handle(event);
> }
>
> It brings the subwindow to front but it doesn't solve the click catching
> problem.
> Apparently, when shown, the hierarchy of the windows depends on the order
> that I added them to the main window. Can that be changed?
This is intentionally and can't be changed in FLTK 1.1 (and probably in
1.3 as well). But this shouldn't have any effect if you only create top
level windows (without modal or non-modal attributes).
I think that we need more info what you are meaning with "subwindow",
and how you create these windows.
BTW: IIRC FLTK 2 has a method named child_of(), and I *think* that this
is intended to make a created window a "child of" another window (WRT
window hierarchy), but I'm absolutely not sure about it. If this is
true, then this will be part of the (near?) future FLTK 3.0.
Albrecht
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
