Re: classic floating window behavior?
Re: classic floating window behavior?
- Subject: Re: classic floating window behavior?
- From: m <email@hidden>
- Date: Tue, 30 Mar 2004 13:05:35 -0800
On Mar 30, 2004, at 11:00 AM, M. Uli Kusterer wrote:
At 18:10 Uhr -0800 29.03.2004, m wrote:
Definitely not. Carbon has kFloatingWindowClass and
kUtilityWindowClass. The latter works like Cocoa's system-wide
floaters, the former stays in front of the frontmost document window
of your app.
Using either kFloatingWindowClass or kUtilityWindowClass as an
argument for setLevel results in the identical behavior.
They actually should result in nonsense. They're window classes, not
window levels. They have to be passed to Carbon APIs, not to Cocoa's
setLevel: method.
So I tried creating a window using the Carbon API's in my awakeFromNib
method thusly:
mFloater = nil; // instance variable of my Controller class
WindowRef windowRef;
Rect bounds = { 600, 100, 800, 200 };
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?
I also tried:
SetWindowClass((WindowRef)[mFloater windowRef], kFloatingWindowClass);
// note that using SetWindowClass() is discouraged.
[mFloater setHidesOnDeactivate:NO];
(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.
_murat
_______________________________________________
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.