On Fri, Jun 27, 2008 at 10:09 AM, Peter Ammon <[EMAIL PROTECTED]> wrote:
> > On Jun 25, 2008, at 7:27 PM, Chris wrote: > >> >> The net effect is that NSPredicateEditor can't display a predicate like >> >> NOT (foo = "bar") >> >> >> A bug in NSPredicateEditor system perhaps? But surely someone would have >> seen it before. >> > > Hi Chris, > > NOT type compound predicates only support exactly one subpredicate, or at > least they did when NSPredicateEditor was written. For this reason, the > default implementation of NOT expects the sole subpredicate to be an OR > type. So set this: > > NOT(OR(foo="bar")) Ahh, this would explain why it hasn't been reported before. However the BNF description of predicates does not impose that restriction: http://developer.apple.com/documentation/Cocoa/Conceptual/Predicates/Predicates.pdf And also, when you convert the predicate to a string, it doesn't show the OR. The OR is apparently optimized away by the predicateFormat routine. Since the only way to feasibly store a predicate is as a string, and then parse it back in, its not really consistent. I've worked around it by replacing the matchForPredicate routine of NSPredicateEditorRowTemplate, which is where I think the actual problem lies: - (double)matchForPredicate:(NSPredicate *)predicate { if ([predicate class] == [NSCompoundPredicate self]) { return 0.5; } return 0.0; } _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [EMAIL PROTECTED]
