Re: Who owns a child view controller?

> On 13 Jul 2017, at 01:32, Jens Alfke wrote: > >> On Jul 12, 2017, at 2:57 PM, Jeremy Hughes >> wrote: >> >> I’m trying to understand memory management so I can avoid retain cycles and >> other issues. > > That’s fine. But using a weak reference to try to detect when an object gets > deall

Re: Who owns a child view controller?

> On 13 Jul 2017, at 10:57, Jeremy Hughes wrote: > > Apple’s Swift book says: > > "The examples above show how to use safe unowned references. Swift also > provides unsafe unowned references for cases where you need to disable > runtime safety checks—for example, for performance reasons. As wi

Re: Who owns a child view controller?

> On 13 Jul 2017, at 11:26, Jeremy Hughes wrote: > > So perhaps the difference between safe and unsafe unowned is that safe > unowned generates a runtime error (but doesn’t crash) while unsafe unowned > crashes? Or perhaps they both crash, but unowned(unsafe) gives a more helpful > error messa

Question about structs and enum placement in a project

I am planning on putting all my structs and enums into it's own swift file - to keep my project cleaner. Seems safe enough, thoughts on this? Thanks, Eric ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moder

Re: Who owns a child view controller?

> On Jul 12, 2017, at 6:30 PM, Quincey Morris > wrote: > > On Jul 12, 2017, at 16:19 , Greg Parker > wrote: >> >> "Unowned" means something else in Swift. > > I suppose. I guess I’ve internalized “unowned” to mean “unretained but > crashes tidily” in Swift, but “unr

Re: Question about structs and enum placement in a project

For a project of any appreciable size, that’s gonna be one huge file… Charles > On Jul 13, 2017, at 8:37 AM, Eric E. Dolecki wrote: > > I am planning on putting all my structs and enums into it's own swift file > - to keep my project cleaner. Seems safe enough, thoughts on this? > > Thanks, >

Re: Question about structs and enum placement in a project

Perhaps. Then maybe a folder of categorized structs and enums? I personally dislike seeing them sprinkled throughout AppDelegate & other classes. It's easy to cntrl-click to where they are defined, but it seems like a lot of clutter. On Thu, Jul 13, 2017 at 9:52 AM Charles Srstka wrote: > For a

Re: Question about structs and enum placement in a project

Folders are good. I’d avoid glomming too many types into one file, because you’ll spend a lot of time scrolling through that file looking for things. Better to break things into smaller files where possible. Charles > On Jul 13, 2017, at 8:53 AM, Eric E. Dolecki wrote: > > Perhaps. Then maybe

Re: Question about structs and enum placement in a project

If they’re not being declared inside another object, why not put them in their own files? > Am 13.07.2017 um 15:53 schrieb Eric E. Dolecki : > > Perhaps. Then maybe a folder of categorized structs and enums? I personally > dislike seeing them sprinkled throughout AppDelegate & other classes. It

Re: Question about structs and enum placement in a project

I've broken out a folder "Structs and Enums" with sub-folders based on related areas of operation. I'm currently prototyping so I don't have tons and tons of operation types. Seems good enough, adds organization, and it keeps my classes much cleaner. I will probably end up with less than a dozen of

NSAccessibility

I have a program which uses the Scintilla text editor. When it's run on an OS 10.8, it gets a crash due to an unrecognized selector for setAccessibilityElement (part of log shown at the bottom). The interface for the view that causes the problem is: @interface SCIContentView : NSView < NSTex

Re: Who owns a child view controller?

On Jul 13, 2017, at 02:57 , Jeremy Hughes wrote: > > When to use unowned rather than weak Here’s how I understand the situation in Swift. As usual, I may have some things a bit wrong, but I think this is right. There are four kinds of reference variable (or stored property) in Swift: 1. Stron

Re: NSAccessibility

On Jul 13, 2017, at 10:17 , Tom Doan wrote: > > it looks like NSAccessibilityStaticText was added with 10.10. > > My problem is that setAccessibilityElement is never called explicitly by > SCIContentView That seems to make it a bug in Scintilla. Does it actually support macOS prior to 10.10?

Re: Who owns a child view controller?

One thing that I had to learn was to break my expectations of when a view controller (one that is tied to a navigationController) is deallocated. My expectations initially were “oh, we’re closing it and going to another screen, it will just be deallocated.” Weee, no. It’s part of a stack