• 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
Re: Window group hierarchy
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Window group hierarchy


  • Subject: Re: Window group hierarchy
  • From: Tom Sutcliffe <email@hidden>
  • Date: Mon, 5 May 2003 17:36:55 +0100

One way is to have all your top-level windows to be Floating (on a system level) then set them to return to a normal level whenever the application deactivates. You could have a subclass of NSWindow that listened for ApplicationDidDeactivate notifications (and didActivate, didUnhide etc) which would save you explicitly handling each window in your App's delegate method.

Child windows do something similar as part of their behaviour but wouldn't really be suitable here as they only order themselves relative to their parent window and not all windows of that class.

Possibly also the window's delegate could manually force the behaviour you want in one of the windowDidDoSomething methods with lots of order: relativeTo: but it would be a lot of hassle.

And don't forget there's always setHidesOnDeactivate: if you don't mind the window actually disappearing.

Regards,

Tom

On Monday, May 5, 2003, at 04:56 pm, Finlay Dobbie wrote:

On Monday, May 5, 2003, at 03:44 pm, Eric Schlegel wrote:

I am trying to create a two-level window hierarchy in my application - normal windows and top-level windows. I do not want to have floating panels, because that works on a system level. I want to have hierarchy just within my application. So I thought I would achieve that with window groups. But nothing happens - windows from normal level, when clicked, move in front of top level windows...

The WindowGroup API only works in Carbon applications; it doesn't work in Cocoa apps. The implementation requires that the Carbon Window Manager be in control of window z-ordering, so that it can properly position a window considering its window group relative to other windows. In a Cocoa app, the Carbon Window Manager is not running.

There is something similar, though, isn't there? Never used either, so I can't be sure :-)

#if MAC_OS_X_VERSION_MAX_ALLOWED >= MAC_OS_X_VERSION_10_2
- (void)addChildWindow:(NSWindow *)childWin ordered:(NSWindowOrderingMode)place;
- (void)removeChildWindow:(NSWindow *)childWin;
- (NSArray *)childWindows;

- (NSWindow *)parentWindow;
- (void)setParentWindow:(NSWindow *)window;
#endif

-- Finlay
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

References: 
 >Re: Window group hierarchy (From: Finlay Dobbie <email@hidden>)

  • Prev by Date: Re: Update tool tip
  • Next by Date: Re: Can't modify existing user interface
  • Previous by thread: Re: Window group hierarchy
  • Next by thread: Can't modify existing user interface
  • Index(es):
    • Date
    • Thread