Re: Autolayout warnings

[Gary L. Wade]

In case it helps with your future animatable design, my particular app has a 
layout kind of like this:

——
| | (8 points separation)Title (could be long)
| | (8 points separation)Subtitle (could be long)
—— 

and I used something like this in viewDidLoad to preserve the values before I 
had any data:

-(void)viewDidLoad
{
self.iconIndicatorWidthOriginalConstant =
self.iconIndicatorWidth.constant;
self.iconTitleLabelLeadingOriginalConstant =
self.iconTitleLabelLeading.constant;
self.iconSubtitleLabelLeadingOriginalConstant =
self.iconSubtitleLabelLeading.constant;

self.iconIndicatorWidth.constant = 0;
}

and I used something like this when I knew whether or not I wanted to show the 
icon indicator (the box to the left of the title and subtitle):

-(void)updateUI:(BOOL )showIconIndicator
{
CGFloat newIconIndicatorWidthConstant;
CGFloat newIconTitleLabelLeadingConstant;
CGFloat newIconSubtitleLabelLeadingConstant;

if (showIconIndicator)
{
newIconIndicatorWidthConstant =
self.iconIndicatorWidthOriginalConstant;
newIconTitleLabelLeadingConstant =
self.iconTitleLabelLeadingOriginalConstant +
self.iconIndicatorWidthOriginalConstant + 8;
newIconSubtitleLabelLeadingConstant =
self.iconSubtitleLabelLeadingOriginalConstant +
self.iconIndicatorWidthOriginalConstant + 8;
}
else
{
newIconIndicatorWidthConstant = 0;
newIconTitleLabelLeadingConstant =
self.iconTitleLabelLeadingOriginalConstant;
newIconSubtitleLabelLeadingConstant =
self.iconSubtitleLabelLeadingOriginalConstant;
}

if (newIconIndicatorWidthConstant != self.iconIndicatorWidth.constant)
{
[self.iconIndicator.superview layoutIfNeeded];
[UIView animateWithDuration:0.3 animations:
^{
self.iconIndicatorWidth.constant =
newIconIndicatorWidthConstant;
self.iconTitleLabelLeading.constant =
newIconTitleLabelLeadingConstant;
self.iconSubtitleLabelLeading.constant =
newIconSubtitleLabelLeadingConstant;

[self.iconIndicator.superview layoutIfNeeded];
}];
}
}

--
Gary L. Wade
http://www.garywade.com/ 
> On Dec 14, 2016, at 3:39 PM, Doug Hill  wrote:
> 
> Great, more good stuff to know!
> 
> However, trying this out I see that some views animate and others don't (just 
> jump into place). I guess I'll look into a more animatable design.
> 
> Doug Hill
> 
>> On Dec 14, 2016, at 3:24 PM, Ken Thomases  wrote:
>> 
>> On Dec 14, 2016, at 5:15 PM, Doug Hill  wrote:
>>> 
>>> Ok, this is more good information to keep in mind when designing autolayout 
>>> constraints. Given that my design isn't animatable, it's back to the 
>>> autolayout drawing board. Again.
>> 
>> I think it works to animate a change of constraints if you do the 
>> -layoutIfNeeded on the window within the animation context.  It's 
>> technically animating the frame changes rather than the constraints, which 
>> can transition through some different states and even temporarily violate 
>> constraints, but for this case it should work.
>> 
>> Regards,
>> Ken
>> 
> 

___

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

Re: Autolayout warnings

[Doug Hill]

Great, more good stuff to know!

However, trying this out I see that some views animate and others don't (just 
jump into place). I guess I'll look into a more animatable design.

Doug Hill

> On Dec 14, 2016, at 3:24 PM, Ken Thomases  wrote:
> 
> On Dec 14, 2016, at 5:15 PM, Doug Hill  wrote:
>> 
>> Ok, this is more good information to keep in mind when designing autolayout 
>> constraints. Given that my design isn't animatable, it's back to the 
>> autolayout drawing board. Again.
> 
> I think it works to animate a change of constraints if you do the 
> -layoutIfNeeded on the window within the animation context.  It's technically 
> animating the frame changes rather than the constraints, which can transition 
> through some different states and even temporarily violate constraints, but 
> for this case it should work.
> 
> Regards,
> Ken
> 


___

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

Re: Autolayout warnings

[Ken Thomases]

