On Oct 4, 2016, at 10:27 AM, Fritz Anderson wrote: On 4 Oct 2016, at 9:50 AM, Alex Zavatone < email@hidden> wrote:
I know that dragging items from one view to another will reset the position of all the items, the position that we so carefully set up.
Is there any option while copying and pasting or while dragging to preserve the position of elements that we are moving?
In Xcode 7.3.1 or 8.x?
Could you clarify? I ask in part because I’m too lazy — oops, busy. Busy. — to try it myself.
Haha. We all know you're out in the hammock on the veranda sipping mint julips while reluctantly pressing keys. But I digress…
In my iOS Storyboards (my mistake for not specifying) I care about preserving the coordinates, the position of the elements, I laid out in one view when moving them to another.
Using teh Googles, I found out that one can select "Embed in View", but all I really want is that when copying "my stuff", my IB elements, that when I paste them that they end up with the same coordinates, not all smashed together on one line.
I can think of all kings of tools that preserve the coords of items that you have spent the time to lay out when moving those elements from one view to another.
It seems quite bass backwards that the IB specifically doesn't do this, unless you go through hoops. Is there a "paste and preserve position" option and if so, why isn't this the default?
Enquiring minds want to know™.
Thankye, sir.
Alex Zavatone
If you mean their layout in relation to the new view, as opposed to the layout in relation to the old one, I’m not surprised. Maybe the way I phrased it makes it clearer: A constraint between view A and superview Z connects to A and Z specifically, not A and whatever its superview is.
If I’m right, I would be surprised to learn that the constraints among A and its sisters B-Y disappeared. Possibly garbled because of the shape of the new superview, but not removed.
This is one reason I try to have as few constraints between a superview and its contents as I can: If A is at the top-left corner (x and y positions have to be set somewhere), then B-E in the top row are top-aligned to A (or the nearest neighbor) and horizontally spaced between each other. The next row, beginning with F, is top-spaced and left-aligned against the bottom of A, and the rest of the row is top-aligned with F and either fixed-spacing or center-aligned to B-E above them. Everybody has intrinsic, minimum, or mutually-proportional sizes. (Which strands you in PriorityLand with only a compass, a buck knife, and gumption. Sorry.) It all cascades.
There still have to be bottom and left constraints to set the absolute total height and width of everything, but that makes four constraints total instead of (12?), all of which will break when (from their point of view) the superview they relate to disappears.
It’s like Swift Strings: It’s horrible, but simplicity and correctness for users frequently turn out to be horrible for somebody else (as in nobody else but you and me).
I’m giving you the extremes, I’m too-specific in hopes of being clearer, and I’ve probably thrown in contradictory constraints. And maybe I misunderstand what you’re asking.
— F
|