Has anyone else seen this?
Make a new Cocoa application project in Xcode 2.1. Open the MainMenu.nib file. Show the inspector for the window in that nib, and switch to the Size panel. Try to make the minimum and maximum sizes for the window the same, either by typing in numbers or hitting the “Current” buttons.
Can’t do it, can you? Whenever you try, Interface Builder automatically “fixes” the maximum value so it is 1 greater than the minimum value. The hell? What if I want the window not to be able to resize vertically or horizontally? It does this for every window, in every nib.
And while 1 pixel may not seem like much, it is definitely visible to the end user, which makes the whole interface look unpolished.
The workaround is to set the min and max values to the same thing programmatically, but that’s a pain in the ass, eh?
I didn’t see anyone complaining about this on the Apple mailing lists. Did this used to work? Am I missing something? Is this just a small enough deal that people live with it? (I’ve filed a bug.)
It also doesn’t look like I can make a little utility based on nibtool to fix this after I’ve made the nib in Interface Builder; while nibtool can show me the offending min/max values in text form, I can’t modify the text, then feed it back into nibtool to generate a changed nib.
I am using the Cocoa UI APIs and Interface Builder again after a hiatus, and I’m finding far more of these workarounds necessary than I would like for a “best of breed” technology.
Weaponized Fluff 
Is it possible that you’re overlooking the “Zoom (and resize)” checkbox in the Attributes pane for the window? Perhaps the minimum and maximum values are implicitly meaningful only for resizable windows?
File thy bugs…and note that there’s an open IB req, if you want to fix the bugs yourself. 🙂
Daniel Jalkut:
> minimum and maximum values are implicitly meaningful only for resizable windows
This is true. The problem case is when you want to restrict resizing in one direction, but not both – “both” is handled properly by disabling the “Zoom (and resize)” green window title bar button.
Eric Albert:
> note that there’s an open IB req, if you want to fix the bugs yourself. 🙂
Don’t tempt me.
AAAGH. Non-resizable windows are EVIL. I’m the end user, not you, and I’ll resize the windows if I want to!
I was all hopeful for a minute, thinking Cocoa was smart enough to just make it impossible for programmers to screw the user over like that, but the 1 pixel thing is even stupider. Bah.
Andrew, that’s definitely a new one. I distinctly remember doing such windows a lot in pre-Tiger IB. IB *did* have a problem with drawer height/width, where it would mix up width and height and e.g. fix the editable width to the owning window’s height, while it didn’t touch the un-editable dimension at all… But apart from a little iffyness when switching the side a drawer is on which I just can’t seem to pin down, that seems to be fixed now.
And as to non-resizable windows being evil … uh… what?! There are many cases where it makes complete sense for a window not to be resizable. The only thing that is bad is if you really have a size box but fix both dimensions. If you tried that, I’d guess it’s an unexpected case and thus no surprise it doesn’t work.
Oh, and yeah, the open IB position is *really* tempting. If it didn’t involve moving to Cupertino in the midst of my studies…
Does it have to be through IB? Hillegass 2d ed. p 119 mentions how to do it in code, using a window delegate that returns the constrained size:
-(NSSize) windowWillResize:(NSWindow *)sender toSize:(NSSize)frameSize;
Just take the frameSize the user wants and return an NSSize with the height always constant, or the width.