Re: Custom window disappears dragging to second display

On May 2, 2016, at 9:26 PM, Trygve Inda wrote: > > I have a custom window that basically eliminates the large title area. > > When you drag a normal window to a second screen, as the drag is in > progress, the window appears semi-transparent on the second screen until

Re: Custom window disappears dragging to second display

Are you talking within Xcode? This always crashes Xcode for me. Simply dragging one window that has shrunken down from the 15” MBP display onto the Thunderbolt. BLAM. No more Xcode. On May 2, 2016, at 10:26 PM, Trygve Inda wrote: > I have a custom window that

Custom window disappears dragging to second display

I have a custom window that basically eliminates the large title area. When you drag a normal window to a second screen, as the drag is in progress, the window appears semi-transparent on the second screen until enough of the window covers the second screen, whereupon it becomes opaque on the

Presenting view controller over another changes its size

I have a modal view controller presented with custom transition and style. It works fine. But if I present another view controller on top of that, and then dismiss that second view controller, the first one is briefly the full size of the screen, and then snaps back to the desired size. Any

Re: undomanger performance

> On 3 May 2016, at 6:10 AM, Martin Wierschin wrote: > >> My app deals with an object tree that can have millions of leaves. It is >> possible to run an operation on all of them. Each will register its own >> change with the undo manager. > > Is it absolutely necessary for

Re: Core Data user-defined fields

In a similar situation, I defined one Property to represent both your Required (A, B, C) and User-defined properties, and wrote some business logic to ensure that the Required properties were always present. A variation would be that this user-interfacing Property is a dependent property,

Core Data user-defined fields

I have a core data document-based app at the document level is a Core Data type called Library, with a one to many relationship to type Element. Element has a few properties but I want to allow the user to add others (of type string only at this point). So I have Element: String name String

Re: undomanger performance

> My app deals with an object tree that can have millions of leaves. It is > possible to run an operation on all of them. Each will register its own > change with the undo manager. Is it absolutely necessary for each leaf object to register its own undo invocation? I don’t know if that’s the

Re: Converting to ARC and blocks

> On May 2, 2016, at 11:30 AM, Steve Mills wrote: > > On May 02, 2016, at 12:58 PM, John McCall wrote: > > > You don't have to declare something with __block just to use it in a block. > > __block specifically means that the variable will be captured *by

Re: Converting to ARC and blocks

On May 02, 2016, at 12:58 PM, John McCall wrote: You don't have to declare something with __block just to use it in a block. __block specifically means that the variable will be captured *by reference* in the block, meaning that changes to the variable within the block are

Re: Converting to ARC and blocks

> On May 2, 2016, at 10:38 AM, Steve Mills wrote: > I'm working on a project that's had to support older hardware/software until > now, so we can *finally* convert to ARC. Since it's been almost a year since > I've worked on anything that used ARC, I'm a little rusty on some of

Re: Converting to ARC and blocks

On May 02, 2016, at 12:45 PM, Steve Mills wrote: I'm working on a project that's had to support older hardware/software until now, so we can *finally* convert to ARC. Since it's been almost a year since I've worked on anything that used ARC, I'm a little rusty on some of the

Converting to ARC and blocks

I'm working on a project that's had to support older hardware/software until now, so we can *finally* convert to ARC. Since it's been almost a year since I've worked on anything that used ARC, I'm a little rusty on some of the stranger stuff, like __unsafe_retained. Here's a pared down hunk