Re: NSDrawer delegate function mis-described?
Re: NSDrawer delegate function mis-described?
- Subject: Re: NSDrawer delegate function mis-described?
- From: Shaun Wexler <email@hidden>
- Date: Mon, 27 Jan 2003 22:40:28 -0800
On Monday, January 27, 2003, at 09:19 PM, Ben Kennedy wrote:
Shaun, thanks for the help. I've been able to solve my problem (at
least
so far, it seems) by adjusting windowDidResize as thus:
- (void) windowDidResize:(NSNotification*)note
{
float windowHeight = [[note object] frame].size.height;
float minus = [drumsDrawer contentSize].height + [drumsDrawer
leadingOffset] + 39;
[drumsDrawer setTrailingOffset:(windowHeight - minus)];
return;
}
and (the other key part) setting the minContentSize of my drawer in IB
to
1. By setting the window minimum size to a reasonable value (bigger
than
the drawer), the drawer's contentSize will remain constant.
I'm a bit leery about the magic constant 39, but that's what I came up
with from calculating ([window frame].size.height - [drawer
leadingOffset] - [drawer contentView].size.height - [drawer
trailingOffset]) via an NSLog() with the window in its smallest
permissible size. And it works.
float windowTitleBarHeight == 22;
float drawerContentViewFrame.size.height;
float drawerWindowFrame.size.height =
drawerContentViewFrame.size.height + 17;
Magic constant: 22 + 17 = 39
Once again, the bug resolves to the private NSDrawerWindow frame
size... ;)
Mildly off-topic, what is NSDrawerWindow? I realise that in your code,
the notification object calling -[DrawerToggle windowDidResize:] is
sometimes an NSDrawerWindow* instead of an NSWindow*. I thought the
drawer's parent window is the window to which it's attached, which
began
life as an NSWindow...?
-ben
--
Ben Kennedy, chief magician
zygoat creative technical services
613-228-3392 | 1-866-466-4628
http://www.zygoat.ca
NSDrawerWindow is the private subclass of NSWindow owned by an
NSDrawer. It encloses the themed frame and drawer's content view. The
NSDrawer offset properties reference this object's frame as a relative
distance from the window's content view frame. If you are referring to
this method in my DrawerToggle class:
- (void) windowDidResize:(NSNotification *)notification
{
NSWindow *window = [notification object];
if (window == [attachedDrawer parentWindow])
[self _offsetForWindow:window];
else if (window = [self window])
[self _updateForWindow:window];
}
Calling _offsetForWindow: only happens if the drawer is attached to a
NSWindow, which returns nil if not, thus reverting to
_updateForWindow:, which sets the proper image for the DrawerToggle
button (not necessary if the drawer is open, since it's always the
"open" image). If this notification is received from an
NSDrawerWindow, it is ignored. My app (MacFOH) may have multiple
DrawerToggle instances per module/per window, so to "properly" handle
things, I should probably track the DrqawerToggle's NSView as it is
added and removed from the view heirarchy, but just watching for all
windowDidResize: notifications is easier, with less overall overhead, I
think. YMMV. Pretty cool class, BTW...did you try the demo app?
;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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.