Re: Auto Layout and Resizable NSViews
> On 21 Jul 2015, at 08:23, Thomas Wetmore wrote: >> >> As a side issue, given that you’ll need to update constraints and re-layout >> your view hierarchy every time the mouse moves during a drag, it might be >> worthwhile retooling your code to use mouseDown/mouseDragged events >> non-modally, instead of using your current modal loop. > > I am worried about the performance implications of this. Should I not be? > Implementation will tell, of course. Test it and see. One point, don’t know if it was already covered as I’ve lost a bit of the thread. Constraints have constants which are amusing named as they’re the one thing you can change. Removing and replacing constraints is expensive and requires lots of recomputation, however just changing the constants on constraints is relatively cheap. So if you do try to do this by setting up and modifying constraints during the drag, see if you can manage to keep the constraint instances the same and just change the constants on them. ___ 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: Auto Layout and Resizable NSViews
> On Jul 20, 2015, at 7:53 PM, Quincey Morris > wrote: > > On Jul 20, 2015, at 16:41 , Thomas Wetmore wrote: >> >> Here is the mouse-down method with event loop. As you can see I am calling >> setFrameOrigin in the dragging case and setting frame directly in the >> resizing case. > > So I think you need to retool your thinking. With auto layout, you no longer > change the size or position of views, but rather change the constraints that > are applied to those view, as Ken Thomases explained in his post. > > As a side issue, given that you’ll need to update constraints and re-layout > your view hierarchy every time the mouse moves during a drag, it might be > worthwhile retooling your code to use mouseDown/mouseDragged events > non-modally, instead of using your current modal loop. I am worried about the performance implications of this. Should I not be? Implementation will tell, of course. I have gone back and forth between the modal approach and the “three-method” approach a couple times. I am now using the modal approach because it resulted in much smoother dragging and resizing. But I have recently upgraded to a new iMac Retina, with much faster processor; I’ll shift back to the three methods when I put in the fix. Tom Wetmore ___ 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: Auto Layout and Resizable NSViews
Clearly Quincey can read minds. He is exactly right about the wrongness of my thinking. I hope he doesn’t read my mind too much longer, or he will get horribly tangled in dusty cob webs of ill-conceived good intentions! Tom Wetmore > On Jul 20, 2015, at 5:15 PM, Quincey Morris > wrote: > > On Jul 20, 2015, at 13:50 , Gary L. Wade wrote: >> >> Depending on your design, why not just use an NSSplitView to do all that for >> you? > > Um, before we go API-hog-wild here, we need to rule out the possibility that > the OP is just Doing It Wrong™. Because I’m 99.% certain that the OP is > just Doing It Wrong™: > >> On Jul 20, 2015, at 13:30 , Thomas Wetmore wrote: >>> >>> I would really like to be able to do resizing using a mouse event loop, but >>> have the layout constraints somehow involved. Reading through references >>> for NSView I don’t see how to do this. I guess I am looking for a way from >>> within the event loop to be able to check whether a proposed new frame >>> rectangle for the view obeys the view’s size constraints. > > So, he’s resizing the view using setFrame**, which is to say he’s not really > using Auto Layout at all. What he apparently wants is *manual* resizing and > repositioning with automatic application of *manual* size limits. This is > functionality that doesn’t exist in Cocoa, and it’s certainly not Auto Layout. > > > ** Probably. There’s still about 0.0001% of doubt about 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
Re: Auto Layout and Resizable NSViews
Ken, Thank you! The lights are coming on. Things can become quite obvious when they become obvious, can’t they? Tom Wetmore > On Jul 20, 2015, at 5:13 PM, Ken Thomases wrote: > >> On Jul 20, 2015, at 3:30 PM, Thomas Wetmore wrote: >> >> I would really like to be able to do resizing using a mouse event loop, but >> have the layout constraints somehow involved. Reading through references for >> NSView I don’t see how to do this. I guess I am looking for a way from >> within the event loop to be able to check whether a proposed new frame >> rectangle for the view obeys the view’s size constraints. > > What you should do when using auto layout is place and size the view using > constraints. Thus moving the view involves modifying the placement > constraints and resizing the view involves modifying the size constraints. > For the size constraints, they should be lower priority than your > minimum-size constraints (if you want to keep those separate). Therefore, no > matter what the drag-tracking code does to those size constraints, your view > still won't go below the minimum size. Of course, a reasonable alternative > is to just use the one set of size constraints and, in your code, disallow > ever setting them below your minimums. You'll have to do something like > that, anyway, to prevent the size constraint constants from going negative, > since that's not allowed. > > You should avoid using any of the -setFrame… methods. I assume that's what > you have been using to place and size the view, but frames set that way get > overridden by the next layout pass. > > 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: Auto Layout and Resizable NSViews
Gary, I am working on an application that supports the old fashioned research process of using 3x5 index cards to hold sources and research notes. I have a hierarchy of NSView sub-classes to represent the cards. At the top of the hierarchy is CardView which simply provides the ability to drag and resize with the option of placing any number of other “controls” (NSBezierPaths) around the border of the card for arbitrary operations. Next layer down in the class hierarchy are “cards" that hold content subviews. For example, there is the OutlineCardView, where the content is an NSOutlineView, used to hold generic information in an outline form. Functionality added at this layer in the hierarchy includes editing the outline with undo and redo and commit, things like that. At the next layer down are cards that represent particular types of information. For example, there is a PersonCardView that represents genealogical data about a person expressed in outline form and displayed in an NSOutlineView. Functionality added at this layer in the hierarchy includes knowledge of life events, relationships between persons, dates, places, and so on. The overall look and feel of this application, as I mentioned to David, is as a large work surface (a near full screen NSWindow) with lots of instances of CardView subclasses that the user can move around, access, put away, search for and bring in, and so forth, while thinking through a research project. I’m not sure how a NSSplitView will particularly solve my resizing problems, but as I implied, I am struggling to learn the best way to get to my goals, and my direction could now be in a dark alley. Tom Wetmore > On Jul 20, 2015, at 4:50 PM, Gary L. Wade > wrote: > > Depending on your design, why not just use an NSSplitView to do all that for > you? > -- > Gary L. Wade (Sent from my iPhone) > http://www.garywade.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: Auto Layout and Resizable NSViews
On Jul 20, 2015, at 16:41 , Thomas Wetmore wrote: > > Here is the mouse-down method with event loop. As you can see I am calling > setFrameOrigin in the dragging case and setting frame directly in the > resizing case. So I think you need to retool your thinking. With auto layout, you no longer change the size or position of views, but rather change the constraints that are applied to those view, as Ken Thomases explained in his post. As a side issue, given that you’ll need to update constraints and re-layout your view hierarchy every time the mouse moves during a drag, it might be worthwhile retooling your code to use mouseDown/mouseDragged events non-modally, instead of using your current modal loop. ___ 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: Auto Layout and Resizable NSViews
> On Jul 20, 2015, at 4:45 PM, David Duncan wrote: > > >> On Jul 20, 2015, at 1:30 PM, Thomas Wetmore wrote: >> >> I really try to figure this stuff out. No kidding. I am trying this simple >> experiment: >> >> I define an NSView that has nothing more than a resize handle, defined as a >> rectangular NSBezierPath in its lower right corner. There are no subviews >> and no superviews involved here. I resize the NSView by implementing a mouse >> event loop in the NSView code. I also drag the NSView within its window >> within the same mouse event loop if the mouse down was not in the resize >> Bezier path. >> >> In the view’s initializer I create two NSLayoutConstraints, to set a minimum >> height and minimum width on the NSView, and add them to the view. I also set >> the NSView’s translatesAutoresizingMaskIntoConstraints property to false, so >> that these are the only two constraints defined on the the view. >> >> This is all done programmatically. There is no NIB for this NSView. For >> reference here is the code that creates and adds the constraints, found >> inside the view’s initializer: >> >> widthConstraint = NSLayoutConstraint(item: self, attribute: >> NSLayoutAttribute.Width, >> relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: nil, >> attribute: NSLayoutAttribute.NotAnAttribute, multiplier: 1.0, constant: >> 100.0) >> heightConstraint = NSLayoutConstraint(item: self, attribute: >> NSLayoutAttribute.Height, >> relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: nil, >> attribute: NSLayoutAttribute.NotAnAttribute, multiplier: 1.0, constant: >> 100.0) >> addConstraint(widthConstraint) >> addConstraint(heightConstraint) > > Nit: instead of using addConstraint(), you can use .active = true on the > constraints themselves and the constraints will find the most appropriate > view to add themselves to. David, Thanks for that tip. I missed that in the docs. I added the constraints directly to the view itself as the view met the definition of “closest ancestor” as found in the docs. >> [Peeve, before I move on. I have to include the names of the two enum types >> (NSLayoutAttribute and NSLayoutRelation) in this code in order for the >> compiler to be happy — why? — I thought the compiler knows what the >> parameter types are so only the enum constants should be needed. End peeve.] >> >> When I instantiate one of these views and place it in an NSWindow, I can >> drag it around and I can resize it, as expected. Notably, however, I can >> resize it down to zero size (and even smaller!), even though the two >> constraints exist. I kind of expected the program to crash when the >> constraints were violated, but things keep on running. I can drag and resize >> the view at will with no repercussions. > > Since you’ve only given height & width constraints, you have an ambiguous > position for this view and no actual relation to the superview. Likely when > you get into this case the view is still respecting the size you gave it, but > since there is no relation to its parent, the parent will simply size smaller > and clip it. Ah. When I add the view to its window, it becomes a sub-view of the window’s content view. Yes, I understand that. However, when I add the view to the window, I have an algorithms that decides where to put it, so I define its location in the window programatically. I didn’t think about the ramifications of that with respect to the constraint system. I am now wondering whether I do have to. (Think of the window as a large working surface, and think of the views as note cards that can be moved around on the surface.) > If you add constraints to match this view to its superview’s > top/leading/bottom/trailing you will likely see the behavior you expect. > >> >> I would really like to be able to do resizing using a mouse event loop, but >> have the layout constraints somehow involved. Reading through references for >> NSView I don’t see how to do this. I guess I am looking for a way from >> within the event loop to be able to check whether a proposed new frame >> rectangle for the view obeys the view’s size constraints. >> >> Anyone have advice of what I should be reading to figure out what to do? All >> the examples I can find seem so simple. Whenever I get into one these, what >> seems to me to be a simple, real world situations (how unusual is a >> resizable view with constraints, after all?), I seem to get lost reading a >> plethora of confusing documents. It’s either me or the documentation, or >> maybe a lack of documentation. I can easily believe it’s me. But that >> doesn’t help me get this experiment to work. >> >> Clearly what I need is a better mental model of how the auto constraint >> system operates at run time. Maybe someone can point me in the direction of >> a good tutorial. >> >> Thanks, >> >> Tom Wetmore >> ___ >> >> Cocoa-dev maili
Re: Auto Layout and Resizable NSViews
Quincey,
Thanks. I’m using Xcode Version 6.4 (6E35b). Mac running 10.10.4. Programming
in Swift 1.2.
Here is the mouse-down method with event loop. As you can see I am calling
setFrameOrigin in the dragging case and setting frame directly in the resizing
case.
override func mouseDown (event: NSEvent) {
var resizing = false
var dragging = false
let clickLocation = convertPoint(event.locationInWindow, fromView: nil)
if resizePath.containsPoint(clickLocation) { resizing = true }
else { dragging = true }
// Remain in an event loop until left mouse up.
let mask = NSEventMask.LeftMouseUpMask |
NSEventMask.LeftMouseDraggedMask
var lastDragLocation = superview!.convertPoint(event.locationInWindow,
fromView: nil)
while resizing || dragging {
let event = window!.nextEventMatchingMask(Int(mask.rawValue))
if event == nil { continue }
if event!.type == NSEventType.LeftMouseUp {
resizing = false
dragging = false
} else if event!.type == NSEventType.LeftMouseDragged {
let dragLocation =
superview!.convertPoint(event!.locationInWindow, fromView: nil)
if dragging {
var origin = frame.origin
origin.x += dragLocation.x - lastDragLocation.x
origin.y += dragLocation.y - lastDragLocation.y
setFrameOrigin(origin)
needsDisplay = true
} else if resizing {
var origin = frame.origin
var size = frame.size
origin.y += dragLocation.y - lastDragLocation.y
size.height -= dragLocation.y - lastDragLocation.y
size.width += dragLocation.x - lastDragLocation.x
frame = CGRect(origin: origin, size: size)
needsLayout = true
needsDisplay = true
}
lastDragLocation = dragLocation
}
}
Tom Wetmore
> On Jul 20, 2015, at 4:43 PM, Quincey Morris
> wrote:
>
> On Jul 20, 2015, at 13:30 , Thomas Wetmore wrote:
>>
>> When I instantiate one of these views and place it in an NSWindow, I can
>> drag it around and I can resize it, as expected. Notably, however, I can
>> resize it down to zero size (and even smaller!), even though the two
>> constraints exist. I kind of expected the program to crash when the
>> constraints were violated, but things keep on running. I can drag and resize
>> the view at will with no repercussions.
>
> a. What version of Xcode are you using?
>
> b. What mechanism are you using (inside the mouse-down event loop) to change
> the size?
>
___
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: Auto Layout and Resizable NSViews
On Jul 20, 2015, at 13:50 , Gary L. Wade wrote: > > Depending on your design, why not just use an NSSplitView to do all that for > you? Um, before we go API-hog-wild here, we need to rule out the possibility that the OP is just Doing It Wrong™. Because I’m 99.% certain that the OP is just Doing It Wrong™: > On Jul 20, 2015, at 13:30 , Thomas Wetmore wrote: >> >> I would really like to be able to do resizing using a mouse event loop, but >> have the layout constraints somehow involved. Reading through references for >> NSView I don’t see how to do this. I guess I am looking for a way from >> within the event loop to be able to check whether a proposed new frame >> rectangle for the view obeys the view’s size constraints. So, he’s resizing the view using setFrame**, which is to say he’s not really using Auto Layout at all. What he apparently wants is *manual* resizing and repositioning with automatic application of *manual* size limits. This is functionality that doesn’t exist in Cocoa, and it’s certainly not Auto Layout. ** Probably. There’s still about 0.0001% of doubt about 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
Re: Auto Layout and Resizable NSViews
> On Jul 20, 2015, at 3:30 PM, Thomas Wetmore wrote: > I define an NSView that has nothing more than a resize handle, defined as a > rectangular NSBezierPath in its lower right corner. There are no subviews and > no superviews involved here. I resize the NSView by implementing a mouse > event loop in the NSView code. I also drag the NSView within its window > within the same mouse event loop if the mouse down was not in the resize > Bezier path. > > In the view’s initializer I create two NSLayoutConstraints, to set a minimum > height and minimum width on the NSView, and add them to the view. I also set > the NSView’s translatesAutoresizingMaskIntoConstraints property to false, so > that these are the only two constraints defined on the the view. > When I instantiate one of these views and place it in an NSWindow, I can drag > it around and I can resize it, as expected. Notably, however, I can resize it > down to zero size (and even smaller!), even though the two constraints exist. > I kind of expected the program to crash when the constraints were violated, > but things keep on running. I can drag and resize the view at will with no > repercussions. > > I would really like to be able to do resizing using a mouse event loop, but > have the layout constraints somehow involved. Reading through references for > NSView I don’t see how to do this. I guess I am looking for a way from within > the event loop to be able to check whether a proposed new frame rectangle for > the view obeys the view’s size constraints. What you should do when using auto layout is place and size the view using constraints. Thus moving the view involves modifying the placement constraints and resizing the view involves modifying the size constraints. For the size constraints, they should be lower priority than your minimum-size constraints (if you want to keep those separate). Therefore, no matter what the drag-tracking code does to those size constraints, your view still won't go below the minimum size. Of course, a reasonable alternative is to just use the one set of size constraints and, in your code, disallow ever setting them below your minimums. You'll have to do something like that, anyway, to prevent the size constraint constants from going negative, since that's not allowed. You should avoid using any of the -setFrame… methods. I assume that's what you have been using to place and size the view, but frames set that way get overridden by the next layout pass. 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: Auto Layout and Resizable NSViews
Or NSSplitViewController, if you can target 10.10+. > On Jul 20, 2015, at 1:50 PM, Gary L. Wade > wrote: > > Depending on your design, why not just use an NSSplitView to do all that for > you? > -- > Gary L. Wade (Sent from my iPhone) > http://www.garywade.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/conrad_shultz%40apple.com > > This email sent to conrad_shu...@apple.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: Auto Layout and Resizable NSViews
Depending on your design, why not just use an NSSplitView to do all that for you? -- Gary L. Wade (Sent from my iPhone) http://www.garywade.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: Auto Layout and Resizable NSViews
> On Jul 20, 2015, at 1:30 PM, Thomas Wetmore wrote: > > I really try to figure this stuff out. No kidding. I am trying this simple > experiment: > > I define an NSView that has nothing more than a resize handle, defined as a > rectangular NSBezierPath in its lower right corner. There are no subviews and > no superviews involved here. I resize the NSView by implementing a mouse > event loop in the NSView code. I also drag the NSView within its window > within the same mouse event loop if the mouse down was not in the resize > Bezier path. > > In the view’s initializer I create two NSLayoutConstraints, to set a minimum > height and minimum width on the NSView, and add them to the view. I also set > the NSView’s translatesAutoresizingMaskIntoConstraints property to false, so > that these are the only two constraints defined on the the view. > > This is all done programmatically. There is no NIB for this NSView. For > reference here is the code that creates and adds the constraints, found > inside the view’s initializer: > > widthConstraint = NSLayoutConstraint(item: self, attribute: > NSLayoutAttribute.Width, > relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: nil, > attribute: NSLayoutAttribute.NotAnAttribute, multiplier: 1.0, constant: > 100.0) > heightConstraint = NSLayoutConstraint(item: self, attribute: > NSLayoutAttribute.Height, > relatedBy: NSLayoutRelation.GreaterThanOrEqual, toItem: nil, > attribute: NSLayoutAttribute.NotAnAttribute, multiplier: 1.0, constant: > 100.0) > addConstraint(widthConstraint) > addConstraint(heightConstraint) Nit: instead of using addConstraint(), you can use .active = true on the constraints themselves and the constraints will find the most appropriate view to add themselves to. > > [Peeve, before I move on. I have to include the names of the two enum types > (NSLayoutAttribute and NSLayoutRelation) in this code in order for the > compiler to be happy — why? — I thought the compiler knows what the parameter > types are so only the enum constants should be needed. End peeve.] > > When I instantiate one of these views and place it in an NSWindow, I can drag > it around and I can resize it, as expected. Notably, however, I can resize it > down to zero size (and even smaller!), even though the two constraints exist. > I kind of expected the program to crash when the constraints were violated, > but things keep on running. I can drag and resize the view at will with no > repercussions. Since you’ve only given height & width constraints, you have an ambiguous position for this view and no actual relation to the superview. Likely when you get into this case the view is still respecting the size you gave it, but since there is no relation to its parent, the parent will simply size smaller and clip it. If you add constraints to match this view to its superview’s top/leading/bottom/trailing you will likely see the behavior you expect. > > I would really like to be able to do resizing using a mouse event loop, but > have the layout constraints somehow involved. Reading through references for > NSView I don’t see how to do this. I guess I am looking for a way from within > the event loop to be able to check whether a proposed new frame rectangle for > the view obeys the view’s size constraints. > > Anyone have advice of what I should be reading to figure out what to do? All > the examples I can find seem so simple. Whenever I get into one these, what > seems to me to be a simple, real world situations (how unusual is a resizable > view with constraints, after all?), I seem to get lost reading a plethora of > confusing documents. It’s either me or the documentation, or maybe a lack of > documentation. I can easily believe it’s me. But that doesn’t help me get > this experiment to work. > > Clearly what I need is a better mental model of how the auto constraint > system operates at run time. Maybe someone can point me in the direction of a > good tutorial. > > Thanks, > > Tom Wetmore > ___ > > 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/david.duncan%40apple.com > > This email sent to david.dun...@apple.com -- David Duncan ___ 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: Auto Layout and Resizable NSViews
On Jul 20, 2015, at 13:30 , Thomas Wetmore wrote: > > When I instantiate one of these views and place it in an NSWindow, I can drag > it around and I can resize it, as expected. Notably, however, I can resize it > down to zero size (and even smaller!), even though the two constraints exist. > I kind of expected the program to crash when the constraints were violated, > but things keep on running. I can drag and resize the view at will with no > repercussions. a. What version of Xcode are you using? b. What mechanism are you using (inside the mouse-down event loop) to change the size? ___ 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
