On May 26, 2005, at 10:45 PM, Laurence Harris wrote:
Sometimes applications open new windows behind the windows of the
active
application, and sometimes they open them on top of all other
windows (but
usually without getting focus, which is annoying). At least this is
what I
see in 10.3.9. I'm wanting to open a window with the results of some
processing. In the past when my application was in the background I've
posted a notification and then opened the window when my
application was
brought forward, but I want to change that to open the window and
then post
the notification. However, I don't my window opening in front of other
applications. How can I ensure that doesn't happen? I'm asking
because I'm
not really sure why some windows open in front of the active
application and
others don't. Any thoughts? Thanks,
The short answer is: don't worry about it, because there's really
nothing you can do anyways. Just create your window, and the OS will
do its best to open it at an appropriate location. Sometimes, we get
this wrong; those are our bugs, and in that case, we'd like to hear
about it so we can try to fix them.
The long answer:
When an app creates a new window that is at the top of its window
list, both Carbon and Cocoa call the window server to make the window
visible using a private function that conditionally orders the window
frontmost. The conditional part is dependent on whether the app that
owns the window is currently the frontmost process. If so, then you
get the normal expected behavior; the window is ordered to the very
top of all windows at that window level. The case you're interested
in occurs when the owning app is not the frontmost process. In that
case, the window server attempts to position the window behind the
active window in the frontmost process.
Determining exactly which window is active can be a somewhat tricky
business. For example, the active app might have two floating windows
plus a document window open. A new window opened by an inactive app
should go behind the document window, not behind any of the floating
windows. The Carbon Window Manager tracks which window is currently
the active window (this would be the window that is returned by
ActiveNonFloatingWindow) and tells the window server when it changes,
so the window server can put newly opened windows behind that window.
Occasionally, you'll see applications that do all of their own window
management with BringToFront and HiliteWindow, and never actually
call SelectWindow or ActivateWindow; in this case, the Window Manager
has no information about which window is active, and you can
potentially wind up with windows from background apps opening at the
wrong z-order.
We did fix some common cases of background windows opening in front
of the active app's active window some time ago, around 10.2 I think.
I haven't seen any new reports of this occuring in quite a while. If
you have specific reproducible cases, I'd like more information.
-eric
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
