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
> enough of the window cove
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 basically eliminates the lar
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 seco
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 id
> 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 each leaf object t
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, conne
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 prop
> 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 a
> 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
> > reference* in the block, meaning t
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 visible in
the orig
> 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 the
> stranger s
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
stranger stuff, l
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 bef
13 matches
Mail list logo