On 10.06.2011 10:17, MacArthur, Ian (SELEX GALILEO, UK) wrote: > It may be a problem with which regular window the non-modal window is > parented too. > > A while back, on OSX with fltk-1.1.something I encountered a similar > sounding issue with non-modal windows, and it turned out that the issue > was something to do with which "regular" window was "current" when the > non-modal window was created. > > What I ended up doing was (hacky pseudo-code follows...) > > ...create main_win then... > main_win->show(); > > ...create other regular windows... > > ...then... > main_win->show(); > ...create a non-modal window... > main_win->show(); > ...create another non-modal window... > main_win->show(); > ...create another non-modal window... > ...etc... > > Note all the "redundant" main_win->show(); calls in there - they "fixed" > my window ordering issues.
Yes, that's exactly what I would expect. The window "parenting" happens when the new window is shown, and the "current" window (that's the first window in the internal window queue) becomes the "parent" of the new (non-)modal window. However, I know nothing about the behavior on OS X in this case ... except that I saw once in our FLTK code that FLTK seems not to do anything WRT this, but maybe only relies on the system to Do The Right Thing. On X11, we set the "transient for" attribute, and I believe that we also set a window "parent" attribute on Windows. Albrecht _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
