• 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: classic floating window behavior?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: classic floating window behavior?


  • Subject: Re: classic floating window behavior?
  • From: "M. Uli Kusterer" <email@hidden>
  • Date: Wed, 31 Mar 2004 18:45:28 +0200

At 13:05 Uhr -0800 30.03.2004, m wrote:
So I tried creating a window using the Carbon API's in my awakeFromNib method thusly:
OSStatus status = CreateNewWindow (kFloatingWindowClass, kWindowStandardFloatingAttributes, &bounds, &windowRef);

if (status == noErr)
{
mFloater = [[NSWindow alloc] initWithWindowRef:windowRef];
[mFloater orderFront:self];
}

The result was a window that did not float above my app windows or any other apps windows. In fact, it didn't respond to clicking at all. Must be more to it, eh?

You would have to install a standard handler, probably.

SetWindowClass((WindowRef)[mFloater windowRef], kFloatingWindowClass);

(mFloater in this case is a pre-existing NSPanel instantiated from the Nib file.) In this instance, I got a floating window that still floats above all app windows.

Okay, then it looks like I simply remembered something of the way it worked in OS 9. This definitely used to work this way in Carbon, but I guess they don't have any application-specific layers in OS X anymore. I see one more venue to investigate:

Use setLevel: to move your window into the document layer, and use a category to replace orderFront: and any other window-order-changing methods with a method that does the same as orderFront: (never done this, but I heard it is messy because you need to get the IMP of the original method to be able to call it and only *then* load the category, e.g. from a bundle) and afterwards sends all your floaters an orderFront: as well.

You could of course also just discard the entire idea for now and simply file an Enhancement Request with Apple's Bugreporter and hope they agree this is needed and add it.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
_______________________________________________
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.


  • Follow-Ups:
    • Re: classic floating window behavior?
      • From: m <email@hidden>
References: 
 >classic floating window behavior? (From: m <email@hidden>)
 >Re: classic floating window behavior? (From: "M. Uli Kusterer" <email@hidden>)
 >Re: classic floating window behavior? (From: "M. Uli Kusterer" <email@hidden>)
 >Re: classic floating window behavior? (From: m <email@hidden>)
 >Re: classic floating window behavior? (From: "M. Uli Kusterer" <email@hidden>)
 >Re: classic floating window behavior? (From: m <email@hidden>)

  • Prev by Date: Re: [ANN] Shovel - Third-Party "Software Update"
  • Next by Date: Re: Why does this keep sending EXC_BAD_ACCESS
  • Previous by thread: Re: classic floating window behavior?
  • Next by thread: Re: classic floating window behavior?
  • Index(es):
    • Date
    • Thread