Re: Weird NSPredicate structure when using "first" in keypath

> On Jan 9, 2017, at 6:38 PM, Aaron Tuller wrote: > > Try doing > name.#first > as FIRST and LAST are reserved words and need escaping: Thanks for the answer. Unfortunately this is a library that will allow developers to provide their own predicate strings, and I can

Re: Weird NSPredicate structure when using "first" in keypath

Try doing name.#first as FIRST and LAST are reserved words and need escaping: https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/Predicates/Articles/pSyntax.html I just tried: NSComparisonPredicate *p = (NSComparisonPredicate *)[NSComparisonPredicate

Weird NSPredicate structure when using "first" in keypath

I’m writing code that walks through an NSPredicate and generates an alternate form of query from it (similar to what CoreData and Realm do.) I’m seeing some very weird undocumented behavior when format strings are compiled into NSPredicates, if the format string includes a key-path with a

Re: Manually building GUI and Retina Macs

Thanks for the information! On 09.01.2017 at 17:33 Ken Thomases wrote: > On Jan 9, 2017, at 10:13 AM, Andreas Falkenhahn > wrote: > I'm building some windows and controls in my app by manually > creating NSWindow objects and the respective controls and then > adding

Re: Manually building GUI and Retina Macs

On Jan 9, 2017, at 10:13 AM, Andreas Falkenhahn wrote: > > I'm building some windows and controls in my app by manually > creating NSWindow objects and the respective controls and then > adding them to the NSWindow by using > > [[win contentView] addSubview:control]; >

Manually building GUI and Retina Macs

I'm building some windows and controls in my app by manually creating NSWindow objects and the respective controls and then adding them to the NSWindow by using [[win contentView] addSubview:control]; The control and window sizes and their positions are all hard-coded in pixels. Thus, it is

Re: AVSimplePlayer in Swift?

I will post code later today. In the meantime, I think I know what’s happening, but not yet why. In short, the IB message is worthless, and KVO is actually working. Ironically, proved that to myself by ditching it altogether and switching currentTime back to using a local (non-computed) property

Is SMJobBless still the correct way to do authorisation?

I'm working on an app which will be written in Swift, but which needs to use some authorisation method to allow creation and deletion of files and folders inside the /Library directory. Last time I needed this sort of ability (three years ago), I took the SMJobBless sample code, along with