On Nov 13, 2015, at 3:43 AM, Dragan Milić <[email protected]> wrote: > > Thanks for the suggestion, but unfortunately that didn’t help :-(
Hmm. Oh well. Your screencast of the failing case shows that you have some additional views (boxes, it looks like) in the hierarchy, and you haven't explained fully the constraints involved. > What I fail to understand is why splitView’s subviews holding priorities > would matter at all, especially while dragging its slider. If I understand > documentation correctly, holding priorities of splitView’s subviews matter > only when the splitView is being resized (in affecting direction) as a whole, > that is as a consequence or its superview/window being resized. Why would > holding priorities matter when a slider is being dragged by a user? No, you misunderstand. The holding priority is how "strongly" the slider keeps its position, in general. If you put a view into one pane and set its width and height at, say, priority 750, and add constraints to keep its edges all around equal to its superview's, then the user would be unable to drag the divider at all. Suppose the split view allowed the user to drag the divider. What happens when the user lets go? The holding priority is less than the priorities of the view's size constraints, so the view would push or pull the divider and return to its desired size. Since the divider won't stay where the user put it, it's best to not allow the user to drag it. In all probability, the drag is actually implemented by adjusting a constraint whose priority is the holding priority, so it stops as dictated by that priority. Regards, Ken _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
