When resizing a UIView to height or width zero, springs and struts stop working permanently

Question

I'm trying to workaround a long-running bug in Apple's SDK here, but I can't see how to achieve it without huge amounts of code.

Here's the bug:

1. Create a view.
2. Put another view inside it, with an origin ANYTHING except (0,0).
3. Configure the subview to resize to fill

...then, at runtime: 4. Set the superview size to zero 5. Set the superview back to ANY non-zero size

BANG! Apple's SDK goes haywire, resets the origin of the subviews, loses all ability to tell up from down, etc. (seems like the programmer "Forgot" to include a variable to record what the spring/strut-size was before it went to 0).

I've heard this bug has existed in OS X for 5 years or so, and Apple still hasn't fixed it. What I would like is some way (any way!) of working around it, without re-writing Apple's entire springs/struts system and implementing it properly, without the bug. Unfortunately, I can't even find the original references to the OS X bug that someone showed me previously.

EDIT:

...I have a resizing "drawer" at the bottom of the screen that has to shrink to small height. The problem is subviews "collapsing" all down to origin 0 (amongst other things) at the drop of a hat (technically: they're reducing their origin.height, but not re-increasing it).

Answer 1

The best solution I have found is to limit your minimum window size so that none of your views can ever hit zero size.

Answer 2

EDIT: an hour later, the collapsing behaviour has returned, without me touching the source files. I'll use source-control to double-check, but I believe all that happened is I added other files to a different part of the view-hierarchy and re-built. Argh!

(what follows SEEMED to work, but is now failing again, in the same way)

Hmm. So, I had two UIVC's on one screen. Refactoring so that I only had one made the resizing bug vanish. It seems to be a bug in the UIVC layout code.

NB: I had the idea this might be a problem because I know Apple currently advises you to only have one UIVC on screen at once with iPhone, even though this means you have to ignore their MVC architecture for complex apps. So, technically, they warn you away from this. But, at the same time, I'm now unable to use the MVC stuff for this code.

The following worked (for my current example - may not be universal!).

HOW:

1. If you're adding any UITableViewController instances ... give up. You'll have to re-implement that class yourself
2. Find my subviews that were in UIVC instances, and change the extended class in the UIVC header from "UIViewController" to "NSObject"
3. Move all code from viewDidLoad to init (remembering that "init" has special rules about first few lines etc)
4. Replace the instantiation of that UIVC from "[[vc alloc] initWithNibName:nil bundle:nil]" with a plain "[[vc alloc] init]"

Answer 3

Another potential workaround (that works in my current situation):

The only View I have right now that MUST have a non-zero origin and MUST resize-to-fit is a UITableView.

Apple has a special feature of letting you put any view as a "table-header".

So ... I've taken all my other components, stuck them in a large view, and made that the table-header view.

The downside is that they now scroll off the top when you scroll the table, but it allows me to give the table a zero-origin, working around the SDK bug.