On Oct 23, 2008, at 1:46 PM, Andy Lee wrote:
On Oct 23, 2008, at 12:30 PM, Eric Gorr wrote:
On Oct 23, 2008, at 11:35 AM, Andy Lee wrote:
You have the text field set to grow and shrink in proportion to
its superview. In the Size inspector, note the red double-ended
horizontal arrow inside the box. In the parlance of struts and
springs, that is a "spring." Click that spring to turn it off,
and also turn off the strut on the right side outside the box. In
other words, only have two struts turned on: the ones on the top
and left.
Please try this yourself and then shrink the window to it's
smallest height. The 'Label' text will disappear.
You are right -- I only noticed a problem with the width, but I see
that is not what you are asking about, since the text view does
reappear if you only resize horizontally.
The reason the label disappears is that when you make the window
small, the text field's width scales to zero. When you expand the
window again, IB scales the width accordingly (as you specified)
-- except now it's scaling zero, which always returns zero.
The problem occurs not when I change the width of the window. The
problem occurs when I change the height.
The same reasoning applies except in the other dimension. One or
more vertical distances are getting scaled to zero, and this
produces undesired results. If you change the height gradually up
and down you will see the text field get shoved up and out of view.
The solution is to either impose a minimum size on your window or
implement your own autoresizing as Cathy Shive did.
Related problems have been reported before, for example with the
subviews of split views. Bottom line: if at all possible prevent
any of the relevant measurements (width, height, margins) from
scaling to zero. In addition, for each direction I personally try
to have two of the three measurements be fixed, to avoid tiny errors
that I'm guessing are caused by roundoff when two or three of the
measurements are "springy." When two of the three measurements are
fixed, IB only has to do subtraction to compute the third -- no
division.
I suspect your particular problem occurs vertically and not
horizontally because of the coordinate system. Shrinking the window
increases the y of the bottom edge but decreases the x of the right
edge. This is just a guess as to why the behavior is not
symmetric. I would call it an annoyance rather than a bug, but
either way, it should be fine to submit a Radar.
Ok, so, now there is an understanding of the problem, I will try to
explain why I need a workaround.
I have an NSPanel and need to implement some window shading
functionality - i.e. the content area is hidden and only the title bar
remains. Unfortunately, this means that the height of the content area
does become zero.
Outside of the window shade functionality, I do have a minimum size
defined so a user will not be able to get themselves into this
situation simply by resizing the window.
Fortunately, part of the design of these panel's is that the content
view will contain a view (call it THE_VIEW) that contains all of the
controls for the NSPanel.
A workaround (which I've just implemented) that seems to work is when
the window shade is activated, I remove THE_VIEW and then shrink the
window. When the window shade is activated again, indicating that the
contents of the panel should reappear, I grow the window and then add
THE_VIEW back to the content view. This probably wouldn't work well if
I needed to animate the shrinking & growing, but I don't need to worry
about that for now.
If anyone has any alternative suggestions, thoughts or comments, I am
interested.
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
