Thanks, guys, for all the help.
Of course the implementation below is meaningless, and also isn't the right
thing to do --- It should have returned min/max size if at all.
I only put it to see if I get there in the debugger (set a breakpoint on the
strange lower-than-minimal situation).
- (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
NSSize min = [sender minSize];
NSSize max = [sender maxSize];
if (frameSize.width > max.width ||
frameSize.height > max.height ||
frameSize.width < min.width ||
frameSize.height < min.height)
return sender.frame.size;
else
return frameSize;
}
The application UI is dynamic and quite complicated. It's built from
plugin-like modules, each with its own code and .xib with its min/max sizes.
After I load all my modules I lay-out my main window with these sub-views, and
calculate the overall min/max content size for the window. I then
setContentMinSize: and setContentMaxSize: This mechanism works fine.
Calculations are right, and have been thoroughly tested.
There is no way I missed setting the window delegate, because
1. I set it for sure (double-checked the code and .xib, and my
NSWindowController is also the delegate for its window).
2. many other window-delegate calls are being called without a problem.
3. This very implementation DOES GET CALLED, except for in the transition to
FullScreen!
I can send in any log that will shed light of this behavior, but spending the
last 2 months rolling my own "auto-layout" mechanism, believe me I know when
window-size is getting wrong.
The snippet I used, is where the problem affects the user --- there is some
split-view with several internal "panels" (sub-views) and one of them is
automatically collapsed (because the split-view becomes too small for all the
panels in their min-size). I have min/max sizes all the way down. So it's
really weird for a user to have one panel auto-collapse, when enlarging the
window to full-screen.
On 22 ביול 2012, at 20:22, Quincey Morris wrote:
> On Jul 22, 2012, at 02:00 , Motti Shneor wrote:
>
>> - (NSSize)windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize {
>> NSSize min = [sender minSize];
>> NSSize max = [sender maxSize];
>> if (frameSize.width > max.width ||
>> frameSize.height > max.height ||
>> frameSize.width < min.width ||
>> frameSize.height < min.height)
>> return sender.frame.size;
>> else
>> return frameSize;
>> }
>
> AFAICT this implementation doesn't do anything. As was mentioned in another
> thread yesterday or the day before, and in the class documentation, the
> min/max constraints have already been applied when this method is called, so
> re-testing the constraints is pointless.
>
You're right. This was only debug-code to let me see if this delegate gets
called with lower-than-minimum size, and if its implementation could save me in
transition-time to full-screen. Unfortunately, it doesn't
> Of course, that doesn't explain how the window gets smaller than it should be.
>
> (Also, it seems wrong to return sender.frame.size, since that would prevent
> the window from actually getting pinned to the limits enforced by this
> method, if there were any.)
>
See above.
> (Also, if you're using min/maxContentSize as shown in your other code sample,
> you should check that everywhere rather than min/maxSize in some places. The
> documentation says the min/maxContentSize constraint "overrides" min/maxSize,
> not "sets" it.)
As explained above, I have a whole mechanism for that. Every module calculates
its own min/max size from its own constraints and its sub-module constraints,
and "reports" it up. This is done recursively, and the window's contents view
is just at the top.
>
>> 2012-07-22 11:44:01.178 AT&T Connect[19369:407] Window min content
>> size:{1001, 579} current size {1001, 517}
>>
>> As you can see, my window is forced to get to 517 pixels height, despite my
>> imposed minSize of 579 pixels, and in spite of the implementation you
>> suggested.
>
> It would be slightly more reassuring to log all of the window's size, with
> min and max, as well as the content size, with min and max, as they are this
> moment in execution.
>
> Incidentally, NSWindow's 'setFrame:display:' is documented to ignore the
> min/max sizes. Is there any place you're calling this yourself?
Nope. Never. My windows are plain NSWindow instances until now, but I could
create a subclass, for the sake of pinning down a "setFrame:display:" with
lower-than-min size, just to prove it happens.
One thing you say raises a question, though. How can minContentSize: "override"
the "minSize" ? these are two different sizes, isn't it?. I'm using
setContentMinSize because I don't know how to calculate the "minSize" which
also depends on the presence of tool-bar, title-bar and other window parts that
can change with versions of the OS. Am I wrong here? should I directly call
setMinSize/setMaxSize on my windows?
I assumed that the window's minSize is calculated from its contentMinSize, plus
the other parts of the window.
Motti Shneor
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
