Re: NSDrawer delegate function mis-described?

FROM : Shaun Wexler
DATE : Tue Jan 28 01:07:39 2003

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_removed>
> 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_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.