Thanks Quincey, First of all, you've got a good idea of what I'm trying to do - so for my first question about how to make the text view fill the remaining space, I think you're of the mindset that I'll need to manually calculate that distance and set an internal height constraint on the text view.
That answer then drives the answer to the second question about what to do when the keyboard comes up. In my case, I want to *both* scroll the view up *AND* shrink the text view's height (since the previously mentioned remaining space in the view is most likely not going to equal the area left above the keyboard). It sounds like you're leaning toward adjusting the internal height constraint on the text view. Now, I consider those manual calculations very similar to what I'd have to do were I laying the scroll view out via frames --- (overriding layoutSubviews, etc). And in that regard, I think that in this scenario, using frames would be slightly more literal for roughly the same amount of work for roughly the same calculations. ie: frames might be more readable and quickly grokkable later on. This technical note <https://developer.apple.com/library/ios/technotes/tn2154/_index.html> seems to imply that either approach is fine. My brief exploration here was to make sure there wasn't some OTHER way to setup AutoLayout for this scenario --- the "scroll view" is the wrench in this equation since it auto sizes its content view and consequently, cannot tell the text view how large to be. In this case, I really don't want the scroll view auto sizing its content view .... but I do want the scrolling animation and dismissal behavior. Seems like I'll need to create something manually then. Maybe a non scroll view parent, an affine transform and a pan gesture recognizer would simplify the layout sizing logic and get me closer to the behavior I want. In the end, I'm just looking for the simplest way to implement the resulting effect. Many thank! On Sun, Jul 27, 2014 at 1:12 AM, Quincey Morris < quinceymor...@rivergatesoftware.com> wrote: > On Jul 26, 2014, at 22:19 , Luther Baker <lutherba...@gmail.com> wrote: > > Are you hoping that when the keyboard comes up -- it shortens the parent > view you are referring to? > > > No, it’s more complicated than that, but I think it’s the *question* > that’s complicated, more than the answer. > > First you have to decide what you actually want to happen when the > keyboard is up. You have 4 views, you said, 3 of which I assume are short > (maybe about 1 line high each), and the last of which takes up the rest of > the screen normally. > > So, when the text view becomes first responder and brings up the keyboard, > do you want all of them to keep their original sizes, but just scroll what > doesn’t fit off the top of the screen? Or do you want to have the top 3 > views to keep their original sizes, and the text view to get smaller > according to how much space is left by the keyboard? Or something else? > > If you don’t need to change the scroll view’s size (if “yes” to the first > question — which I think is what you originally described as the goal), > then setting the content and scroll indicator insets (along with scrolling > the current insertion point onto the screen) ought to be all you need. You > don’t actually need to resize anything. > > If you need to change the scroll view’s size, then any auto layout > constraints *inside* the scroll view should keep your text view at a > suitable size, and you shouldn’t need to muck about with the layout inside > the scroll view manually. The problem then becomes one of getting the > scroll view itself sized correctly. > > If the scroll view itself is subject to auto layout constraints relative > to its own ancestors and siblings, I guess you’ll have to update its > height-controlling constraint, *or* override its superview’s > ‘layoutSubviews’ to set its frame directly after auto layout has had at it. > > If the scroll view is not subject to auto layout constraints, then you can > just resize it directly. > > That’s a lot of if’s… > > _______________________________________________ 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
