On Aug 6, 2014, at 8:40 AM, Ken Thomases <k...@codeweavers.com> wrote:

> On Aug 5, 2014, at 11:36 PM, Daryle Walker <dary...@mac.com> wrote:
> 
>> I’m using the Size Inspector for my document window’s XIB to create a Small 
>> Bottom Border as a Content Border.  From the top to the bottom of my window, 
>> not counting the title and tool bars, I got:
>> 
>> 1. 20 pts. space w/ Autolayout
>> 2. Text-editing (1 line) field, changing its size width-wise as the window 
>> does
>> 3. 8 pts. space w/ Autolayout
>> 4. WebView, changing its size as the window does
>> 5. Formerly 0 pts. space, now 22 pts. space, both times with Autolayout
>> 
>> The 22 pts. of space added to the bottom exposes the Small Bottom Border.
>> 
>> I made a menu item to turn on/off the Status Bar.  I even put a check mark 
>> there as appropriate.  The problem is that the Bar doesn’t actually 
>> disappear, it just looks inactive.  If I try messing with the window’s frame 
>> NSRect, I shrink the WebView with the window but keep the Bar.  If I try 
>> messing with the WebView’s frame NSRect, the WebView just shifts down and 
>> leaves extra space on top.
> 
> When you're using auto layout, you should not manipulate view frames 
> directly.  Instead, you modify or replace the constraints.
> 
> In your list above, number 5 indicates you have a constraint determining the 
> spacing between the web view and the bottom of the window content view.  So, 
> you want to adjust that.  Presumably, it's of the form contentView.bottom =  
> webView.bottom * 1 + 22 (or possibly reversed order with a negative 
> constant).  So, you want to adjust that constant term to 0.
> 
> You can create an outlet from your controller class to the constraint.  
> Connect it in the NIB.  Then, you can refer to that constraint in your code 
> and set its "constant" property.

I think I read about that once, that since the constraints are in the Interface 
Builder list, you can play outlet games with them.

Your idea mostly works:

//=====
- (BOOL)showingStatusBar
{
    return !![self.windowForSheet contentBorderThicknessForEdge:NSMinYEdge];
}

- (void)hideStatusBar
{
    NSWindow * const  window = self.windowForSheet;

    //[window setAutorecalculatesContentBorderThickness:NO forEdge:NSMinYEdge];
    [window setContentBorderThickness:0.0 forEdge:NSMinYEdge];
    self.bottomSpacing.constant = 0.0;
}

- (void)showStatusBar
{
    NSWindow * const  window = self.windowForSheet;

    //[window setAutorecalculatesContentBorderThickness:YES forEdge:NSMinYEdge];
    [window setContentBorderThickness:PrStatusBarHeight forEdge:NSMinYEdge];
    self.bottomSpacing.constant = PrStatusBarHeight;
}

- (IBAction)hideShowStatusBar:(id)sender
{
    if ([self showingStatusBar]) {
        [self hideStatusBar];
    } else {
        [self showStatusBar];
    }
}
//=====

When first turning off the status bar, Xcode’s debugger showed an exception, 
due to a constraints conflict.  There’s a 22 pt gap between the WebView and the 
bottom of the window, and two 4 pt gaps between the Status Text and both the 
WebView and window bottom.  I took care of it by changing the two Status Text 
constraints’ priorities from 1000 (the default) to 999, so the 
WebView/window-bottom constraint always wins.

Apple’s guides suggest calling [window 
setAutorecalculatesContentBorderThickness:NO forEdge:Whatever] whenever calling 
[window setContentBorderThickness:Something forEdge:Whatever].  Should I still 
call “…Auto…”?  If so, should it go next to the “setContent…” call?  If so, 
before or after?  Should the “…Auto…” call be done once in a central location, 
like the XIB’s awakening method, instead?  Can I do this adjustment within the 
XIB instead?  Will I ever need to call “…Auto…” with YES?

— 
Daryle Walker
Mac, Internet, and Video Game Junkie
darylew AT mac DOT com 

_______________________________________________

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

Reply via email to