On Dec 14, 2016, at 5:15 PM, Doug Hill  wrote:
> 
> Ok, this is more good information to keep in mind when designing autolayout 
> constraints. Given that my design isn't animatable, it's back to the 
> autolayout drawing board. Again.

I think it works to animate a change of constraints if you do the 
-layoutIfNeeded on the window within the animation context.  It's technically 
animating the frame changes rather than the constraints, which can transition 
through some different states and even temporarily violate constraints, but for 
this case it should work.

Regards,
Ken


___

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

Re: Autolayout warnings

[Doug Hill]

Ok, this is more good information to keep in mind when designing autolayout 
constraints. Given that my design isn't animatable, it's back to the autolayout 
drawing board. Again.

Doug Hill


> On Dec 14, 2016, at 3:07 PM, Gary L. Wade  
> wrote:
> 
> Right, activate and deactivate are not animatable, but the constant values in 
> constraints are.
> 
> True, it depends on what you’re showing as to whether to shrink or move your 
> view.  When I wanted to use a search bar in UISearchController with a 
> collection view in iOS to appear similarly as UITableView, I moved the search 
> bar:
> 
> https://whatweretheythinkingblog.wordpress.com/2016/11/19/effectively-using-uisearchcontroller-with-uicollectionview/
>  
> 
> 
> When I wanted to show an icon to the left of a title, where the item may not 
> have an icon but was only available through a REST call, I found it more 
> attractive to grow the icon and compress the title in that animation, 
> choosing a scale-to-fill option, when I determined there was an icon.
> --
> Gary L. Wade
> http://www.garywade.com/ 
>> On Dec 14, 2016, at 2:52 PM, Doug Hill > > wrote:
>> 
>> Gary,
>> 
>> Thanks for the reply.
>> I tried moving the container rather than resizing to 0 because there's a 
>> table inside this view and it will relayout when resizing. For an animation, 
>> I guess it depends on what effect you want: either seeing the view move or 
>> resize to 0.
>> 
>> Oddly, when I put my code to activate/deactivate constraints inside a 
>> [UIView animateWithDuration…] I get no animation. :(
>> 
>> Doug Hill
>> 
>>> On Dec 14, 2016, at 2:49 PM, Gary L. Wade >> > wrote:
>>> 
>>> If I understand you correctly, you might prefer the approach I chose to do. 
>>>  Rather than activating and deactivating constraints (BTW, you should 
>>> always deactivate before having multiple actives), set your constraints up 
>>> to always be active but change the width for the one you’re hiding to 0 and 
>>> the other to be the extra size needed to fill the gap.  I also chose to 
>>> animate the constant values, so the size-change is smooth to the user.
>>> --
>>> Gary L. Wade
>>> http://www.garywade.com/ 
 On Dec 14, 2016, at 2:19 PM, Doug Hill > wrote:
 
 I'm seeing warnings in the console when I dynamically make autolayout 
 constraints active/inactive at runtime.
 
 I have two constraints that align a container view leading or trailing 
 edge with another view's edge. This is to move the container onscreen or 
 offscreen. I have another view whose trailing edge aligns with the leading 
 edge of the first container view so it moves with it as autolayout 
 constraints change.
 
 At runtime, I make one of these constraints active and the other inactive, 
 like so:
 
 - (IBAction)toggleCommentsVisibility:(id)sender
 {
self.commentsAreHidden ? [self showComments:self] : [self 
 hideComments:self]; 
 }
 
 - (IBAction)showComments:(id)sender
 {
self.showCommentsConstraint.active = YES;
self.hideCommentsContainerConstraint.active = NO;
 
self.commentsAreHidden = NO;
 }
 
 - (IBAction)hideComments:(id)sender
 {
self.showCommentsConstraint.active = NO;
self.hideCommentsContainerConstraint.active = YES;
 
self.commentsAreHidden = YES;
 }
 
 When I call showComments, I get the following warning in the console:
 
 =
 
 Unable to simultaneously satisfy constraints.
 Probably at least one of the constraints in the following list is one you 
 don't want. 
 Try this: 
(1) look at each constraint and try to figure out which you don't 
 expect; 
(2) find the code that added the unwanted constraint or constraints and 
 fix it. 
 (
">>> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
">>> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
">>> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
">>> H:[UIView:0x7f91426def30(768)]>"
 )
 
 Will attempt to recover by breaking constraint 
 >>> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
 
 Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to 
 catch this in the debugger.
 
 =
 
 This is puzzling because IB doesn't give me any autolayout errors/warning 
 when I manually activate/deactivate these constraints. Also, I don't get 
 this runtime warning when calling hideComments, only the 'show' case. 

Re: Autolayout warnings

[Gary L. Wade]

Right, activate and deactivate are not animatable, but the constant values in 
constraints are.

True, it depends on what you’re showing as to whether to shrink or move your 
view.  When I wanted to use a search bar in UISearchController with a 
collection view in iOS to appear similarly as UITableView, I moved the search 
bar:

https://whatweretheythinkingblog.wordpress.com/2016/11/19/effectively-using-uisearchcontroller-with-uicollectionview/

When I wanted to show an icon to the left of a title, where the item may not 
have an icon but was only available through a REST call, I found it more 
attractive to grow the icon and compress the title in that animation, choosing 
a scale-to-fill option, when I determined there was an icon.
--
Gary L. Wade
http://www.garywade.com/ 
> On Dec 14, 2016, at 2:52 PM, Doug Hill  wrote:
> 
> Gary,
> 
> Thanks for the reply.
> I tried moving the container rather than resizing to 0 because there's a 
> table inside this view and it will relayout when resizing. For an animation, 
> I guess it depends on what effect you want: either seeing the view move or 
> resize to 0.
> 
> Oddly, when I put my code to activate/deactivate constraints inside a [UIView 
> animateWithDuration…] I get no animation. :(
> 
> Doug Hill
> 
>> On Dec 14, 2016, at 2:49 PM, Gary L. Wade > > wrote:
>> 
>> If I understand you correctly, you might prefer the approach I chose to do.  
>> Rather than activating and deactivating constraints (BTW, you should always 
>> deactivate before having multiple actives), set your constraints up to 
>> always be active but change the width for the one you’re hiding to 0 and the 
>> other to be the extra size needed to fill the gap.  I also chose to animate 
>> the constant values, so the size-change is smooth to the user.
>> --
>> Gary L. Wade
>> http://www.garywade.com/ 
>>> On Dec 14, 2016, at 2:19 PM, Doug Hill >> > wrote:
>>> 
>>> I'm seeing warnings in the console when I dynamically make autolayout 
>>> constraints active/inactive at runtime.
>>> 
>>> I have two constraints that align a container view leading or trailing edge 
>>> with another view's edge. This is to move the container onscreen or 
>>> offscreen. I have another view whose trailing edge aligns with the leading 
>>> edge of the first container view so it moves with it as autolayout 
>>> constraints change.
>>> 
>>> At runtime, I make one of these constraints active and the other inactive, 
>>> like so:
>>> 
>>> - (IBAction)toggleCommentsVisibility:(id)sender
>>> {
>>> self.commentsAreHidden ? [self showComments:self] : [self 
>>> hideComments:self]; 
>>> }
>>> 
>>> - (IBAction)showComments:(id)sender
>>> {
>>> self.showCommentsConstraint.active = YES;
>>> self.hideCommentsContainerConstraint.active = NO;
>>> 
>>> self.commentsAreHidden = NO;
>>> }
>>> 
>>> - (IBAction)hideComments:(id)sender
>>> {
>>> self.showCommentsConstraint.active = NO;
>>> self.hideCommentsContainerConstraint.active = YES;
>>> 
>>> self.commentsAreHidden = YES;
>>> }
>>> 
>>> When I call showComments, I get the following warning in the console:
>>> 
>>> =
>>> 
>>> Unable to simultaneously satisfy constraints.
>>> Probably at least one of the constraints in the following list is one you 
>>> don't want. 
>>> Try this: 
>>> (1) look at each constraint and try to figure out which you don't 
>>> expect; 
>>> (2) find the code that added the unwanted constraint or constraints and 
>>> fix it. 
>>> (
>>>">> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>>">> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>>">> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>>">> H:[UIView:0x7f91426def30(768)]>"
>>> )
>>> 
>>> Will attempt to recover by breaking constraint 
>>> >> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
>>> 
>>> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to 
>>> catch this in the debugger.
>>> 
>>> =
>>> 
>>> This is puzzling because IB doesn't give me any autolayout errors/warning 
>>> when I manually activate/deactivate these constraints. Also, I don't get 
>>> this runtime warning when calling hideComments, only the 'show' case. 
>>> Finally, things actually work at runtime because it's nice enough to 
>>> "break" the constraint that I deactivated in code. But I would like to not 
>>> have these warnings.
>>> 
>>> Any ideas on what's going on how I might go about debugging this?
>>> 
>>> Doug Hill
>>> ___
>>> 
>>> 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 

Re: Autolayout warnings

[Doug Hill]

Gary,

Thanks for the reply.
I tried moving the container rather than resizing to 0 because there's a table 
inside this view and it will relayout when resizing. For an animation, I guess 
it depends on what effect you want: either seeing the view move or resize to 0.

Oddly, when I put my code to activate/deactivate constraints inside a [UIView 
animateWithDuration…] I get no animation. :(

Doug Hill

> On Dec 14, 2016, at 2:49 PM, Gary L. Wade  
> wrote:
> 
> If I understand you correctly, you might prefer the approach I chose to do.  
> Rather than activating and deactivating constraints (BTW, you should always 
> deactivate before having multiple actives), set your constraints up to always 
> be active but change the width for the one you’re hiding to 0 and the other 
> to be the extra size needed to fill the gap.  I also chose to animate the 
> constant values, so the size-change is smooth to the user.
> --
> Gary L. Wade
> http://www.garywade.com/ 
>> On Dec 14, 2016, at 2:19 PM, Doug Hill > > wrote:
>> 
>> I'm seeing warnings in the console when I dynamically make autolayout 
>> constraints active/inactive at runtime.
>> 
>> I have two constraints that align a container view leading or trailing edge 
>> with another view's edge. This is to move the container onscreen or 
>> offscreen. I have another view whose trailing edge aligns with the leading 
>> edge of the first container view so it moves with it as autolayout 
>> constraints change.
>> 
>> At runtime, I make one of these constraints active and the other inactive, 
>> like so:
>> 
>> - (IBAction)toggleCommentsVisibility:(id)sender
>> {
>>  self.commentsAreHidden ? [self showComments:self] : [self 
>> hideComments:self]; 
>> }
>> 
>> - (IBAction)showComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = YES;
>>  self.hideCommentsContainerConstraint.active = NO;
>> 
>>  self.commentsAreHidden = NO;
>> }
>> 
>> - (IBAction)hideComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = NO;
>>  self.hideCommentsContainerConstraint.active = YES;
>> 
>>  self.commentsAreHidden = YES;
>> }
>> 
>> When I call showComments, I get the following warning in the console:
>> 
>> =
>> 
>> Unable to simultaneously satisfy constraints.
>> Probably at least one of the constraints in the following list is one you 
>> don't want. 
>> Try this: 
>>  (1) look at each constraint and try to figure out which you don't 
>> expect; 
>>  (2) find the code that added the unwanted constraint or constraints and 
>> fix it. 
>> (
>>"> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>"> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>"> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>"> H:[UIView:0x7f91426def30(768)]>"
>> )
>> 
>> Will attempt to recover by breaking constraint 
>> > H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
>> 
>> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to 
>> catch this in the debugger.
>> 
>> =
>> 
>> This is puzzling because IB doesn't give me any autolayout errors/warning 
>> when I manually activate/deactivate these constraints. Also, I don't get 
>> this runtime warning when calling hideComments, only the 'show' case. 
>> Finally, things actually work at runtime because it's nice enough to "break" 
>> the constraint that I deactivated in code. But I would like to not have 
>> these warnings.
>> 
>> Any ideas on what's going on how I might go about debugging this?
>> 
>> Doug Hill
>> ___
>> 
>> 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/garywade%40desisoftsystems.com
>>  
>> 
>> 
>> This email sent to garyw...@desisoftsystems.com
> 

___

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

Re: Autolayout warnings

[Doug Hill]

> On Dec 14, 2016, at 2:46 PM, Ken Thomases  wrote:
> 
> On Dec 14, 2016, at 4:19 PM, Doug Hill  wrote:
>> 
>> I'm seeing warnings in the console when I dynamically make autolayout 
>> constraints active/inactive at runtime.
>> 
>> I have two constraints that align a container view leading or trailing edge 
>> with another view's edge. This is to move the container onscreen or 
>> offscreen. I have another view whose trailing edge aligns with the leading 
>> edge of the first container view so it moves with it as autolayout 
>> constraints change.
>> 
>> At runtime, I make one of these constraints active and the other inactive, 
>> like so:
> 
>> - (IBAction)showComments:(id)sender
>> {
>>  self.showCommentsConstraint.active = YES;
>>  self.hideCommentsContainerConstraint.active = NO;
> 
> Swap the order of these.  Always disable no-longer-applicable constraints 
> before enabling newly-applicable constraints.  The way you have it here, 
> after the first line, you temporarily have constraints which conflict 
> enabled.  You fix that with the next line, but you've already gotten the 
> warning by then.

Ding-Ding-Ding-Ding-Ding-Ding! We have a winner!

I went ahead and made this change and warnings are gone. Will keep the order of 
activation in mind for future coding.

Doug Hill
___

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

Re: Autolayout warnings

[Gary L. Wade]

If I understand you correctly, you might prefer the approach I chose to do.  
Rather than activating and deactivating constraints (BTW, you should always 
deactivate before having multiple actives), set your constraints up to always 
be active but change the width for the one you’re hiding to 0 and the other to 
be the extra size needed to fill the gap.  I also chose to animate the constant 
values, so the size-change is smooth to the user.
--
Gary L. Wade
http://www.garywade.com/ 
> On Dec 14, 2016, at 2:19 PM, Doug Hill  wrote:
> 
> I'm seeing warnings in the console when I dynamically make autolayout 
> constraints active/inactive at runtime.
> 
> I have two constraints that align a container view leading or trailing edge 
> with another view's edge. This is to move the container onscreen or 
> offscreen. I have another view whose trailing edge aligns with the leading 
> edge of the first container view so it moves with it as autolayout 
> constraints change.
> 
> At runtime, I make one of these constraints active and the other inactive, 
> like so:
> 
> - (IBAction)toggleCommentsVisibility:(id)sender
> {
>   self.commentsAreHidden ? [self showComments:self] : [self 
> hideComments:self]; 
> }
> 
> - (IBAction)showComments:(id)sender
> {
>   self.showCommentsConstraint.active = YES;
>   self.hideCommentsContainerConstraint.active = NO;
> 
>   self.commentsAreHidden = NO;
> }
> 
> - (IBAction)hideComments:(id)sender
> {
>   self.showCommentsConstraint.active = NO;
>   self.hideCommentsContainerConstraint.active = YES;
> 
>   self.commentsAreHidden = YES;
> }
> 
> When I call showComments, I get the following warning in the console:
> 
> =
> 
> Unable to simultaneously satisfy constraints.
> Probably at least one of the constraints in the following list is one you 
> don't want. 
> Try this: 
>   (1) look at each constraint and try to figure out which you don't 
> expect; 
>   (2) find the code that added the unwanted constraint or constraints and 
> fix it. 
> (
>" UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>" H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>" UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>" H:[UIView:0x7f91426def30(768)]>"
> )
> 
> Will attempt to recover by breaking constraint 
>  H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>
> 
> Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch 
> this in the debugger.
> 
> =
> 
> This is puzzling because IB doesn't give me any autolayout errors/warning 
> when I manually activate/deactivate these constraints. Also, I don't get this 
> runtime warning when calling hideComments, only the 'show' case. Finally, 
> things actually work at runtime because it's nice enough to "break" the 
> constraint that I deactivated in code. But I would like to not have these 
> warnings.
> 
> Any ideas on what's going on how I might go about debugging this?
> 
> Doug Hill
> ___
> 
> 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/garywade%40desisoftsystems.com
> 
> This email sent to garyw...@desisoftsystems.com

___

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

Re: Autolayout warnings

[Doug Hill]

Quincey,

Thanks for the reply.

> On Dec 14, 2016, at 2:40 PM, Quincey Morris 
>  wrote:
> 
> On Dec 14, 2016, at 14:19 , Doug Hill  > wrote:
>> 
>>"> UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>>"> H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>>"> UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>>"> H:[UIView:0x7f91426def30(768)]>"
> 
> It kinda looks like the conflict is between the first and last of these. When 
> you move the comments view off to the trailing edge of what it’s aligned to, 
> you seem to be making the enclosing view wider according to some combination 
> of constraints, which violates the constraint (the last one) saying that the 
> enclosing view is 768 pts wide.

The funky  UIView-Encapsulated-Layout-Width constraint is not mine and I don't 
set it to 768. Not sure what it is.

> Can you set the comment view to 0 width when you hide it? That would probably 
> eliminate the problem, although a different approach might be preferable. 
> (For example, use conditional constraints on the view that expands to fill 
> the space occupied by the comment view, relative to the enclosing view, and 
> hide the comment view instead of moving it.)

I actually put a lot of time into trying to figure out how to architect the 
autolayout constraints to make everything move together using. This scheme 
seems good because, by not shrinking the container (which has a table view 
inside), it doesn't cause the table to relayout. But I'll try some of your 
techniques too.

Doug Hill
___

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

Re: Autolayout warnings

[Ken Thomases]

On Dec 14, 2016, at 4:19 PM, Doug Hill  wrote:
> 
> I'm seeing warnings in the console when I dynamically make autolayout 
> constraints active/inactive at runtime.
> 
> I have two constraints that align a container view leading or trailing edge 
> with another view's edge. This is to move the container onscreen or 
> offscreen. I have another view whose trailing edge aligns with the leading 
> edge of the first container view so it moves with it as autolayout 
> constraints change.
> 
> At runtime, I make one of these constraints active and the other inactive, 
> like so:

> - (IBAction)showComments:(id)sender
> {
>   self.showCommentsConstraint.active = YES;
>   self.hideCommentsContainerConstraint.active = NO;

Swap the order of these.  Always disable no-longer-applicable constraints 
before enabling newly-applicable constraints.  The way you have it here, after 
the first line, you temporarily have constraints which conflict enabled.  You 
fix that with the next line, but you've already gotten the warning by then.

> 
>   self.commentsAreHidden = NO;
> }

Regards,
Ken


___

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

Re: Autolayout warnings

[Quincey Morris]

On Dec 14, 2016, at 14:19 , Doug Hill  wrote:
> 
>" UIView:0x7f91426d9db0.width == 0.33*UIView:0x7f91426def30.width>",
>" H:[UIView:0x7f91426d7f00]-(0)-[UIView:0x7f91426d9db0]>",
>" UIView:0x7f91426d9db0.trailing == UIView:0x7f91426d7f00.trailing>",
>" H:[UIView:0x7f91426def30(768)]>"

It kinda looks like the conflict is between the first and last of these. When 
you move the comments view off to the trailing edge of what it’s aligned to, 
you seem to be making the enclosing view wider according to some combination of 
constraints, which violates the constraint (the last one) saying that the 
enclosing view is 768 pts wide.

Can you set the comment view to 0 width when you hide it? That would probably 
eliminate the problem, although a different approach might be preferable. (For 
example, use conditional constraints on the view that expands to fill the space 
occupied by the comment view, relative to the enclosing view, and hide the 
comment view instead of moving it.)
___

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

Autolayout warnings

[Doug Hill]

I'm seeing warnings in the console when I dynamically make autolayout 
constraints active/inactive at runtime.

I have two constraints that align a container view leading or trailing edge 
with another view's edge. This is to move the container onscreen or offscreen. 
I have another view whose trailing edge aligns with the leading edge of the 
first container view so it moves with it as autolayout constraints change.

At runtime, I make one of these constraints active and the other inactive, like 
so:

- (IBAction)toggleCommentsVisibility:(id)sender
{
self.commentsAreHidden ? [self showComments:self] : [self 
hideComments:self]; 
}

- (IBAction)showComments:(id)sender
{
self.showCommentsConstraint.active = YES;
self.hideCommentsContainerConstraint.active = NO;

self.commentsAreHidden = NO;
}

- (IBAction)hideComments:(id)sender
{
self.showCommentsConstraint.active = NO;
self.hideCommentsContainerConstraint.active = YES;

self.commentsAreHidden = YES;
}

When I call showComments, I get the following warning in the console:

=

Unable to simultaneously satisfy constraints.
Probably at least one of the constraints in the following list is one you don't 
want. 
Try this: 
(1) look at each constraint and try to figure out which you don't 
expect; 
(2) find the code that added the unwanted constraint or constraints and 
fix it. 
(
"",
"",
"",
""
)

Will attempt to recover by breaking constraint 


Make a symbolic breakpoint at UIViewAlertForUnsatisfiableConstraints to catch 
this in the debugger.

=

This is puzzling because IB doesn't give me any autolayout errors/warning when 
I manually activate/deactivate these constraints. Also, I don't get this 
runtime warning when calling hideComments, only the 'show' case. Finally, 
things actually work at runtime because it's nice enough to "break" the 
constraint that I deactivated in code. But I would like to not have these 
warnings.

Any ideas on what's going on how I might go about debugging this?

Doug Hill
___

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