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 16:07:39 -0800
Yes!!!
I've previously filed this same bug, to no avail. So far, I've only
received stock responses, such as "Use leading and trailing offsets to
constrain the size. See DrawerMadness for an example. Bug Closed."
Well, DrawerMadness doesn't have a fixed-size drawer on the MinX or
MaxX edge! If you try to modify its code to do this, it doesn't work
either, as per the bug. It only works for a drawer on the MinY edge.
Scott Anguish has tried to help me with this issue, and was going to
look into it by modifying DrawerMadness and reproduce the improper
window behavior many of us have experienced...
I had to perform an extensive workaround to get this to function
correctly, as per the doc's. Set the minimum drawer content height to
a small number such as 1.0f, and constrain the window's min height
programmatically, as appropriate. Performing a correct offset
calculation also requires using the height of the private
NSDrawerWindow, which is available via [[[drawer contentView] window]
frame], which in itself should be filed as another bug, since the
leading/trailing offsets are referenced to the private NSDrawerWindow's
frame size, not the drawer's contentView size. Also, I don't attach
the drawer unless it's needed, so the window can be resized smaller
than an open drawer would allow (which isn't related to the bug).
Within drawerShouldOpen, I attach it to the window, after first growing
the window's frame if necessary.
In searching online archives, I have not seen any acknowledgment of
this bug, and most requests for help on this issue seem to go
unanswered. I wrote a demo app to illustrate the NSWindow/NSDrawer
bug(s) to Apple. The parent window's minSize is set by the drawer when
attached, using the offsets as if they were a mandatory sizing
requirement. Even when setting the drawer's minContentSize to a low
number, when resizing, the window will eventually begin in increase its
minSize using the offsets and minContentSize.height, regardless. My
demo app clearly shows the problems (I hope).
The leading and trailing offsets should not be "enforced" by the
window. They should be used as "hints", and if the window is not large
enough to support the drawer using the requested offsets, then the
window should proportionately decrease the offsets, until pinning at
the drawer's minContentSize with default min offsets of 0.0 and 15.0,
to protect the drawer frame and shadow from being revealed. The
current NSWindow behavior is a kludge here. What I'd like to see added
are (bug fixed and) a few extra NSDrawer properties:
"minLeadingOffset" and "minTrailingOffset", to which the window would
pin to 0.0 and 15.0 if the drawer was on MinX or MaxX edge, and a
property of "usesFixedSize", to toggle between using the standard fixed
offsets and the new variable min__Offsets. Oh, plus "drawerWindowSize"
to get the NSDrawerWindow's frame size, so we can calculate proper
offset references. Should I file a feature/bug?
Hopefully, this has been of some help. If you can't get it working
soon, email me for my workaround code. ;)
--
Shaun Wexler
MacFOH
http://www.macfoh.com
On Monday, January 27, 2003, at 01:46 PM, Ben Kennedy wrote:
Hi all,
I am trying to implement code to keep an NSDrawer (attached to a
document
window) at a fixed size when the user resizes the parent window.
According to the doc, I should be able to override the delegate method
drawerWillResizeContents:toSize:. However, this method appears only to
be called when the drawer itself is being resized manually, and NOT
when
the parent window is resized. Quoth the doc,
Invoked when the user resizes the drawer or parent. contentSize
contains
the size sender will be resized to. To resize to a different size,
simply
return the desired size from this method; to avoid resizing, return
the
current size. [...]
Is this a bug in the implementation, or in the doc?
More to the general point, can anyone suggest how to achieve what I
want
to do? It seems that the "content size" of the drawer is ignored in
favour of the leading and trailing edge sizes; for example, putting a
call to [drawer setContentSize:NSMakeSize(100,100)] in the parent
window's windowDidResize: delegate implementation causes the drawer to
resize to 100 wide, but its height still varies as per the trailing
edge
value (the 100 width value is ignored).
So, instead I have tried adjusting the trailing edge value in
windowDidResize: instead. Unfortunately, this only works for sizing
the
window larger -- not smaller. The window is only allowed to grow, and
is
prevented from shrinking. I suspect this is because I also have resize
increments set on the window (such that it is only allowed to size
vertically in intervals of ~150 pixels), and the system is noticing
that
the drawer's current trailingOffset is too large to allow the window to
shrink by the increment. It's a chicken/egg situation. I have tried
moving the drawer adjustment to windowWillResize:toSize: instead, but
this results in ugly flicker as the drawer size flips around
repeatedly.
Clearly 'didResize' is preferable to 'willResize' for such an
adjustment.
Ideas? Surely the problem of a fixed-size drawer has been tackled
before...
-ben
--
Ben Kennedy, chief magician
zygoat creative technical services
613-228-3392 | 1-866-466-4628
http://www.zygoat.ca
_______________________________________________
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.