• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
window de/activation notifications (was Re: inappropriate tool palette activation problem)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

window de/activation notifications (was Re: inappropriate tool palette activation problem)


  • Subject: window de/activation notifications (was Re: inappropriate tool palette activation problem)
  • From: John Richetta <email@hidden>
  • Date: Fri, 19 Oct 2007 13:02:28 -0700

On Date: Thu, 18 Oct 2007 09:42:24 +0200, Uli Kusterer said:
Am 18.10.2007 um 02:53 schrieb John Richetta:
I also don't know why I'm receiving seemingly incorrect, or at least very unnecessary, extra window activation and deactivation notifications, via didBecomeMain and didResignMain, but this is a separate topic, and I can probably get to the bottom of these issues.

The apps that don't have this are probably Carbon, are they? Or maybe they're just using non-activating panels. The new behaviour has two activation states. One is the "main" window, which has the gradient, and the other is a more subtle "frontmost window in its layer" hightlight.


This distinction is actually very useful, in particular for controlling an app via keyboard. You can use Cmd-~ (or Cmd-< on some localized keyboards) to make whatever window you want main, floater or document. And then the "Zoom" and "Minimize" menu items will apply to that window. Same goes for the "Close" menu item. Before Apple introduced this behaviour, it was impossible to perform the actions of the window widgets under keyboard control for some windows.

I tend to be a stickler for UI details, but I admit that I hadn't noticed a distinct "frontmost in its layer" highlight. However, my point was a different one (which I again explained inadequately). This (second) problem is not about appearance but rather notifications.


For my application to properly load and store object state used by its inspector window, I must know about application windows being activated and deactivated (this terminology which was previously very clear on Mac OS is no longer consistently applied in the documentation; often, but not always, the NeXT terminology of "ordering front" is used, or the term "main" - which doesn't appear to be really precisely defined anywhere).

The inspector must always synchronize with the frontmost document, and save changes made to frontmost document before it loses that status. Although it is in fact rare for changes to be committed later rather than at the exact time they are made in the inspector window, it is still possible, and so these notifications are important.

It took me a while to determine how to obtain these notifications. In older Mac OS, these were events delivered to all apps, without requesting them specially, but now, apparently, one must subscribe to the didBecomeMain and didResignMain notifications. I've done this, and these notifications are being sent to my documents, which then message the inspector appropriately.

However, either I am getting too many notifications, or I don't understand their meaning correctly. They are sent at times and/or for reasons that seem to be more complicated than simple window activation and deactivation. Specifically, here is what happens in my application, assuming document A is initially in front of document B, and one clicks on document B:

   1. app receives a deactivate (windowDidResignMain) for document A
   2. app receives a deactivate for document B
   3. app receives an activate (windowDidBecomeMain) for document A
   4. app receives an activate for document B

If one then clicks on document A, one will receive the *exact* same sequence all over again!

I can't fathom why I receive deactivate and activate notifications for both windows, every time one window is clicked once. Further, the notification order does not match what I would expect (it seems to match temporal order of window *creation*). This pattern extends to the case when many windows are on-screen: all send a notification for every window order change, and the order of the notifications from specific windows remains constant, regardless of window depth order.

I'm sure I'm misusing something, and the answer is probably staring me in the face...

Thanks for reading, and any further suggestions.  -jar
_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: window de/activation notifications (was Re: inappropriate tool palette activation problem)
      • From: Uli Kusterer <email@hidden>
    • Re: window de/activation notifications (was Re: inappropriate tool palette activation problem)
      • From: Murat Konar <email@hidden>
  • Prev by Date: NSTextView drag logs pasteboard message
  • Next by Date: RE: Progress bar on front NSPanel is grey not blue??
  • Previous by thread: NSTextView drag logs pasteboard message
  • Next by thread: Re: window de/activation notifications (was Re: inappropriate tool palette activation problem)
  • Index(es):
    • Date
    • Thread