NSPredicateEditor query
I have an NSPredicateEditor configured to generate my queries. I have two questions: 1. I want my users to be able to construct queries from a simple initial predicate. Ideally I would like the initial predicate to operate on a single key path and look something like: @"(self.fullName CONTAINS[cd] '')” However I would also like the composite predicate row to be visible initially - This is the row that says “”Any / All of the following are true”; The following works but always logs Warning - unable to find template matching predicate 1 == 1 @"(self.fullName CONTAINS[cd] '') AND (1 == 1)” Is there a workaround for this? 2. The second query is connected. I would also like to offer the ability to add additional composite predicate operators (Any/All). The default UI doesn’t seem to implement this. Is the solution simply to implement an action that takes the current predicate format, append an “AND ()” statement and regenerate the predicate? Thanks J ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Bug with NSPredicateEditor in Xcode 4
In my project, I have a problem with editing NSPredicateEditor in a xib with Xcode 4. If I add a row template for strings, when I run my application and try to add a row to the predicate editor, I have an exception saying that it's impossible to init a predicate with a nil expression. If I edit my xib with IB 3, the problem went away. I just want to know if it's a known problem before reporting it. Frédéric PS : in my test case, the exception raise for all template, not only strings predicate template. I don't know why there is a difference in the test case and my application.___ 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 arch...@mail-archive.com
Re: Using NSPredicateEditor with core data
Peter. Thank you very much. On Aug 14, 2010, at 12:27 AM, Peter Ammon wrote: > You can get the left and right expressions, etc. by calling through to super: > > NSComparisonPredicate *superPredicate = [super > predicateWithSubpredicates:subpredicates]; > NSExpression *lhs = [superPredicate leftExpression], *rhs = > [superPredicate rightExpression]; > ... > > You would return a new predicate constructed from from the pieces of super's > predicate, except substitute in your own modifier. > > -Peter > > On Aug 13, 2010, at 3:12 PM, Gustavo Pizano wrote: > >> Peter hello, first of all thanks for the reply. >> >> So yes, I need to cross a to-many relationship. let me see if I got this >> straight because my mind was heading in that same direction you commented, >> just I didn't know what to use or what was the name of the artifact, in this >> case the NSComparasionPredicateModifier. >> >> So due the fact that I already have overwritten NSPredicateEditorRowTemplate >> to enlarge the Floating-Decimal NSTextfield of the right expression, I would >> take that approach first, overwriden the predicateWithSubpredicates method >> and doing the following: >> >> - (NSPredicate *)predicateWithSubpredicates:(NSArray *)subpredicates{ >> NSPredicate * predicate = [NSComparasionPredicate >> predicateWithLeftExpression:(NSExpression *)lhs >> rightExpression:(NSExpression*)rhs modifier: NSAllPredicateModifier >> >> type:(NSPredicateOperatorType)type options:NSCaseInsensitivePredicateOption]; >> } >> >> I don't know what lhs, rhs and type must be. should I pass [[self >> leftExpresions] objectAtIndex:0] and also for the rightExpresion? or does it >> comes from the subpredicates parameter?. >> >> sorry I got little confused there... :( >> >> Thx >> >> Gustavo >> >> >> On Aug 13, 2010, at 11:49 PM, Peter Ammon wrote: >> >>> >>> On Aug 13, 2010, at 8:45 AM, Gustavo Pizano wrote: >>> >>>> Hello all once again. >>>> >>>> I have been searching but I hadn't found something useful, so please >>>> before if you know a place I can look at let me know. >>>> >>>> I have these 3 Entities >>>> >>>> ExpenditureGroup: >>>>name >>>>icon. >>>> --- >>>> toExpenditures. ->> >>>> >>>> >>>> Expenditure >>>>creationDate >>>>location >>>>total >>>> >>>> toExpenditureGroup -> >>>> toExpenditureDetails ->> >>>> >>>> >>>> ExpenditureDetail >>>>detailDescrb >>>>subTotal >>>> -- >>>> toExpenditure -> >>>> >>>> also I have an arrayController that fetches all the ExpenditureGroup >>>> Entities called _expenditureGorupArrayController. >>>> >>>> in my predicate editor I added the NSPredicateEditorRowTemplates with key >>>> paths for toExpenditures.location, toExpenditures.creationDate, >>>> toExpenditures.total, toExpenditures.toExpenditrueDetails.detailDescrb and >>>> finally toExpenditures.toExpenditureDetails.subTotal. >>>> >>>> I dunno if those last 2 are ok.. my guess NO. >>>> >>>> anyway, when I set the predicate, Im setting into the >>>> _expenditureGroupArrayController setFilterPredicate, and pass the >>>> predicate I just created, but nothing seems to work. >>> >>> Hi Gustavo, >>> >>> It looks like you want your predicate to cross a "to-many" relation. Is >>> that right? If so, you need to create a predicate that has an >>> NSComparisonPredicateModifier that knows how to cross to-many relations >>> (that is, either NSAllPredicateModifier or NSAnyPredicateModifier). >>> >>> If you're using NSPredicateEditor to create the predicate, then the >>> RowTemplate has to know to create a predicate with the right modifier. >>> Unfortunately you cannot yet set that up in IB, but you can do it >>> programmatically, by passing the right NSComparisonPredicateModifier to one >>> of the initWith... methods on NSPredicateEditorRowTemplate (see its header). >>> >>> You can also subclass NSPredicateEditorRowTemplate and override >>> -predicateWithSubpredicates: to create an NSPredicate with the proper >>> modifier. >>> >>> Hope that helps, let me know if that's not clear, >>> -Peter >>> >> > ___ 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 arch...@mail-archive.com
Re: Using NSPredicateEditor with core data
You can get the left and right expressions, etc. by calling through to super: NSComparisonPredicate *superPredicate = [super predicateWithSubpredicates:subpredicates]; NSExpression *lhs = [superPredicate leftExpression], *rhs = [superPredicate rightExpression]; ... You would return a new predicate constructed from from the pieces of super's predicate, except substitute in your own modifier. -Peter On Aug 13, 2010, at 3:12 PM, Gustavo Pizano wrote: > Peter hello, first of all thanks for the reply. > > So yes, I need to cross a to-many relationship. let me see if I got this > straight because my mind was heading in that same direction you commented, > just I didn't know what to use or what was the name of the artifact, in this > case the NSComparasionPredicateModifier. > > So due the fact that I already have overwritten NSPredicateEditorRowTemplate > to enlarge the Floating-Decimal NSTextfield of the right expression, I would > take that approach first, overwriden the predicateWithSubpredicates method > and doing the following: > > - (NSPredicate *)predicateWithSubpredicates:(NSArray *)subpredicates{ > NSPredicate * predicate = [NSComparasionPredicate > predicateWithLeftExpression:(NSExpression *)lhs > rightExpression:(NSExpression*)rhs modifier: NSAllPredicateModifier > > type:(NSPredicateOperatorType)type options:NSCaseInsensitivePredicateOption]; > } > > I don't know what lhs, rhs and type must be. should I pass [[self > leftExpresions] objectAtIndex:0] and also for the rightExpresion? or does it > comes from the subpredicates parameter?. > > sorry I got little confused there... :( > > Thx > > Gustavo > > > On Aug 13, 2010, at 11:49 PM, Peter Ammon wrote: > >> >> On Aug 13, 2010, at 8:45 AM, Gustavo Pizano wrote: >> >>> Hello all once again. >>> >>> I have been searching but I hadn't found something useful, so please >>> before if you know a place I can look at let me know. >>> >>> I have these 3 Entities >>> >>> ExpenditureGroup: >>> name >>> icon. >>> --- >>> toExpenditures. ->> >>> >>> >>> Expenditure >>> creationDate >>> location >>> total >>> >>> toExpenditureGroup -> >>> toExpenditureDetails ->> >>> >>> >>> ExpenditureDetail >>> detailDescrb >>> subTotal >>> -- >>> toExpenditure -> >>> >>> also I have an arrayController that fetches all the ExpenditureGroup >>> Entities called _expenditureGorupArrayController. >>> >>> in my predicate editor I added the NSPredicateEditorRowTemplates with key >>> paths for toExpenditures.location, toExpenditures.creationDate, >>> toExpenditures.total, toExpenditures.toExpenditrueDetails.detailDescrb and >>> finally toExpenditures.toExpenditureDetails.subTotal. >>> >>> I dunno if those last 2 are ok.. my guess NO. >>> >>> anyway, when I set the predicate, Im setting into the >>> _expenditureGroupArrayController setFilterPredicate, and pass the predicate >>> I just created, but nothing seems to work. >> >> Hi Gustavo, >> >> It looks like you want your predicate to cross a "to-many" relation. Is >> that right? If so, you need to create a predicate that has an >> NSComparisonPredicateModifier that knows how to cross to-many relations >> (that is, either NSAllPredicateModifier or NSAnyPredicateModifier). >> >> If you're using NSPredicateEditor to create the predicate, then the >> RowTemplate has to know to create a predicate with the right modifier. >> Unfortunately you cannot yet set that up in IB, but you can do it >> programmatically, by passing the right NSComparisonPredicateModifier to one >> of the initWith... methods on NSPredicateEditorRowTemplate (see its header). >> >> You can also subclass NSPredicateEditorRowTemplate and override >> -predicateWithSubpredicates: to create an NSPredicate with the proper >> modifier. >> >> Hope that helps, let me know if that's not clear, >> -Peter >> > ___ 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 arch...@mail-archive.com
Re: Using NSPredicateEditor with core data
Peter hello, first of all thanks for the reply. So yes, I need to cross a to-many relationship. let me see if I got this straight because my mind was heading in that same direction you commented, just I didn't know what to use or what was the name of the artifact, in this case the NSComparasionPredicateModifier. So due the fact that I already have overwritten NSPredicateEditorRowTemplate to enlarge the Floating-Decimal NSTextfield of the right expression, I would take that approach first, overwriden the predicateWithSubpredicates method and doing the following: - (NSPredicate *)predicateWithSubpredicates:(NSArray *)subpredicates{ NSPredicate * predicate = [NSComparasionPredicate predicateWithLeftExpression:(NSExpression *)lhs rightExpression:(NSExpression*)rhs modifier: NSAllPredicateModifier type:(NSPredicateOperatorType)type options:NSCaseInsensitivePredicateOption]; } I don't know what lhs, rhs and type must be. should I pass [[self leftExpresions] objectAtIndex:0] and also for the rightExpresion? or does it comes from the subpredicates parameter?. sorry I got little confused there... :( Thx Gustavo On Aug 13, 2010, at 11:49 PM, Peter Ammon wrote: > > On Aug 13, 2010, at 8:45 AM, Gustavo Pizano wrote: > >> Hello all once again. >> >> I have been searching but I hadn't found something useful, so please before >> if you know a place I can look at let me know. >> >> I have these 3 Entities >> >> ExpenditureGroup: >> name >> icon. >> --- >> toExpenditures. ->> >> >> >> Expenditure >> creationDate >> location >> total >> >> toExpenditureGroup -> >> toExpenditureDetails ->> >> >> >> ExpenditureDetail >> detailDescrb >> subTotal >> -- >> toExpenditure -> >> >> also I have an arrayController that fetches all the ExpenditureGroup >> Entities called _expenditureGorupArrayController. >> >> in my predicate editor I added the NSPredicateEditorRowTemplates with key >> paths for toExpenditures.location, toExpenditures.creationDate, >> toExpenditures.total, toExpenditures.toExpenditrueDetails.detailDescrb and >> finally toExpenditures.toExpenditureDetails.subTotal. >> >> I dunno if those last 2 are ok.. my guess NO. >> >> anyway, when I set the predicate, Im setting into the >> _expenditureGroupArrayController setFilterPredicate, and pass the predicate >> I just created, but nothing seems to work. > > Hi Gustavo, > > It looks like you want your predicate to cross a "to-many" relation. Is that > right? If so, you need to create a predicate that has an > NSComparisonPredicateModifier that knows how to cross to-many relations (that > is, either NSAllPredicateModifier or NSAnyPredicateModifier). > > If you're using NSPredicateEditor to create the predicate, then the > RowTemplate has to know to create a predicate with the right modifier. > Unfortunately you cannot yet set that up in IB, but you can do it > programmatically, by passing the right NSComparisonPredicateModifier to one > of the initWith... methods on NSPredicateEditorRowTemplate (see its header). > > You can also subclass NSPredicateEditorRowTemplate and override > -predicateWithSubpredicates: to create an NSPredicate with the proper > modifier. > > Hope that helps, let me know if that's not clear, > -Peter > ___ 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 arch...@mail-archive.com
Re: Using NSPredicateEditor with core data
On Aug 13, 2010, at 8:45 AM, Gustavo Pizano wrote: > Hello all once again. > > I have been searching but I hadn't found something useful, so please before > if you know a place I can look at let me know. > > I have these 3 Entities > > ExpenditureGroup: > name > icon. > --- > toExpenditures. ->> > > > Expenditure > creationDate > location > total > > toExpenditureGroup -> > toExpenditureDetails ->> > > > ExpenditureDetail > detailDescrb > subTotal > -- > toExpenditure -> > > also I have an arrayController that fetches all the ExpenditureGroup Entities > called _expenditureGorupArrayController. > > in my predicate editor I added the NSPredicateEditorRowTemplates with key > paths for toExpenditures.location, toExpenditures.creationDate, > toExpenditures.total, toExpenditures.toExpenditrueDetails.detailDescrb and > finally toExpenditures.toExpenditureDetails.subTotal. > > I dunno if those last 2 are ok.. my guess NO. > > anyway, when I set the predicate, Im setting into the > _expenditureGroupArrayController setFilterPredicate, and pass the predicate I > just created, but nothing seems to work. Hi Gustavo, It looks like you want your predicate to cross a "to-many" relation. Is that right? If so, you need to create a predicate that has an NSComparisonPredicateModifier that knows how to cross to-many relations (that is, either NSAllPredicateModifier or NSAnyPredicateModifier). If you're using NSPredicateEditor to create the predicate, then the RowTemplate has to know to create a predicate with the right modifier. Unfortunately you cannot yet set that up in IB, but you can do it programmatically, by passing the right NSComparisonPredicateModifier to one of the initWith... methods on NSPredicateEditorRowTemplate (see its header). You can also subclass NSPredicateEditorRowTemplate and override -predicateWithSubpredicates: to create an NSPredicate with the proper modifier. Hope that helps, let me know if that's not clear, -Peter ___ 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 arch...@mail-archive.com
Using NSPredicateEditor with core data
Hello all once again. I have been searching but I hadn't found something useful, so please before if you know a place I can look at let me know. I have these 3 Entities ExpenditureGroup: name icon. --- toExpenditures. ->> Expenditure creationDate location total toExpenditureGroup -> toExpenditureDetails ->> ExpenditureDetail detailDescrb subTotal -- toExpenditure -> also I have an arrayController that fetches all the ExpenditureGroup Entities called _expenditureGorupArrayController. in my predicate editor I added the NSPredicateEditorRowTemplates with key paths for toExpenditures.location, toExpenditures.creationDate, toExpenditures.total, toExpenditures.toExpenditrueDetails.detailDescrb and finally toExpenditures.toExpenditureDetails.subTotal. I dunno if those last 2 are ok.. my guess NO. anyway, when I set the predicate, Im setting into the _expenditureGroupArrayController setFilterPredicate, and pass the predicate I just created, but nothing seems to work. I was reading apple docs, and I see here I need to do some join, but there it says its not possible, that I have to fetch first something and then using operators get the other required objects. I really dunno even if the key paths I set for the templates are ok or no, because I thought that If im gonna apply the predicate to the arraycontroller with entity is ExpenditureGroup, then I can simple use the relationships. Any suggestion? Thx Gustavo ___ 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 arch...@mail-archive.com
Re: Can't resize Floating-Number NSTextfield in NSPredicateEditor.
Dave: Thanks worked like charm! . Gustavo On Aug 13, 2010, at 3:39 PM, Dave DeLong wrote: > NSPredicateEditorRowTemplate ___ 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 arch...@mail-archive.com
Re: Can't resize Floating-Number NSTextfield in NSPredicateEditor.
Dave thanks for the reply Im gonna try it right away. Gustavo. On Aug 13, 2010, at 3:39 PM, Dave DeLong wrote: > This is only resizing the textfield of the row *template*, not the row > itself. I've found that the easiest way to do what you're wanting is to > subclass NSPredicateEditorRowTemplate and override the templateViews method. > In that method you'll invoke super's implementation, then alter the frame of > the last view in the array (just like you posted), and then return the array. > > Don't forget to change the row class in IB either! > > Dave DeLong > > Sent from my iPhone > > On Aug 13, 2010, at 7:33 AM, Gustavo Pizano > wrote: > >> Hello all, I come to you asking for humble guidance. >> >> after reading the way to resize the TextFields in some other topic, I tried >> myself, without success.. >> >> This is what I have. >> >> A parent view which display the panel that contains the predicate editor, >> this predicate editor controller (NSWindowController) has an @property >> (assign) pointing to the parent controller. In the parent controller I have >> a NSPredicate ivar which at the moment before initializing the panel, I >> initialize it with a Default Predicate. >> >> In IB, I set via Bindings the value for the predicate editor to >> _parentController.predicate. >> >> So when I run and click the button that display the panel, the panel appears >> and the predicate editor is there with the default predicate I set up. So >> far so Good. >> >> But I can' t rezise the NSTextField view of a Floating-Double number, in my >> PanelController on the awakefromNib method I added this code: >> >> NSArray* rtemplates = [pe rowTemplates]; >> for(NSPredicateEditorRowTemplate * peRT in rtemplates){ >> if([peRT rightExpressionAttributeType] == NSDoubleAttributeType){ >> NSView * v = [[peRT templateViews] lastObject]; >> if([v isKindOfClass:[NSTextField class]]){ >> NSRect frame = [v frame]; // comment 1 >> frame.size.width = 200; >> [v setFrame:frame]; >> >> } >> } >> } >> >> I set a Breakpoint into //comment 1, and I get the size of the field which >> is 25, then as you see I set it up to 200 and re-set the frame property. >> >> But nothing happens I still see that field with the small size >> >> >> What can I do?, what am I missing?... I have tried moving the code above to >> different methods such as the initWithNibName:, just testing ... with no >> good results either. >> >> >> thanks >> >> Gustavo >> >> >> ___ >> >> 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/davedelong%40me.com >> >> This email sent to davedel...@me.com > ___ > > 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/gustavxcodepicora%40gmail.com > > This email sent to gustavxcodepic...@gmail.com ___ 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 arch...@mail-archive.com
Re: Can't resize Floating-Number NSTextfield in NSPredicateEditor.
This is only resizing the textfield of the row *template*, not the row itself. I've found that the easiest way to do what you're wanting is to subclass NSPredicateEditorRowTemplate and override the templateViews method. In that method you'll invoke super's implementation, then alter the frame of the last view in the array (just like you posted), and then return the array. Don't forget to change the row class in IB either! Dave DeLong Sent from my iPhone On Aug 13, 2010, at 7:33 AM, Gustavo Pizano wrote: > Hello all, I come to you asking for humble guidance. > > after reading the way to resize the TextFields in some other topic, I tried > myself, without success.. > > This is what I have. > > A parent view which display the panel that contains the predicate editor, > this predicate editor controller (NSWindowController) has an @property > (assign) pointing to the parent controller. In the parent controller I have a > NSPredicate ivar which at the moment before initializing the panel, I > initialize it with a Default Predicate. > > In IB, I set via Bindings the value for the predicate editor to > _parentController.predicate. > > So when I run and click the button that display the panel, the panel appears > and the predicate editor is there with the default predicate I set up. So far > so Good. > > But I can' t rezise the NSTextField view of a Floating-Double number, in my > PanelController on the awakefromNib method I added this code: > >NSArray* rtemplates = [pe rowTemplates]; >for(NSPredicateEditorRowTemplate * peRT in rtemplates){ >if([peRT rightExpressionAttributeType] == NSDoubleAttributeType){ >NSView * v = [[peRT templateViews] lastObject]; >if([v isKindOfClass:[NSTextField class]]){ >NSRect frame = [v frame]; // comment 1 >frame.size.width = 200; >[v setFrame:frame]; > >} >} >} > > I set a Breakpoint into //comment 1, and I get the size of the field which > is 25, then as you see I set it up to 200 and re-set the frame property. > > But nothing happens I still see that field with the small size > > > What can I do?, what am I missing?... I have tried moving the code above to > different methods such as the initWithNibName:, just testing ... with no good > results either. > > > thanks > > Gustavo > > > ___ > > 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/davedelong%40me.com > > This email sent to davedel...@me.com ___ 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 arch...@mail-archive.com
Can't resize Floating-Number NSTextfield in NSPredicateEditor.
Hello all, I come to you asking for humble guidance. after reading the way to resize the TextFields in some other topic, I tried myself, without success.. This is what I have. A parent view which display the panel that contains the predicate editor, this predicate editor controller (NSWindowController) has an @property (assign) pointing to the parent controller. In the parent controller I have a NSPredicate ivar which at the moment before initializing the panel, I initialize it with a Default Predicate. In IB, I set via Bindings the value for the predicate editor to _parentController.predicate. So when I run and click the button that display the panel, the panel appears and the predicate editor is there with the default predicate I set up. So far so Good. But I can' t rezise the NSTextField view of a Floating-Double number, in my PanelController on the awakefromNib method I added this code: NSArray * rtemplates = [pe rowTemplates]; for(NSPredicateEditorRowTemplate * peRT in rtemplates){ if([peRT rightExpressionAttributeType] == NSDoubleAttributeType){ NSView * v = [[peRT templateViews] lastObject]; if([v isKindOfClass:[NSTextField class]]){ NSRect frame = [v frame]; // comment 1 frame.size.width = 200; [v setFrame:frame]; } } } I set a Breakpoint into //comment 1, and I get the size of the field which is 25, then as you see I set it up to 200 and re-set the frame property. But nothing happens I still see that field with the small size What can I do?, what am I missing?... I have tried moving the code above to different methods such as the initWithNibName:, just testing ... with no good results either. thanks Gustavo ___ 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 arch...@mail-archive.com
NSPredicateEditor, _NSRuleEditorViewUnboundRowHolder and boundArray error moving to 10.6
I have an application originally written for the 10.5 SDK. The app presents a document modal sheet (owned by a separate NSWindowController subclass) which contains an NSPredicateEditor. Starting with the move to OS X 10.6, I am getting the following exception when calling setObjectValue: on the predicate editor instance from within my window controller subclass: [<_NSRuleEditorViewUnboundRowHolder 0x1005ccf50> valueForUndefinedKey:]: this class is not key value coding-compliant for the key boundArray. I have verified that the nib containing the window has been loaded correctly and that the object value I'm trying to set is a valid NSPredicate. Since my app uses several custom row templates, I removed the call to setRowTemplates and put some generic row templates in the editor via Interface Builder. I still receive the same error. I am *not* able to replicate this error with a small test project, hence the problem is clearly in my code, but I am lost in tracking down the source of the problem. Has anyone come across this issue and/or have a suggestion for where to start? Any help greatly appreciated. Thanks, Barry ___ 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 arch...@mail-archive.com
Re: Dragging rows in NSPredicateEditor
On Mar 12, 2010, at 7:17 PM, Graham Cox wrote: > > On 13/03/2010, at 2:03 PM, Graham Cox wrote: > >> I notice though that at runtime I'm able to drag an image of each row. What >> can I do with this drag? > > I just realised that the drag allows me to reorder the rows - is that its > only purpose? Yes, that's all. > I didn't realise that before because it is still draggable even when there is > only one row or one row plus the header row of a compound predicate. > Shouldn't that drag be suppressed if there is nothing useful for it to do? You could conceivably drag it between predicate editors, but I don't think that was ever implemented. -Peter___ 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 arch...@mail-archive.com
Re: Dragging rows in NSPredicateEditor
On 13/03/2010, at 2:03 PM, Graham Cox wrote: > I notice though that at runtime I'm able to drag an image of each row. What > can I do with this drag? I just realised that the drag allows me to reorder the rows - is that its only purpose? I didn't realise that before because it is still draggable even when there is only one row or one row plus the header row of a compound predicate. Shouldn't that drag be suppressed if there is nothing useful for it to do? --Graham ___ 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 arch...@mail-archive.com
Dragging rows in NSPredicateEditor
I'm using the NSPredicateEditor control for the first time, and so far it's going well. I notice though that at runtime I'm able to drag an image of each row. What can I do with this drag? I either need to be able to process it in some meaningful way (there may be none for my app) or turn it off. The docs appear not to mention this behaviour anywhere, there's nothing i can see in API and there's no Pboard type that seems to relate to predicates. --Graham ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor losing nextKeyView
On Feb 23, 2010, at 2:31 PM, Trygve Inda wrote: >> On Feb 21, 2010, at 9:50 PM, Trygve Inda wrote: >> >>> In my sheet, I have a "name" NSTextField and an NSPredicateEditor. >>> Initially, the tab key works to jump between my name field and the first >>> match field in the predicate editor. >>> >>> However, after changing any of the menus in the line of my predicate editor, >>> the tab key no longer allows the keyfield to rotate out of the >>> NSPredicateEditor back to other fields in my sheet. >>> >>> Is this a bug or do I need to hook up something to make it work? >> >> I noticed this happening sometimes in my code too. As a quick fix I just >> issued a delayed -recalculateKeyViewLoop message on any change of the search >> predicate when the view was visible. > > It does the same thing when adding a row but... > > NSRuleEditorRowsDidChangeNotification is only sent when changing popup menus > or text, not when simply adding a row. > > Thoughts? I have the predicate editor bound to a predicate in my controller. Then in my -setPredicate: method of the controller I'm issuing a delayed recalculation of the key-view loop. You could probably just observe for changes to the predicate on the predicate editor itself but I'm not sure if NSPredicateEditor sends KVO notifications or not for that property. Ashley ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor losing nextKeyView
> On Feb 21, 2010, at 9:50 PM, Trygve Inda wrote: > >> In my sheet, I have a "name" NSTextField and an NSPredicateEditor. >> Initially, the tab key works to jump between my name field and the first >> match field in the predicate editor. >> >> However, after changing any of the menus in the line of my predicate editor, >> the tab key no longer allows the keyfield to rotate out of the >> NSPredicateEditor back to other fields in my sheet. >> >> Is this a bug or do I need to hook up something to make it work? > > I noticed this happening sometimes in my code too. As a quick fix I just > issued a delayed -recalculateKeyViewLoop message on any change of the search > predicate when the view was visible. > > > Ashley > > > > It does the same thing when adding a row but... NSRuleEditorRowsDidChangeNotification is only sent when changing popup menus or text, not when simply adding a row. Thoughts? Trygve ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor losing nextKeyView
On Feb 21, 2010, at 9:50 PM, Trygve Inda wrote: > In my sheet, I have a "name" NSTextField and an NSPredicateEditor. > Initially, the tab key works to jump between my name field and the first > match field in the predicate editor. > > However, after changing any of the menus in the line of my predicate editor, > the tab key no longer allows the keyfield to rotate out of the > NSPredicateEditor back to other fields in my sheet. > > Is this a bug or do I need to hook up something to make it work? I noticed this happening sometimes in my code too. As a quick fix I just issued a delayed -recalculateKeyViewLoop message on any change of the search predicate when the view was visible. Ashley ___ 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 arch...@mail-archive.com
NSPredicateEditor losing nextKeyView
In my sheet, I have a "name" NSTextField and an NSPredicateEditor. Initially, the tab key works to jump between my name field and the first match field in the predicate editor. However, after changing any of the menus in the line of my predicate editor, the tab key no longer allows the keyfield to rotate out of the NSPredicateEditor back to other fields in my sheet. Is this a bug or do I need to hook up something to make it work? Thanks, Trygve ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor Continuous updating failes
On Thu, Jan 21, 2010 at 6:00 AM, Florian Soenens wrote: > Hi LIst, > > i set up an NSPredicateEditor and got it all working fine except that it > only executes when i hit enter or tab out of the NSTextField. > Is there a way to let it execute everytime something changes in the > textfield? > > I tried checking the "continuous" button in IB but that is impossible, it > always unchecks itself. I also tried setting continuous programatically but > to no avail... > > Anyone has any suggestions? > > Kind regards, > Florian. Add an observer for notifications of NSControlTextDidChangeNotification. When the predicate editor updates a text field, it'll send this notification with itself as the object value. -- Jim http://nukethemfromorbit.com ___ 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 arch...@mail-archive.com
NSPredicateEditor Continuous updating failes
Hi LIst, i set up an NSPredicateEditor and got it all working fine except that it only executes when i hit enter or tab out of the NSTextField. Is there a way to let it execute everytime something changes in the textfield? I tried checking the "continuous" button in IB but that is impossible, it always unchecks itself. I also tried setting continuous programatically but to no avail... Anyone has any suggestions? Kind regards, Florian. Looking for Web-to-Print Solutions? Visit our website : http://www.vit2print.com This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information and/or information protected by intellectual property rights. If you are not the intended recipient, please note that any review, dissemination, disclosure, alteration, printing, copying or transmission of this e-mail and/or any file transmitted with it, is strictly prohibited and may be unlawful. If you have received this e-mail by mistake, please immediately notify the sender and permanently delete the original as well as any copy of any e-mail and any printout thereof. We may monitor e-mail to and from our network. NSS nv Tieltstraat 167 8740 Pittem Belgium ___ 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 arch...@mail-archive.com
Re: Having problems understanding NSPredicateEditor
The only way I have done this is to build the thing in IB. Forget the NSSearchField. First add a Predicate Editor to a window. This gives you a top-level compound predicate ("Any of the following are true") and a single predicate template. The predicate template has three parts, a left expression, a set of operators, and a right expression. Click on the template to show its attributes in the Inspector. Each template combines a single type of L.E, e.g. Key Paths, and a single type of R.E., e.g. Strings, and a set of operators. For instance, all the searchable key paths that have string values are included in a single template. You would add "cardName" and any other searchable string variable. In the middle section, select the required comparison operators. The R.E. is then set to Strings, and since these are provided by the user, you don't list them here. If you had a date variable, then you make another template, this time setting the R.E. to Date. Obviously there are many combinations possible, since there are 6 possibilities for L.E. and R.E. You need to work out the characteristics of each template appropriately. You must understand that, although the editor you create in I.B. looks visually like the filter predicate the user creates, it really is very different. The set of the templates you create in I.B. define the types of comparisons the user can make, but doesn't create any instances of them. The user instantiates as many of each template as he likes at run time to build the total predicate. When you enter the list of L.E.s, the left popup in the row template is populated with choices that have the same names as appear in the L.E. list. You can change the popup item strings by double-clicking the item and changing the string, in the usual way. Once you understand this much, you should understand how many templates you need. (This does not mean how many filter comparisons the user can define, which are unlimited, but how many types of comparisons your program allows. For instance, a comparison of a key path to a string would be one, to a date would be another, to a constant a third, and so on.) Call this number N. Now you should examine the Editor itself in the Inspector and set the number of templates to N. This will produce N templates. You set up each one of them to match one of the types of comparison. The editor also has an attribute to allow all rows to be deleted. If this is turned on, then the top row template can be deleted by the user using the minus button. If the user does this, then the top level compound row also disappears (sometimes), leaving a totally blank view, which makes the editor useless. At least this was the case under Leopard. So you pretty much have to turn this off. This leaves you with a predicate that must have at least one comparison, even if you might like to have a predicate editor without any comparisons, which would match everything. I'm suspicious that I don't quite understand what's going on here, but I haven't achieved any greater clarity. Now, when the editor is created out of the nib file, it is created with a single empty compound. But since this produces a editor that is totally blank, it is useless. So at some early stage, for instance, in awakeFromNib, you have to add a row by sending the editor an addRow message. Adding this row actually produces two rows, since once a row template is added, the compound row also appears, and you're good to go. I have used the action method of the predicate editor to inform my app delegate that the user has changed the predicate, which I then apply to an array controller. There are probably other approaches. I have not created one of these in Snow Leopard, so some of the details may have changed. Tim Larkin Abstract Tools ___ 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 arch...@mail-archive.com
Having problems understanding NSPredicateEditor
I have an application that contains a NSTableView of Card data types. The NSTableView gets its data from an NSArray of Card instances. I want to allow the user to be able to filter the view based on the Card fields. I know I need to use a NSPredicateEditor to present the UI for the user, and to create the NSPredicate instances. However, I cannot wrap my head around how this works, and cannot get a simple example working (with a single rule). I have spent the last two days reading up on it, and it is just not clicking for me. So, does anyone have a very simple example of how to use NSPredicateEditor programmatically? I want to be able to allow the user to potentially filter on multiple fields, but would be happy if I can get a single field to work right now. Here is the current predicate I am using with a NSSearchField: NSPredicate *namePredicate = [NSPredicate predicateWithFormat:@"cardName contains[c] %@", searchString]; [filteredCards filterUsingPredicate:namePredicate]; Card has a property (NSString) named "cardName". I have tried to programmatically add a NSPredicateEditorRowTemplate, but when I do this, nothing shows up in the editor at runtime. NSPredicateEditorRowTemplate *template = [[NSPredicateEditorRowTemplate alloc] initWithLeftExpressions:[NSArray arrayWithObjects:[NSExpression expressionForKeyPath:@"cardName"], nil] rightExpressions:[NSArray arrayWithObjects:[NSExpression expressionForConstantValue:@"Foo"], nil] modifier:NSDirectPredicateModifier operators:[NSArray arrayWithObject:[NSNumber numberWithInt:NSContainsPredicateOperatorType]] options:NSCaseInsensitivePredicateOption ]; predicateEditor.rowTemplates = [NSArray arrayWithObject:template]; I am really stumped on this one, and would appreciate it if someone could help nudge me in the right direction. Does anyone have a simple example of how to construct NSPredicateEditorRowTemplate that will create a filter like so: cardName contains USER_INPUT I think if I can get that working, then it will put me over the hump and I can figure out the rest. mike ___ 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 arch...@mail-archive.com
Help Debugging NSPredicateEditor reloadCriteria Exception
Under 10.6.2 my program is throwing an exception when I call the NSPredicateEditor method reloadCriteria. I do not see the behavior on earlier releases of 10.6 or 10.5. When the exception is thrown the stack is the following: #0 0x96f624e6 in objc_exception_throw () #1 0x95657138 in +[NSException raise:format:arguments:] () #2 0x956570aa in +[NSException raise:format:] () #3 0x9926b496 in -[NSPredicateEditor _predicateFromRowItem:] () #4 0x9926a320 in -[NSPredicateEditor _updatePredicateFromRows] () #5 0x9920ac4e in -[NSRuleEditor observeValueForKeyPath:ofObject:change:context:] () #6 0x9820aca7 in NSKeyValueDidChange () #7 0x981ef6d0 in -[NSObject(NSKeyValueObserverNotification) didChangeValueForKey:] () #8 0x981e587a in -[NSCFDictionary setObject:forKey:] () #9 0x98206dac in _NSSetUsingKeyValueSetter () #10 0x982e5674 in -[NSKeyValueSlowMutableArray removeObjectAtIndex:] () #11 0x95645c73 in -[NSMutableArray removeAllObjects] () #12 0x982e4825 in -[NSKeyValueMutableArray setArray:] () #13 0x992051a6 in -[NSRuleEditor reloadCriteria] () #14 0x99269f0b in -[NSPredicateEditor reloadCriteria] () #15 0x00026971 in -[Game_Document Display_Filter_Window:] (self=0x1053ec0, _cmd=0x336af, sender=0x10b75b0) at /Volumes/HD/Football_Review/Source/Game_Document.m:1705 #16 0x98b98f86 in -[NSApplication sendAction:to:from:] () #17 0x98c78705 in -[NSControl sendAction:to:] () #18 0x98c741ba in -[NSCell _sendActionFrom:] () #19 0x98c734b1 in -[NSCell trackMouse:inRect:ofView:untilMouseUp:] () #20 0x98cc895d in -[NSButtonCell trackMouse:inRect:ofView:untilMouseUp:] () #21 0x98c71f07 in -[NSControl mouseDown:] () #22 0x98c6ff10 in -[NSWindow sendEvent:] () #23 0x98b88b2f in -[NSApplication sendEvent:] () #24 0x98b1c4ff in -[NSApplication run] () #25 0x98b14535 in NSApplicationMain () #26 0x2960 in main (argc=1, argv=0xb7ec) at /Volumes/HD/Football_Review/Source/main.m:13 The following information is output to the console log: 2009-12-15 09:32:49.865 Football_Review[987:a0f] In , different number of items (1) than values (2) Below is my function that calls reloadCriteria: - (IBAction) Display_Filter_Window:(id)sender { if ( ! [main_window makeFirstResponder:main_window]) //force edit compleation return; [plays_predicate_editor reloadCriteria]; [ NSApp beginSheet:filter_window modalForWindow: main_window modalDelegate:self didEndSelector:@selector(sheetDidEnd:returnCode:contextInfo:) contextInfo:NULL]; } I have greatly simplified my predicate and I still get the exception. If I comment out the call to reloadCriteria the predicate editor is correctly displayed with the default values setup in IB. What is the log message trying to tell me?. What strategies and tools can I use to debug such a problem? Thank you for the help. Marshall ___ 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 arch...@mail-archive.com
Re: Possible NSPredicateEditor bug (found workaround)
On 03/07/2009, at 12:26 PM, Tom wrote: Hi everyone, I'm either doing something wrong, or I've found a bug in NSPredicateEditor. Whenever I use setObjectValue: on the NSPredicateEditor, it displays the new predicate, but if I change a couple of the operators (is, contains, begins with, etc) the text fields on the rows disappear. Screenshot: http://www.tomdalling.com/wp-content/Picture-1.png Demo project: http://www.tomdalling.com/wp-content/PredicateEditorBug.zip Here is the relevant code: -(IBAction) setPredicateEditorObjectValue:(id)sender { NSPredicate* single = [NSPredicate predicateWithFormat:@"name == 'test'"]; NSMutableArray* subpredicates = [NSMutableArray array]; [subpredicates addObject:[[single copy] autorelease]]; [subpredicates addObject:[[single copy] autorelease]]; [subpredicates addObject:[[single copy] autorelease]]; [subpredicates addObject:[[single copy] autorelease]]; NSPredicate* compound = [NSCompoundPredicate orPredicateWithSubpredicates:subpredicates]; [m_predicateEditor setObjectValue:compound]; } Am I doing something wrong? --Tom For anyone having the same problem, here is the workaround I've discovered. It's not the most elegant solution, but it works. 1. Set the NSPredicateEditor's target/action to an IBAction on your controller 2. Put this code in the controller's IBAction method: NSPredicate* objectValue = [[[m_predEditor objectValue] retain] autorelease]; [m_predEditor setObjectValue:nil]; [m_predEditor setObjectValue:objectValue]; --Tom ___ 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 arch...@mail-archive.com
Possible NSPredicateEditor bug
Hi everyone, I'm either doing something wrong, or I've found a bug in NSPredicateEditor. Whenever I use setObjectValue: on the NSPredicateEditor, it displays the new predicate, but if I change a couple of the operators (is, contains, begins with, etc) the text fields on the rows disappear. Screenshot: http://www.tomdalling.com/wp-content/Picture-1.png Demo project: http://www.tomdalling.com/wp-content/PredicateEditorBug.zip Here is the relevant code: -(IBAction) setPredicateEditorObjectValue:(id)sender { NSPredicate* single = [NSPredicate predicateWithFormat:@"name == 'test'"]; NSMutableArray* subpredicates = [NSMutableArray array]; [subpredicates addObject:[[single copy] autorelease]]; [subpredicates addObject:[[single copy] autorelease]]; [subpredicates addObject:[[single copy] autorelease]]; [subpredicates addObject:[[single copy] autorelease]]; NSPredicate* compound = [NSCompoundPredicate orPredicateWithSubpredicates:subpredicates]; [m_predicateEditor setObjectValue:compound]; } Am I doing something wrong? --Tom ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
Thanks to Kyle and Melissa for the further explanation. So, I thought about it some more and agree with you that putting a few redundant bits on the disk is not sinful, and actually I am a fan of keyPathsForValuesAffectingValueFor. Look at the little script I have in my Xcode scripts menu! [1] But the other issue -- the inability of a Core Data fetch to handle arbitrary predicates produced by NSPredicateEditor -- weighs heavily against Core Data fetches. I made my own simple predicate editor control a few years ago, but of course it is a pile of garbage compared to NSPredicateEditor, and I just can't go back to 2006 now. So I still plan to use NSPredicateEditor, fetch all and filter with - [NSArray filteredArrayWithPredicate:]. I have used sqlite3 directly myself and don't recall any limitation on the number of ALL, ANY or IN clauses. If there is not, then maybe Apple would be responsive to a enhancement/bug report on Core Data fetches not being able to handle predicates from NSPredicateEditor. And if I'm lucky Apple will fix it before any of my users has a data set large enough to require hard disk access during a search :) Jerry [1] Script for coding +keyPathsForValuesAffecting... #!/bin/sh echo "+ (NSSet*)keyPathsForValuesAffecting {" echo " return [NSSet setWithObjects:" echo " @\"\"," echo " nil] ;" echo "}" echo ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
(apologies for the delay; I've been on vacation for the last few days and just got back) On Apr 28, 2009, at 14:32, Kyle Sluder wrote: So step 1 is to stop clinging to normalization rules. (My database professor would kill me for that sentence, but it's true.) There really is no redundancy here, because the data stored on disk is never really separated from the model objects which use that data. In an n-tier app, you would be correct to avoid storing the derived property. Even in an n-tier application there are situations where it makes more sense to denormalize data than cling to theoretical purity. Once common case is to avoid joins, because they're *expensive*. Sometimes, the dba level pain of maintaining duplicate/derived data is much less than the user level pain of doing a join to display information in a frequently accessed view. There's no general rule for when this becomes true, because it's data set and use dependent, and it's not something you should do casually or without understanding what you're doing, why, and what tradeoffs are involved, but it is part of building a schema that's does what you need it to do efficiently. You can see an example of denormalized data in the Leopard version of iCal. The badges on the corner of events in the varying day/week/month views displays meta-information about the relationship that contains the note/contact/etc data. Having the badge provides useful information (there are other people invited, click here for meeting material), but it's expensive to do the join just to decide whether or not to display that badge for any given event, so iCal stores a separate bit of information saying "this event has notes/contacts/ etc". According to pure relational design, this is a Very Bad Thing, because it duplicates information that exists in the join tables and introduces the possibility of error into the database. According to real-world performance, not doing the join sped displaying those views up by an order of magnitude (more in the case of large calendars). Taking normalization to it's fullest extent, you end up with things like databases where a Person is a set of joins to a Names table (don't get me started on natural vs assigned integer keys ;-), but no one outside academia does that because it's overkill and inefficient for anything except theoretical work. As for the logic required to maintain this relationship, that's why we have KVC/KVO! Implement +keyPathsForValuesAffectingValueFor: as appropriate. Implement your KVC setters/getters for the independent attributes such that they invoke -setPrimitiveValue:forKey: for the required dependent properties. This is what I was getting at, yes. Create a separate modeled property 'letterGrade' and have the mutator for 'percentageGrade' automatically update it whenever percentageGrade is changed. Add observers as necessary. +Melissa ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On Tue, Apr 28, 2009 at 5:15 PM, Jerry Krinock wrote: > If Melissa is referring to a managed property, if it is non-transient, then > yes this could be used in the predicate of a Core Data fetch. The > disadvantage is that now every object in every store has this redundant > (derived) attribute. More important than the wasted bits is that custom > setters are now required to keep the derived attribute in sync with its > source attribute, opening a way to introduce bugs into future versions. We all love normalization. That is, until it hinders our progress. One of the things to keep in mind with Core Data is that you are *not* using an RDMBS. Sure, one might provide the backing storage under the hood, but the traditional concern with data normalization in an n-tier enterprise situation is with the data: the data must remain pure and accessible to any number of interfaces. Core Data is different: it's an object graph management framework for desktop apps. You are required by its very nature to couple the business logic much tighter to the data storage, since you really are storing business-logic-bearing model objects. So step 1 is to stop clinging to normalization rules. (My database professor would kill me for that sentence, but it's true.) There really is no redundancy here, because the data stored on disk is never really separated from the model objects which use that data. In an n-tier app, you would be correct to avoid storing the derived property. As for the logic required to maintain this relationship, that's why we have KVC/KVO! Implement +keyPathsForValuesAffectingValueFor: as appropriate. Implement your KVC setters/getters for the independent attributes such that they invoke -setPrimitiveValue:forKey: for the required dependent properties. --Kyle Sluder ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 2009 Apr 23, at 13:53, Melissa J. Turner wrote: Unwinding to the original message, the most correct thing to do would be to add a derived property letterGrade which is automatically updated whenever grade is, which then allows you to search against that. I don't know if a "derived property" is a managed property that appears in the .xcdatamodel, or a regular instance variable. If Melissa is referring to a managed property, if it is non-transient, then yes this could be used in the predicate of a Core Data fetch. The disadvantage is that now every object in every store has this redundant (derived) attribute. More important than the wasted bits is that custom setters are now required to keep the derived attribute in sync with its source attribute, opening a way to introduce bugs into future versions. If Melissa is referring to a regular instance variable, then it cannot be used in the predicate of a Core Data fetch and thus filtering must be done in RAM by -[NSArray filteredArrayWithPredicate], resulting in limited scalability. For my application, I chose the latter. Am I misunderstanding anything? ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 2009 Apr 22, at 01:26, Ben Trumbull wrote: "The Core Data SQL store supports only one to-many operation per query; therefore in any predicate sent to the SQL store, there may be only one operator (and one instance of that operator) from ALL, ANY, and IN." Do you have a specific scenario in which you need to perform nested to-many operations, yet you cannot use SUBQUERY or compound queries like OR ? Or is this troubling, in the sense that the universe is doomed to evaporate kind of way ? Well, I'd rather give my users NSPredicateEditor and let them make that decision. I'm sure that the code which Apple has written to generate predicates in NSPredicateEditor is better than any that I could write, not to mention that Lazy Programmer thing. However, it appears that NSPredicateEditor can produce compound predicates that violate the rule given above. For example, here's one that I just produced in my app: isAllowedDupe == 1 OR dontVerify == 1 OR shortcut CONTAINS "stuff" OR comments CONTAINS "" OR type == 3840 OR name CONTAINS "M" OR (url CONTAINS "a" AND tagsString CONTAINS "apple") A much better way appears to be to fetch all objects from the store with no predicate and then use -[NSArray filteredArrayWithPredicate:]. This takes only one more line of code, solves all problems, and is supposedly cheaper too: This does not solve all problems, it most emphatically is NOT cheaper, and most assuredly does NOT scale Thank you, Ben. I understand about the scaling now. But for applications with typically small data sets, I believe that - filteredArrayWithPredicate can be a good, practical solution for developers who'd like to "leverage the power of NSPredicateEditor" in exchange for having a few users with not enough RAM to hold all their objects experience some hard disk access. Performance is always something that needs to be tested, anyhow. The managed objects in my app have 35 properties and I rarely see a user with more than 1500 objects. Searching is something that the average user might do once a week. I have an early 2006 Mac Mini with 2 GB RAM. Filtering an array on a test database of 5000 objects looks like it takes maybe 20 milliseconds or so. So, yes it would be nice to optimize the search, maybe doing a fetch with Core Data and then further filtering the array as someone suggested. I'll probably do some more testing, but at this point my cost/benefit analysis says to wait until, if ever, it becomes an issue for someone. Maybe Apple might provide an easier solution by then ;) (Yes, I know about the ER procedure.) ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 2009 Apr 23, at 13:53, Melissa J. Turner wrote: Unwinding to the original message, the most correct thing to do would be to add a derived property letterGrade which is automatically updated whenever grade is, which then allows you to search against that. Melissa, please give a more precise definition of "derived property". Is it... (a) an attribute defined in the data model or (b) a plain old instance variable Thanks, Jerry ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On Apr 23, 2009, at 05:18, Mike Abdullah wrote: On 22 Apr 2009, at 22:34, Melissa J. Turner wrote: On Apr 22, 2009, at 02:12, Mike Abdullah wrote: On 22 Apr 2009, at 08:48, Ben Trumbull wrote: Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know Probably because nobody ever cared enough to file an enhancement request, and it didn't occur to us that writing 1 line of code to call filteredArrayWithPredicate was so troublesome. Calling -filteredArrayWithPredicate is no hassle, but for a large predicate, it has the bad performance of comparing a bunch of the persistent properties all over again, despite already knowing they'll match the predicate. Since I assume Core Data must do some kind of internal splitting up of the predicate in order to perform its fetch, I'd have thought it is in a good position to know what the remaining transient portion of the predicate is. You assume incorrectly. CoreData simply translates the predicate to SQL and passes it down to SQLite as a WHERE clause. Hence the lack of support for transient properties: SQLite has no idea what to do when you ask it to qualify by a column that doesn't exist in its schema. OK, so I'm trying to wrap my head around this. Let's say I build a predicate along the lines of: fooPersistent == 123 && fooTransient == 456 And then use it in a fetch request. Does Core Data: A) Pass that predicate straight to SQLite which fails because it can't find a fooTransient column. B) Pass that predicate straight to SQLite which ignores fooTransient (presumably treating it as always evaluating to true). C) Create a "fooPersistent == 123" predicate and pass that to SQLite. Or of course D) something I've failed to conceive of which seems quite probable! D) It varies by store. The SQL store does something close to A, other stores do different things. Feel free to experiment and discover them ;-) Unwinding to the original message, the most correct thing to do would be to add a derived property letterGrade which is automatically updated whenever grade is, which then allows you to search against that. The best uses for transient properties are infrequently used properties and caches that are not directly displayed. If a value is something you're expecting to use regularly (as in a search), it makes more sense to persist it due to the overhead of recalculating. Personal opinion: Data design is all about knowing when to normalize, and when throw the textbook away and denormalize because it makes sense. 3rd normal form is theoretically really spiffy, and kind of sucks in the real world where joins are expensive operations and doing extra I/O avoid 1 byte of storage per row is kind of silly. +Melissa ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 23 Apr 2009, at 15:03, Jerry Krinock wrote: On 2009 Apr 23, at 05:18, Mike Abdullah wrote: OK, so I'm trying to wrap my head around this. Let's say I build a predicate along the lines of: fooPersistent == 123 && fooTransient == 456 And then use it in a fetch request. Does Core Data: A) Pass that predicate straight to SQLite which fails because it can't find a fooTransient column. B) Pass that predicate straight to SQLite which ignores fooTransient (presumably treating it as always evaluating to true). C) Create a "fooPersistent == 123" predicate and pass that to SQLite. Or of course D) something I've failed to conceive of which seems quite probable! In my experience, before I read the documentation and learned not to put transient properties in my predicates, I found that fetches containing such predicates returned an empty array. Ah, so that would be option A then I guess, if by "fail" we take it to be more "nothing matches the predicate." In which case, I guess it certainly would be quite a big change for Core Data to start handling transient attributes during fetches too. ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 2009 Apr 23, at 05:18, Mike Abdullah wrote: OK, so I'm trying to wrap my head around this. Let's say I build a predicate along the lines of: fooPersistent == 123 && fooTransient == 456 And then use it in a fetch request. Does Core Data: A) Pass that predicate straight to SQLite which fails because it can't find a fooTransient column. B) Pass that predicate straight to SQLite which ignores fooTransient (presumably treating it as always evaluating to true). C) Create a "fooPersistent == 123" predicate and pass that to SQLite. Or of course D) something I've failed to conceive of which seems quite probable! In my experience, before I read the documentation and learned not to put transient properties in my predicates, I found that fetches containing such predicates returned an empty array. ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 22 Apr 2009, at 22:34, Melissa J. Turner wrote: On Apr 22, 2009, at 02:12, Mike Abdullah wrote: On 22 Apr 2009, at 08:48, Ben Trumbull wrote: Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know Probably because nobody ever cared enough to file an enhancement request, and it didn't occur to us that writing 1 line of code to call filteredArrayWithPredicate was so troublesome. Calling -filteredArrayWithPredicate is no hassle, but for a large predicate, it has the bad performance of comparing a bunch of the persistent properties all over again, despite already knowing they'll match the predicate. Since I assume Core Data must do some kind of internal splitting up of the predicate in order to perform its fetch, I'd have thought it is in a good position to know what the remaining transient portion of the predicate is. You assume incorrectly. CoreData simply translates the predicate to SQL and passes it down to SQLite as a WHERE clause. Hence the lack of support for transient properties: SQLite has no idea what to do when you ask it to qualify by a column that doesn't exist in its schema. OK, so I'm trying to wrap my head around this. Let's say I build a predicate along the lines of: fooPersistent == 123 && fooTransient == 456 And then use it in a fetch request. Does Core Data: A) Pass that predicate straight to SQLite which fails because it can't find a fooTransient column. B) Pass that predicate straight to SQLite which ignores fooTransient (presumably treating it as always evaluating to true). C) Create a "fooPersistent == 123" predicate and pass that to SQLite. Or of course D) something I've failed to conceive of which seems quite probable! Regards, Mike. ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On Apr 22, 2009, at 02:12, Mike Abdullah wrote: On 22 Apr 2009, at 08:48, Ben Trumbull wrote: Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know Probably because nobody ever cared enough to file an enhancement request, and it didn't occur to us that writing 1 line of code to call filteredArrayWithPredicate was so troublesome. Calling -filteredArrayWithPredicate is no hassle, but for a large predicate, it has the bad performance of comparing a bunch of the persistent properties all over again, despite already knowing they'll match the predicate. Since I assume Core Data must do some kind of internal splitting up of the predicate in order to perform its fetch, I'd have thought it is in a good position to know what the remaining transient portion of the predicate is. You assume incorrectly. CoreData simply translates the predicate to SQL and passes it down to SQLite as a WHERE clause. Hence the lack of support for transient properties: SQLite has no idea what to do when you ask it to qualify by a column that doesn't exist in its schema. +Melissa ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 22 Apr 2009, at 08:48, Ben Trumbull wrote: Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know Probably because nobody ever cared enough to file an enhancement request, and it didn't occur to us that writing 1 line of code to call filteredArrayWithPredicate was so troublesome. Calling -filteredArrayWithPredicate is no hassle, but for a large predicate, it has the bad performance of comparing a bunch of the persistent properties all over again, despite already knowing they'll match the predicate. Since I assume Core Data must do some kind of internal splitting up of the predicate in order to perform its fetch, I'd have thought it is in a good position to know what the remaining transient portion of the predicate is. I haven't filed a radar I admit as this hadn't become a issue for me yet, but may well do. ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
The fact that Core Data "cannot fetch using a predicate based on transient properties" [1] seems to greatly limit the utility of the NSPredicateEditor view, and makes me very sad. Dear list. transient (adj): (1) passing especially quickly into and out of existence May I suggest that the expectation that Core Data should fetch based on criteria that DOES NOT EXIST in the file seems somewhat unrealistic ? However, enhancement requests are always welcome if you can articulate a coherent solution to the existential limitation. But there's an even better way. Upon further study of the Predicate Programming Guide, I find that there are even more limitations to Core Data fetches with predicates. The most troubling is that: "The Core Data SQL store supports only one to-many operation per query; therefore in any predicate sent to the SQL store, there may be only one operator (and one instance of that operator) from ALL, ANY, and IN." Do you have a specific scenario in which you need to perform nested to- many operations, yet you cannot use SUBQUERY or compound queries like OR ? Or is this troubling, in the sense that the universe is doomed to evaporate kind of way ? A much better way appears to be to fetch all objects from the store with no predicate and then use -[NSArray filteredArrayWithPredicate:]. This takes only one more line of code, solves all problems, and is supposedly cheaper too: This does not solve all problems, it most emphatically is NOT cheaper, and most assuredly does NOT scale. The atomic file approach is convenient and extremely simplistic. It also fails to scale gracefully past 10^2 objects. Optimizing memory management is very important for launch time and concurrency. The monster 8 core mac pro will be constrained by the memory bus (vastly slower compared to the sum computational power) if you're careless with memory usage. In addition to the memory bus bandwidth, concurrency is highly impacted by locality of reference. Keeping the voracious cpus fed with useful work is quite challenging for many pragmatic application tasks. Makes me wonder why NSFetchRequest even supports a predicate, since its predicate has all these limitations and is supposedly more expensive when compared to fetching all objects and then using - [NSArray filteredArrayWithPredicate:] ? ... If you redrew the entire window all the time, for each and every pixel change, and then marveled at the limitations, people might suggest clipping your drawing to the intersection of the dirty and visible regions. You might also use bounding rects as a convenient approximation of more complex region clipping calculations. These days even apps with modest requirements need bounding rects and region clipping for their data too. - Ben ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know Probably because nobody ever cared enough to file an enhancement request, and it didn't occur to us that writing 1 line of code to call filteredArrayWithPredicate was so troublesome. - Ben ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 2009 Apr 20, at 11:24, Jim Correia wrote: On Apr 20, 2009, at 2:02 PM, Jerry Krinock wrote: Makes me wonder why NSFetchRequest even supports a predicate, since its predicate has all these limitations and is supposedly more expensive when compared to fetching all objects and then using - [NSArray filteredArrayWithPredicate:] ? You are taking that quote out of context and misinterpreting it. Yes, you're correct about that; I was being sloppy there. However, I did my own experiment on this with about 1200 objects a few months ago, each object having about 2 dozen attributes and a couple of relationships. A couple hundred bytes in each record. I compared the time for a Core Data fetch-with-predicate versus Core Data fetch- without-predicate followed by array filtering. Apples versus apples. The latter was slightly faster. For others this may not be true -- "Always test performance in your own app" -- and now I understand why NSFetchRequest supports a predicate. But in my case the search completes in milliseconds, and not having to program around the limitations of Core Data's fetch-with- predicate is a huge advantage. On 2009 Apr 20, at 13:09, Sean McBride wrote: It strikes me that if one currently develops with with XML store, and then one day switches to the SQL store ... when one is in for lots of things suddenly breaking. Yup. I gleefully chucked that off my "list of things to retest" after I ditched the Core Data fetch-with-predicate. On 2009 Apr 20, at 11:23, Melissa Turner wrote: Doing filtering in memory is a code smell. It generally signals that you're fetching against the wrong entity, or that your model needs to be tweaked to be more efficient. Well, when I first started with Core Data, my religion was: "Oooo -- database -- relationships -- Oooo -- queries -- fast -- cool". But it doesn't always pan out. ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 4/20/09 11:02 AM, Jerry Krinock said: >But there's an even better way. Upon further study of the Predicate >Programming Guide, I find that there are even more limitations to Core >Data fetches with predicates. The most troubling is that: > >"The Core Data SQL store supports only one to-many operation per >query; therefore in any predicate sent to the SQL store, there may be >only one operator (and one instance of that operator) from ALL, ANY, >and IN." Anyone know of a way to catch such 'SQL-unfriendly' predicates at compile time? Or with a static analyser? It strikes me that if one currently develops with with XML store, and then one day switches to the SQL store (say when it becomes compatible with GC apps, grrr) when one is in for lots of things suddenly breaking. -- Sean McBride, B. Eng s...@rogue-research.com Rogue Researchwww.rogue-research.com Mac Software Developer Montréal, Québec, Canada ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On Apr 20, 2009, at 2:02 PM, Jerry Krinock wrote: A much better way appears to be to fetch all objects from the store with no predicate and then use -[NSArray filteredArrayWithPredicate:]. This takes only one more line of code, solves all problems, and is supposedly cheaper too: "If you use the Core Data framework, the array methods provide an efficient means of filtering an existing array of objects without —- as a fetch does —- requiring a round trip to a persistent data store." [...] Makes me wonder why NSFetchRequest even supports a predicate, since its predicate has all these limitations and is supposedly more expensive when compared to fetching all objects and then using - [NSArray filteredArrayWithPredicate:] ? You are taking that quote out of context and misinterpreting it. If you already have an array of NSManagedObjects (fully realized, no faults), then it is going to be faster to filter that array than it is to execute a fetch request with a predicate, which always round trips to the store. They key is "if you already have an array..." (Or a set.) If you don't, then fetching a limited set with a predicate is (usually) going to be considerably faster than fetching all objects, and reducing the result after the fact with a predicate. Consider what happens when you fetch all objects of a particular type. Now consider what happens if you can give Core Data a predicate which says "no, just these 3". Jim ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On Mon, April 20, 2009 11:02 am, Jerry Krinock wrote: > Makes me wonder why NSFetchRequest even supports a predicate, since > its predicate has all these limitations and is supposedly more > expensive when compared to fetching all objects and then using - > [NSArray filteredArrayWithPredicate:] ? It would have saved me a day > on the learning curve had it not been there for me to hang myself with. > filteredArrayWithPredicate: is only an option if you have a relatively small dataset. There's overhead to loading an object into memory, both in terms of memory and CPU cycles. Doing filtering in memory is a code smell. It generally signals that you're fetching against the wrong entity, or that your model needs to be tweaked to be more efficient. +Melissa ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On 2009 Apr 20, at 04:50, Jerry Krinock wrote: Problem solved But there's an even better way. Upon further study of the Predicate Programming Guide, I find that there are even more limitations to Core Data fetches with predicates. The most troubling is that: "The Core Data SQL store supports only one to-many operation per query; therefore in any predicate sent to the SQL store, there may be only one operator (and one instance of that operator) from ALL, ANY, and IN." A much better way appears to be to fetch all objects from the store with no predicate and then use -[NSArray filteredArrayWithPredicate:]. This takes only one more line of code, solves all problems, and is supposedly cheaper too: "If you use the Core Data framework, the array methods provide an efficient means of filtering an existing array of objects without —- as a fetch does —- requiring a round trip to a persistent data store." Furthermore, now since my left-side expressions don't need to be managed properties I don't need the categories -- I can just add simple derived-attribute getters to my target object class and predicate upon the derived attribute directly. So, I guess the reason why Apple has never noticed that "Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness" is because there's a better way to do it. Makes me wonder why NSFetchRequest even supports a predicate, since its predicate has all these limitations and is supposedly more expensive when compared to fetching all objects and then using - [NSArray filteredArrayWithPredicate:] ? It would have saved me a day on the learning curve had it not been there for me to hang myself with. ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
Problem solved. Although predicates cannot involve transient properties, "you can follow relationships in a predicate using a key path". Obj-C Categories to the rescue… For example, you can write a category on NSNumber containing a method - letterGrade. Then use this to create the leftExpression in the row template. Now everything works nicely, except you need to dig into the template after creating it, get the views and change the title of the menu item from "score.letterGrade" to something like "Letter Grade". But, in a real-life app, you need to do that for localization anyhow. On 2009 Apr 18, at 05:03, Mike Abdullah wrote: If it helps, the reason for Apple only supporting searching of persistent properties is for performance. If you're using the SQLite store for example, the predicate is not evaluated against the in- memory objects, but against the individual bits of data in the SQLite table. Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know… Yes, I figured something like that was going on but didn't want to get my hand slapped for trying to peek under Core Data's covers :) I also tried Keary's suggestion, and learned some stuff that may be useful to have in the list archives... On 2009 Apr 17, at 09:27, Keary Suska wrote: I am not really up to speed on NSPredicateEditor, but could you use - ruleEditor:predicatePartsForCriterion:withDisplayValue:inRow: to "convert" the display case of grade = A-F to a predicate that is actually grade >= <= score range? I imagine you would need to construct a compound predicate with subpredicates (sub-rows). Either that or use the "BETWEEN" operator. Good question. Long answer: The method you refer to is one of five delegate methods of the NSPredicate superclass NSRuleEditor, three of which the "delegate must implement". My guess is that implementing an NSPredicateEditor delegate is way to override the default row template generation. Might be what I need. However… • No documentation on how to implement a delegate. • Delegate seems to be ignored. I sent -setDelegate:self and echoed it back at several points. I implemented the three required methods, returning nil or 0. Expected result: Probably empty rule editors. Actual result: None of my delegate methods ever get invoked and everything still works as before. Echoing back -delegate returns self as expected. • Even if the delegate methods worked, I don't think I could implement them to return the required results. For example, ruleEditor:displayValueForCriterion:inRow: is supposed to return "The criterion for which the value is required". I know what a criterion is in English but to write code one needs something precise. No explanation in either this document or the Predicate Programming Guide. Oh, and the type of it is id :( One clue I can find is that -criteriaForRow returns "the same [items] as those returned from the delegate method ruleEditor:child:forCriterion:withRowType:. Aha -- so I send - criteriaForRow for each row up to -numberOfRows, log the results and get an array like this: 2009-04-19 17:22:45.521 TestApp[52864:10b] criteria for row 2: ( <_NSPredicateEditorItem: 0x15b71ce0 [Name]>, <_NSPredicateEditorItem: 0x15b6fbf0 [contains]>, <_NSPredicateEditorItem: 0x15b70e80 []> ) I can see what they're doing -- these are the three subviews in the template. But notice the underscore prefix on _NSPredicateEditorItem. Since I can't create those, I'd need a way to get this "default" answer and then tweak it, and I have no idea how to do either. Conclusion: Judging from these results and the lack of results in web searches, NSRuleEditor seems to be seldom used, NSPredicateEditor is rarely used, and probably delegate support in NSPredicateEditor is incomplete and unusable in Mac OS X 10.5. ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
If it helps, the reason for Apple only supporting searching of persistent properties is for performance. If you're using the SQLite store for example, the predicate is not evaluated against the in- memory objects, but against the individual bits of data in the SQLite table. Of course, why Apple couldn't have then added automatic support for in-memory matching as the second step I don't know… On 17 Apr 2009, at 04:01, Jerry Krinock wrote: The fact that Core Data "cannot fetch using a predicate based on transient properties" [1] seems to greatly limit the utility of the NSPredicateEditor view, and makes me very sad. For example, say that my objects are student test results with a 'score' attribute and two dozen other properties. I could give the user an NSPredicateEditor and let them have oodles of fun constructing complex predicates. But what if I need the user to be able to set a predicate with a left-side-expression of "letter grade" and a right-side-expression popup menu showing 'A' - 'F'. If I could fetch based on a transient 'letterGrade' attribute, I could implement some custom accessors which would calculate 'letterGrade' from 'score' as needed, the predicate emitted from the NSPredicateEditor would "just work", and life would be sweet. But since I can't use transient properties in my predicate, providing a popup like that in NSPredicateEditor seems to mean that I'm going to have to somehow deconstruct the compound predicate which Apple put so many man-years of engineering into, have Core Data do "sub-fetches", then do my own filtering and put the results back together. I fear that writing bug-free code to handle the general compound predicate would be very time-consuming, and also it would be MVC hell with my NSPredicateEditor subclass (view) code wanting to have model logic such as "if score > 93, letterGrade = 'A'". Does anyone have any suggestions for a "least worst" workaround? Thanks, Jerry [1] http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdFetching.html#/ /apple_ref/doc/uid/TP40002484 ___ 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/cocoadev%40mikeabdullah.net This email sent to cocoa...@mikeabdullah.net ___ 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 arch...@mail-archive.com
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
On Apr 16, 2009, at 9:01 PM, Jerry Krinock wrote: The fact that Core Data "cannot fetch using a predicate based on transient properties" [1] seems to greatly limit the utility of the NSPredicateEditor view, and makes me very sad. For example, say that my objects are student test results with a 'score' attribute and two dozen other properties. I could give the user an NSPredicateEditor and let them have oodles of fun constructing complex predicates. But what if I need the user to be able to set a predicate with a left-side-expression of "letter grade" and a right-side-expression popup menu showing 'A' - 'F'. If I could fetch based on a transient 'letterGrade' attribute, I could implement some custom accessors which would calculate 'letterGrade' from 'score' as needed, the predicate emitted from the NSPredicateEditor would "just work", and life would be sweet. But since I can't use transient properties in my predicate, providing a popup like that in NSPredicateEditor seems to mean that I'm going to have to somehow deconstruct the compound predicate which Apple put so many man-years of engineering into, have Core Data do "sub-fetches", then do my own filtering and put the results back together. I fear that writing bug-free code to handle the general compound predicate would be very time-consuming, and also it would be MVC hell with my NSPredicateEditor subclass (view) code wanting to have model logic such as "if score > 93, letterGrade = 'A'". I am not really up to speed on NSPredicateEditor, but could you use - ruleEditor:predicatePartsForCriterion:withDisplayValue:inRow: to "convert" the display case of grade = A-F to a predicate that is actually grade >= <= score range? I imagine you would need to construct a compound predicate with subpredicates (sub-rows). Either that or use the "BETWEEN" operator. HTH, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" ___ 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 arch...@mail-archive.com
Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
The fact that Core Data "cannot fetch using a predicate based on transient properties" [1] seems to greatly limit the utility of the NSPredicateEditor view, and makes me very sad. For example, say that my objects are student test results with a 'score' attribute and two dozen other properties. I could give the user an NSPredicateEditor and let them have oodles of fun constructing complex predicates. But what if I need the user to be able to set a predicate with a left- side-expression of "letter grade" and a right-side-expression popup menu showing 'A' - 'F'. If I could fetch based on a transient 'letterGrade' attribute, I could implement some custom accessors which would calculate 'letterGrade' from 'score' as needed, the predicate emitted from the NSPredicateEditor would "just work", and life would be sweet. But since I can't use transient properties in my predicate, providing a popup like that in NSPredicateEditor seems to mean that I'm going to have to somehow deconstruct the compound predicate which Apple put so many man-years of engineering into, have Core Data do "sub-fetches", then do my own filtering and put the results back together. I fear that writing bug-free code to handle the general compound predicate would be very time-consuming, and also it would be MVC hell with my NSPredicateEditor subclass (view) code wanting to have model logic such as "if score > 93, letterGrade = 'A'". Does anyone have any suggestions for a "least worst" workaround? Thanks, Jerry [1] http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/Articles/cdFetching.html#/ /apple_ref/doc/uid/TP40002484 ___ 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 arch...@mail-archive.com
Re: A question about NSPredicateEditor and NSPredicateEditorRowTemplate
On Mar 6, 2009, at 6:42 AM, David Hoerl wrote: [following up to a Jan 08 thread] > is it possible to modify the width of the NSTextField representing a "Number" in a NSPredicateEditorRowTemplate ? Yes, but not yet in Interface Builder. To do so programatically, get the row template, get the text field as the last member of the row template's templateViews array, and set its frame to the size you want. I hope that helps, -Peter Peter, I tried to do as you suggest - set the frames to what I want, but it has no effect. Any other suggestions? David PS: code -applicationDidFinishLaunching ... int i = 0; NSArray *temps = [predicateEditor rowTemplates]; for(NSPredicateEditorRowTemplate *temp in temps) { NSArray *views = [temp templateViews]; int j = 0; int x = 0; for(NSControl *view in views) { // I know, view is not a good name for this :-) NSLog(@"temp=%@ view=%@ frame: %@", temp, view, NSStringFromRect([view frame])); // verify all is connected if(i==0) continue; // don't touch first one NSRect r = [view frame]; r.origin.x = 0; // just for testing impact... [view setFrame:r]; NSLog(@" mod frame=%@", NSStringFromRect([view frame])); // yes, it took ++j; } ++i; } David, the above code changes the frame origin, but not the frame width. Changing the frame origin will have no effect (the origins are controlled by NSPredicateEditor). But changing the width should have an effect. -Peter ___ 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 arch...@mail-archive.com
Re: A question about NSPredicateEditor and NSPredicateEditorRowTemplate
[following up to a Jan 08 thread] > is it possible to modify the width of the NSTextField representing a "Number" in a NSPredicateEditorRowTemplate ? Yes, but not yet in Interface Builder. To do so programatically, get the row template, get the text field as the last member of the row template's templateViews array, and set its frame to the size you want. I hope that helps, -Peter Peter, I tried to do as you suggest - set the frames to what I want, but it has no effect. Any other suggestions? David PS: code -applicationDidFinishLaunching ... int i = 0; NSArray *temps = [predicateEditor rowTemplates]; for(NSPredicateEditorRowTemplate *temp in temps) { NSArray *views = [temp templateViews]; int j = 0; int x = 0; for(NSControl *view in views) { // I know, view is not a good name for this :-) NSLog(@"temp=%@ view=%@ frame: %@", temp, view, NSStringFromRect([view frame])); // verify all is connected if(i==0) continue; // don't touch first one NSRect r = [view frame]; r.origin.x = 0; // just for testing impact... [view setFrame:r]; NSLog(@" mod frame=%@", NSStringFromRect([view frame])); // yes, it took ++j; } ++i; } ___ 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 arch...@mail-archive.com
one more NSPredicateEditor question
Hello once again, just a quick question: It seems that predicate editor remains what right view was used for each operation. If I add a row with numeric parameter and two operators (less and greater) and then switch between them - predicate editor will "remember" value I entered for "less" and when I switch to "greater" it will show "it's" value. And vise versa. How to get rid of this? I want to keep the value I entered while switching between operators? Thank you. ___ 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 arch...@mail-archive.com
Re: Adding rows in NSPredicateEditor
On Jan 25, 2009, at 3:25 AM, Tom wrote: Hi everyone, I'm wondering if there is a way I can control which row template gets added when the user clicks the '+' button on an NSPredicateEditor. The template chosen seems to be random, but I want it to be a specific one for user convenience. Kind regards, Tom Hi Tom, Unfortunately there's no easy way to control this yet. Please file an enhancement request. Thanks! Note that the current algorithm is not random: it picks the first unused rule in a breadth-first search. -Peter ___ 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 arch...@mail-archive.com
Adding rows in NSPredicateEditor
Hi everyone, I'm wondering if there is a way I can control which row template gets added when the user clicks the '+' button on an NSPredicateEditor. The template chosen seems to be random, but I want it to be a specific one for user convenience. Kind regards, Tom ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor
On Jan 15, 2009, at 5:14 AM, Chris Idou wrote: Is it just me or does the "enabled" checkbox in IB for NSPredicateEditor, as well as the enabled bindings do nothing? enabled indeed does nothing yet. If you want to prevent the user from changing an NSPredicateEditor, you can use setEditable:NO. -Peter ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor
Well it doesn't do anything for me. And I downloaded PredicateEditorSample ( http://developer.apple.com/samplecode/PredicateEditorSample/index.html) and unchecked enabled for the PredicateEditor and it doesn't do anything. And I tried calling setEnabled:NO in awakeFromNib on the predicateEditor, and it didn't do anything. I am using 10.5.6. From: Volker in Lists To: Chris Idou Cc: cocoa-dev@lists.apple.com Sent: Friday, 16 January, 2009 12:42:10 AM Subject: Re: NSPredicateEditor Hi, works for me on 10.5.5 just as well as via code and calling the appropriate methods. At least that was my experience from before christmas. Want me to retry on 10.5.6? Volker Am 15.01.2009 um 14:14 schrieb Chris Idou: > > Is it just me or does the "enabled" checkbox in IB for NSPredicateEditor, as > well as the enabled bindings do nothing? > Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor
Hi, works for me on 10.5.5 just as well as via code and calling the appropriate methods. At least that was my experience from before christmas. Want me to retry on 10.5.6? Volker Am 15.01.2009 um 14:14 schrieb Chris Idou: Is it just me or does the "enabled" checkbox in IB for NSPredicateEditor, as well as the enabled bindings do nothing? ___ 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 arch...@mail-archive.com
NSPredicateEditor
Is it just me or does the "enabled" checkbox in IB for NSPredicateEditor, as well as the enabled bindings do nothing? Stay connected to the people that matter most with a smarter inbox. Take a look http://au.docs.yahoo.com/mail/smarterinbox ___ 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 arch...@mail-archive.com
NSPredicateEditor
Hello, I'm working on a small CoreData Document based application and wanted to include an NSPredicateEditor in a NSDrawer. But this failed for me because somehow the NSPredicateEditor is not drawn in the Drawer's Content View. From the PredicateEditorSample I found out that in this the delegate of the NSPredicateEditor in a NSWindowController instead of a NSDocument. I cross checked this also in some small test application and this seams to be the difference between my non-working application and a correctly working application. So I added a sub-class of the NSWindowController to my own application but still I have a problem: The NSPredicateEditor works fine if it is part of my NSWindow of my document based application. But it does not work if it the NSPredicateEditor is included in the ContentPane of the NSDrawer belonging to the same NSWindow. Can anybody give me a tip on the background of this issue? Why do I need a sub-class of the NSWindowController at all to get the NSPredicateEditor drawn correctly on the screen? How do both interact? Is there any documentation which I am lacking? Greetings and Thanx Eckart ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor and aggregate operations
I've got around it by implementing a kind of "man in the middle" subclass of NSPredicateEditorRowTemplate. I set the class of the row template to my subclass in IB and it automatically adds the "ANY" modifier to whatever is already configured. It removes the "ANY" modifier from the predicate before calling superclass function, and puts it back on the return values of super class functions. I've included the overridden functions below. It would be much easier if there was an option called "Predicate Modifier" in IB for row templates. -(NSComparisonPredicate*)copyPredicate: (NSComparisonPredicate*)aPredicate andChangeModifierTo: (NSComparisonPredicateModifier)aMod { NSComparisonPredicate* aCopy = nil; aCopy = (NSComparisonPredicate*)[NSComparisonPredicate predicateWithLeftExpression:[aPredicate leftExpression] rightExpression:[aPredicate rightExpression] modifier:aMod type:[aPredicate predicateOperatorType] options:[aPredicate options]]; return aCopy; } - (double)matchForPredicate:(NSPredicate *)predicate { //if the modifier is "ANY", then strip it off and pass it to super if([predicate isKindOfClass:[NSComparisonPredicate class]]){ NSComparisonPredicate* p = (NSComparisonPredicate*)predicate; if([p comparisonPredicateModifier] == NSAnyPredicateModifier){ return [super matchForPredicate:[self copyPredicate:p andChangeModifierTo:NSDirectPredicateModifier]]; } } //else, don't handle it return 0.0; } - (void)setPredicate:(NSPredicate *)predicate { //strip off "ANY" modifier and pass it to super NSComparisonPredicate* p = (NSComparisonPredicate*)predicate; [super setPredicate:[self copyPredicate:p andChangeModifierTo:NSDirectPredicateModifier]]; } - (NSPredicate *)predicateWithSubpredicates:(NSArray *)subpredicates { //add the "ANY" modifier back onto the predicate NSComparisonPredicate* ret = (NSComparisonPredicate*)[super predicateWithSubpredicates:subpredicates]; return [self copyPredicate:ret andChangeModifierTo:NSAnyPredicateModifier]; } ___ 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 arch...@mail-archive.com
NSPredicateEditor and aggregate operations
Hi everyone, I'm trying to implement a find window using an NSPredicateEditor, but can't get it to do aggregate operations like "ANY tags == 'some tag' ". As far as I can see, Interface Builder doesn't cater for aggregate operations like "ANY". I assume I have to subclass NSPrdicateEditorRowTemplate to do what I want, but I can't figure out how to subclass it properly based on the documentation. Is there a way to do it in IB? If not, are there any examples or tutorials regarding subclassing NSPredicateEditorRowTemplate? I can't find anything in google. Kind Regards, Tom Dalling ___ 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 arch...@mail-archive.com
Re: NSPredicateEditor and date comparisons
I think you're better off writing a custom Date compare function, and customising the NSPredicateEditor to return a predicate using the function, so that you can guarantee that date comparison happens the way you want. I guess you *could* control the date passed into the predicate to normalise the date to midday or something, but then if you later added some predicate terms that used the time, that wouldn't work, do it would be a bit of a kludge. --- On Sun, 7/12/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> > Subject: Re: NSPredicateEditor and date comparisons > To: cocoa-dev@lists.apple.com > Received: Sunday, 7 December, 2008, 6:16 PM > I remember, way long ago in the past, having to supply a > time component to go with a date component - otherwise some > seemingly "random" time was inserted which then > threw off anything else I did. If I only needed a date > (from a datetime field), I had to format it that way (as > only a date, and in the format I needed) and do some > seemingly-odd comparison (like comparing two strings). It > worked, so I didn't care past that point. > > Quoting Chris Idou <[EMAIL PROTECTED]>: > > > > > Would your time zone happen to somehow correspond to > 8:00 ? > > > > Try doing a setDateValue on the gui component before > you start, with a particular time. I've got a suspicion > that it will then leave the time component alone. When you > got a result of 13:41:40, might that have been the time you > ran the program? > > > > > > --- On Sun, 7/12/08, Josh Abernathy > <[EMAIL PROTECTED]> wrote: > > > >> From: Josh Abernathy <[EMAIL PROTECTED]> > >> Subject: Re: NSPredicateEditor and date > comparisons > >> To: [EMAIL PROTECTED] > >> Cc: "Cocoa-Dev List" > > >> Received: Sunday, 7 December, 2008, 5:00 PM > >> Ah, yes, that would be the more accurate way to > explain it. > >> I have an NSDatePicker in my NSPredicateEditor and > no funny > >> business is going on with conversions. It's > just the > >> simple default, setup-in-IB usage. > >> > >> So I guess the question is better put: is there > any > >> guarantee about the time of an NSDatePicker in an > >> NSPredicateEditor? > >> > >> I created a quick test of an NSDatePicker outside > an > >> NSPredicateEditor and its default time seems to be > 8:00:00. > >> > >> On Dec 7, 2008, at 5:57 PM, Chris Idou wrote: > >> > >> > > >> > I'm a bit confused by your post. > NSPredicateEditor > >> doesn't compare any dates, it just creates > NSPredicates. > >> Maybe you're saying that if you have a > NSDatePicker in > >> your NSPredicateEditor, that it creates a > predicate with a > >> date set to 13:41:40. If that's the case, then > it > >> probably has more to do with the NSDatePicker than > >> predicates. Unless you're converting the > predicate to a > >> string, which introduces more complications. > >> NSPredicateEditor tends to just call objectValue > on the gui > >> component, so try calling that yourself on your > NSDatePicker > >> and see what happens. > >> > > >> > --- On Sun, 7/12/08, Josh Abernathy > >> <[EMAIL PROTECTED]> wrote: > >> > > >> >> From: Josh Abernathy > <[EMAIL PROTECTED]> > >> >> Subject: NSPredicateEditor and date > comparisons > >> >> To: "Cocoa-Dev List" > >> > >> >> Received: Sunday, 7 December, 2008, 11:14 > AM > >> >> Hi all, > >> >> > >> >> In my application, users have the option > of > >> comparing to a > >> >> date in an NSPredicateEditor. For the > NSDates it > >> is > >> >> comparing against, only the date is > important; > >> time > >> >> doesn't matter. > >> >> > >> >> The interesting thing I found about > >> NSPredicateEditor is > >> >> the NSTimeInterval it compares my NSDates > to has > >> the time > >> >> set to 13:41:40. That means my NSDates > with the > >> default > >> >> 12:00:00 time don't match an > "is" > >> predicate. > >> >> It's not a big deal because I can > just change > >> my > >> >> NSDate's time to 13:41:40 to fix the &g
Re: NSPredicateEditor and date comparisons
I remember, way long ago in the past, having to supply a time component to go with a date component - otherwise some seemingly "random" time was inserted which then threw off anything else I did. If I only needed a date (from a datetime field), I had to format it that way (as only a date, and in the format I needed) and do some seemingly-odd comparison (like comparing two strings). It worked, so I didn't care past that point. Quoting Chris Idou <[EMAIL PROTECTED]>: Would your time zone happen to somehow correspond to 8:00 ? Try doing a setDateValue on the gui component before you start, with a particular time. I've got a suspicion that it will then leave the time component alone. When you got a result of 13:41:40, might that have been the time you ran the program? --- On Sun, 7/12/08, Josh Abernathy <[EMAIL PROTECTED]> wrote: From: Josh Abernathy <[EMAIL PROTECTED]> Subject: Re: NSPredicateEditor and date comparisons To: [EMAIL PROTECTED] Cc: "Cocoa-Dev List" Received: Sunday, 7 December, 2008, 5:00 PM Ah, yes, that would be the more accurate way to explain it. I have an NSDatePicker in my NSPredicateEditor and no funny business is going on with conversions. It's just the simple default, setup-in-IB usage. So I guess the question is better put: is there any guarantee about the time of an NSDatePicker in an NSPredicateEditor? I created a quick test of an NSDatePicker outside an NSPredicateEditor and its default time seems to be 8:00:00. On Dec 7, 2008, at 5:57 PM, Chris Idou wrote: > > I'm a bit confused by your post. NSPredicateEditor doesn't compare any dates, it just creates NSPredicates. Maybe you're saying that if you have a NSDatePicker in your NSPredicateEditor, that it creates a predicate with a date set to 13:41:40. If that's the case, then it probably has more to do with the NSDatePicker than predicates. Unless you're converting the predicate to a string, which introduces more complications. NSPredicateEditor tends to just call objectValue on the gui component, so try calling that yourself on your NSDatePicker and see what happens. > > --- On Sun, 7/12/08, Josh Abernathy <[EMAIL PROTECTED]> wrote: > >> From: Josh Abernathy <[EMAIL PROTECTED]> >> Subject: NSPredicateEditor and date comparisons >> To: "Cocoa-Dev List" >> Received: Sunday, 7 December, 2008, 11:14 AM >> Hi all, >> >> In my application, users have the option of comparing to a >> date in an NSPredicateEditor. For the NSDates it is >> comparing against, only the date is important; time >> doesn't matter. >> >> The interesting thing I found about NSPredicateEditor is >> the NSTimeInterval it compares my NSDates to has the time >> set to 13:41:40. That means my NSDates with the default >> 12:00:00 time don't match an "is" predicate. >> It's not a big deal because I can just change my >> NSDate's time to 13:41:40 to fix the problem. >> >> But what I'm wondering is if this is guaranteed to >> always be true. I couldn't find it anywhere in the >> documentation. >> >> Thanks, >> Josh >> ___ >> >> 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/idou747%40yahoo.com >> >> This email sent to [EMAIL PROTECTED] > > > Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline ___ 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/jmunson%40his.com This email sent to [EMAIL PROTECTED] ___ 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]
Re: NSPredicateEditor and date comparisons
Would your time zone happen to somehow correspond to 8:00 ? Try doing a setDateValue on the gui component before you start, with a particular time. I've got a suspicion that it will then leave the time component alone. When you got a result of 13:41:40, might that have been the time you ran the program? --- On Sun, 7/12/08, Josh Abernathy <[EMAIL PROTECTED]> wrote: > From: Josh Abernathy <[EMAIL PROTECTED]> > Subject: Re: NSPredicateEditor and date comparisons > To: [EMAIL PROTECTED] > Cc: "Cocoa-Dev List" > Received: Sunday, 7 December, 2008, 5:00 PM > Ah, yes, that would be the more accurate way to explain it. > I have an NSDatePicker in my NSPredicateEditor and no funny > business is going on with conversions. It's just the > simple default, setup-in-IB usage. > > So I guess the question is better put: is there any > guarantee about the time of an NSDatePicker in an > NSPredicateEditor? > > I created a quick test of an NSDatePicker outside an > NSPredicateEditor and its default time seems to be 8:00:00. > > On Dec 7, 2008, at 5:57 PM, Chris Idou wrote: > > > > > I'm a bit confused by your post. NSPredicateEditor > doesn't compare any dates, it just creates NSPredicates. > Maybe you're saying that if you have a NSDatePicker in > your NSPredicateEditor, that it creates a predicate with a > date set to 13:41:40. If that's the case, then it > probably has more to do with the NSDatePicker than > predicates. Unless you're converting the predicate to a > string, which introduces more complications. > NSPredicateEditor tends to just call objectValue on the gui > component, so try calling that yourself on your NSDatePicker > and see what happens. > > > > --- On Sun, 7/12/08, Josh Abernathy > <[EMAIL PROTECTED]> wrote: > > > >> From: Josh Abernathy <[EMAIL PROTECTED]> > >> Subject: NSPredicateEditor and date comparisons > >> To: "Cocoa-Dev List" > > >> Received: Sunday, 7 December, 2008, 11:14 AM > >> Hi all, > >> > >> In my application, users have the option of > comparing to a > >> date in an NSPredicateEditor. For the NSDates it > is > >> comparing against, only the date is important; > time > >> doesn't matter. > >> > >> The interesting thing I found about > NSPredicateEditor is > >> the NSTimeInterval it compares my NSDates to has > the time > >> set to 13:41:40. That means my NSDates with the > default > >> 12:00:00 time don't match an "is" > predicate. > >> It's not a big deal because I can just change > my > >> NSDate's time to 13:41:40 to fix the problem. > >> > >> But what I'm wondering is if this is > guaranteed to > >> always be true. I couldn't find it anywhere in > the > >> documentation. > >> > >> Thanks, > >> Josh > >> ___ > >> > >> 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/idou747%40yahoo.com > >> > >> This email sent to [EMAIL PROTECTED] > > > > > > Start your day with Yahoo!7 and win a Sony Bravia > TV. Enter now > http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline ___ 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]
Re: NSPredicateEditor and date comparisons
Ah, yes, that would be the more accurate way to explain it. I have an NSDatePicker in my NSPredicateEditor and no funny business is going on with conversions. It's just the simple default, setup-in-IB usage. So I guess the question is better put: is there any guarantee about the time of an NSDatePicker in an NSPredicateEditor? I created a quick test of an NSDatePicker outside an NSPredicateEditor and its default time seems to be 8:00:00. On Dec 7, 2008, at 5:57 PM, Chris Idou wrote: I'm a bit confused by your post. NSPredicateEditor doesn't compare any dates, it just creates NSPredicates. Maybe you're saying that if you have a NSDatePicker in your NSPredicateEditor, that it creates a predicate with a date set to 13:41:40. If that's the case, then it probably has more to do with the NSDatePicker than predicates. Unless you're converting the predicate to a string, which introduces more complications. NSPredicateEditor tends to just call objectValue on the gui component, so try calling that yourself on your NSDatePicker and see what happens. --- On Sun, 7/12/08, Josh Abernathy <[EMAIL PROTECTED]> wrote: From: Josh Abernathy <[EMAIL PROTECTED]> Subject: NSPredicateEditor and date comparisons To: "Cocoa-Dev List" Received: Sunday, 7 December, 2008, 11:14 AM Hi all, In my application, users have the option of comparing to a date in an NSPredicateEditor. For the NSDates it is comparing against, only the date is important; time doesn't matter. The interesting thing I found about NSPredicateEditor is the NSTimeInterval it compares my NSDates to has the time set to 13:41:40. That means my NSDates with the default 12:00:00 time don't match an "is" predicate. It's not a big deal because I can just change my NSDate's time to 13:41:40 to fix the problem. But what I'm wondering is if this is guaranteed to always be true. I couldn't find it anywhere in the documentation. Thanks, Josh ___ 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/idou747%40yahoo.com This email sent to [EMAIL PROTECTED] Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline ___ 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]
Re: NSPredicateEditor and date comparisons
I'm a bit confused by your post. NSPredicateEditor doesn't compare any dates, it just creates NSPredicates. Maybe you're saying that if you have a NSDatePicker in your NSPredicateEditor, that it creates a predicate with a date set to 13:41:40. If that's the case, then it probably has more to do with the NSDatePicker than predicates. Unless you're converting the predicate to a string, which introduces more complications. NSPredicateEditor tends to just call objectValue on the gui component, so try calling that yourself on your NSDatePicker and see what happens. --- On Sun, 7/12/08, Josh Abernathy <[EMAIL PROTECTED]> wrote: > From: Josh Abernathy <[EMAIL PROTECTED]> > Subject: NSPredicateEditor and date comparisons > To: "Cocoa-Dev List" > Received: Sunday, 7 December, 2008, 11:14 AM > Hi all, > > In my application, users have the option of comparing to a > date in an NSPredicateEditor. For the NSDates it is > comparing against, only the date is important; time > doesn't matter. > > The interesting thing I found about NSPredicateEditor is > the NSTimeInterval it compares my NSDates to has the time > set to 13:41:40. That means my NSDates with the default > 12:00:00 time don't match an "is" predicate. > It's not a big deal because I can just change my > NSDate's time to 13:41:40 to fix the problem. > > But what I'm wondering is if this is guaranteed to > always be true. I couldn't find it anywhere in the > documentation. > > Thanks, > Josh > ___ > > 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/idou747%40yahoo.com > > This email sent to [EMAIL PROTECTED] Start your day with Yahoo!7 and win a Sony Bravia TV. Enter now http://au.docs.yahoo.com/homepageset/?p1=other&p2=au&p3=tagline ___ 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]
NSPredicateEditor and date comparisons
Hi all, In my application, users have the option of comparing to a date in an NSPredicateEditor. For the NSDates it is comparing against, only the date is important; time doesn't matter. The interesting thing I found about NSPredicateEditor is the NSTimeInterval it compares my NSDates to has the time set to 13:41:40. That means my NSDates with the default 12:00:00 time don't match an "is" predicate. It's not a big deal because I can just change my NSDate's time to 13:41:40 to fix the problem. But what I'm wondering is if this is guaranteed to always be true. I couldn't find it anywhere in the documentation. Thanks, Josh ___ 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]
NSPredicateEditor and date comparisons
Hi all, In my application, users have the option of comparing to a date in an NSPredicateEditor. For the NSDates it is comparing against, only the date is important; time doesn't matter. The interesting thing I found about NSPredicateEditor is the NSTimeInterval it compares my NSDates to has the time set to 13:41:40. That means my NSDates with the default 12:00:00 time don't match an "is" predicate. It's not a big deal because I can just change my NSDate's time to 13:41:40 to fix the problem. But what I'm wondering is if this is guaranteed to always be true. I couldn't find it anywhere in the documentation. Thanks, Josh ___ 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]
Re: NSPredicateEditor not updating scrollbar
On 4 Nov 2008, at 3:38 pm, Guy Umbright wrote: I have an NSPredicateEditor in an NSTabView. But when I add enough predicate items to the point where the vertical scrollbar should appear, it does not. My question is am I wrong to expect it to handle the scrollbar or am I missing something obvious? Is the NSPredicateEditor embedded in a NSScrollView? --Graham ___ 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]
NSPredicateEditor not updating scrollbar
I have an NSPredicateEditor in an NSTabView. But when I add enough predicate items to the point where the vertical scrollbar should appear, it does not. My question is am I wrong to expect it to handle the scrollbar or am I missing something obvious? Thanks Guy Umbright ___ 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]
Re: NSPredicateEditor
On Nov 2, 2008, at 9:09 PM, Chris Idou wrote: Has anyone been able to add menu items to the first popup while it is running? Or are you pretty much stuck with whatever the initial values were? I've tried various things and haven't been able to do it. If you want to change the items available in a popup, you should create a new NSPredicateEdtorRowTemplate whose popups contain the items you want, and then add it to the NSPredicateEditor with setRowTemplates:. -Peter ___ 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]
NSPredicateEditor
Has anyone been able to add menu items to the first popup while it is running? Or are you pretty much stuck with whatever the initial values were? I've tried various things and haven't been able to do it. ___ 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]
Re: NSRuleEditor/NSPredicateEditor selected rows
On Oct 31, 2008, at 12:17 AM, Houdah - ML Pierre Bernard wrote: Hi! NSRuleEditor has the concept of selected rows in its API. I however see no visual clues of which rows are selected. Is it possible to subclass whatever cell view is used by the rule editor to add such a visual clue? Pierre Selected rows turned out to be confusing for users, so we removed it from the art but didn't get around to updating the API. We may add selection again in the future, but for now you shouldn't depend on it. ___ 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]
NSRuleEditor/NSPredicateEditor selected rows
Hi! NSRuleEditor has the concept of selected rows in its API. I however see no visual clues of which rows are selected. Is it possible to subclass whatever cell view is used by the rule editor to add such a visual clue? Pierre ___ 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]
Re: Getting localized NSPredicateEditor
On Oct 28, 2008, at 3:57 PM, Peter Ammon wrote: Here's something that may help - there's a method on NSRuleEditor: - (NSData *)_generateFormattingDictionaryStringsFile. It gives you a strings file (as UTF16 data) appropriate for that control - write the data to a .strings file and then you can start translating it. That method should never be called in production code but it can be useful for generating the strings file. Excellent, that saves a lot of error prone work - I have more than 180 such sentences. Thanks again! Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ 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]
Re: Getting localized NSPredicateEditor
On Oct 28, 2008, at 3:33 PM, Markus Spoettl wrote: Hi Peter, Let me know if you have any questions, I do! I tried to localize the All/Any/None sentence for the German localization. When I do this I get an exception and the following console log: 10/28/08 3:20:54 PM myApp[43721] Error parsing localization! Key: %d %@ Value: %1$d %2$@ Error is: The maximum given order was 2, but nothing has order 1. My guess is that you're using the same strings file for this and other uses. The %[...]@ syntax is unique to NSRuleEditor/NSPredicateEditor and so it needs its own strings file. %d should never appear in one of these strings. Here's something that may help - there's a method on NSRuleEditor: - (NSData *)_generateFormattingDictionaryStringsFile. It gives you a strings file (as UTF16 data) appropriate for that control - write the data to a .strings file and then you can start translating it. That method should never be called in production code but it can be useful for generating the strings file. The localization part looks like this: "%[Any]@ of the following are true" = "%[Eine]@ der folgenden Bedingungen treffen zu"; "%[All]@ of the following are true" = "%[Alle]@ der folgenden Bedingungen treffen zu"; "%[None]@ of the following are true" = "%[Keine]@ der folgenden Bedingungen treffen zu"; I've set the predicate editor's formattingStringsFilename in - awakeFromNib and implemented - (NSDictionary *)ruleEditor:(NSPredicateEditor *)editor predicatePartsForCriterion:(id)criterion withDisplayValue:(id)value inRow:(NSInteger)row { NSMutableDictionary *result = [NSMutableDictionary dictionary]; if ([value isKindOfClass:[NSString class]]) { if ([value isEqual:@"Any"]) [result setObject:[NSNumber numberWithInt:NSOrPredicateType] forKey:NSRuleEditorPredicateCompoundType]; else if ([value isEqual:@"All"]) [result setObject:[NSNumber numberWithInt:NSAndPredicateType] forKey:NSRuleEditorPredicateCompoundType]; else if ([value isEqual:@"None"]) [result setObject:[NSNumber numberWithInt:NSNotPredicateType] forKey:NSRuleEditorPredicateCompoundType]; } return result; } which never gets called (probably because it's a NSPredicateEditor and as such does not use delegate methods?). Right, those delegate methods are not used for NSPredicateEditor. All that's necessary for localization is to set the strings file. -Peter ___ 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]
Re: Getting localized NSPredicateEditor
Hi Peter, On Oct 28, 2008, at 3:33 PM, Markus Spoettl wrote: 10/28/08 3:20:54 PM myApp[43721] Error parsing localization! Key: %d %@ Value: %1$d %2$@ Error is: The maximum given order was 2, but nothing has order 1. The localization part looks like this: Never mind the previous mail. I put the localization in its own file and it works. I had it in Localizable.strings with tons of other stuff in it and apparently the system does expect it to be on its own. Time for some more experimenting, thanks very much for the quick help! Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ 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]
Re: Getting localized NSPredicateEditor
Hi Peter, On Oct 28, 2008, at 2:10 PM, Peter Ammon wrote: Apple does not provide any translations of the operator names or criteria. This is because NSPredicateEditor is designed to be localized with sentence granularity, not word by word. Translating each word independently and piecing them together doesn't produce as good a localization. For example, in Finder, you can search for "[Last modified date] is [within last] [5] [weeks]". That whole sentence is what gets localized - it appears in a strings file in Finder's bundle - and there can be a separate localization for each possible sentence. There's an example of a NSRuleEditor localized into Spanish at http://homepage.mac.com/gershwin/NibBasedSpotlightSearcher.zip (NSPredicateEditor's localization is identical). Also see NSNavRuleEditor.strings inside AppKit.framework/*.lproj for how the search in the Open panel gets localized. OK, thanks very much! That's very interesting, I would have never figured that out from the documentation, and it appears my googling skills are very bad. Of course, you can localize each word independently if you prefer, with the usual mechanism - set the title of each menu item in each popup to the translation you want. In my case it might even work but I'd love to give this mechanism a try but... Let me know if you have any questions, I do! I tried to localize the All/Any/None sentence for the German localization. When I do this I get an exception and the following console log: 10/28/08 3:20:54 PM myApp[43721] Error parsing localization! Key: %d %@ Value: %1$d %2$@ Error is: The maximum given order was 2, but nothing has order 1. The localization part looks like this: "%[Any]@ of the following are true" = "%[Eine]@ der folgenden Bedingungen treffen zu"; "%[All]@ of the following are true" = "%[Alle]@ der folgenden Bedingungen treffen zu"; "%[None]@ of the following are true" = "%[Keine]@ der folgenden Bedingungen treffen zu"; I've set the predicate editor's formattingStringsFilename in - awakeFromNib and implemented - (NSDictionary *)ruleEditor:(NSPredicateEditor *)editor predicatePartsForCriterion:(id)criterion withDisplayValue:(id)value inRow:(NSInteger)row { NSMutableDictionary *result = [NSMutableDictionary dictionary]; if ([value isKindOfClass:[NSString class]]) { if ([value isEqual:@"Any"]) [result setObject:[NSNumber numberWithInt:NSOrPredicateType] forKey:NSRuleEditorPredicateCompoundType]; else if ([value isEqual:@"All"]) [result setObject:[NSNumber numberWithInt:NSAndPredicateType] forKey:NSRuleEditorPredicateCompoundType]; else if ([value isEqual:@"None"]) [result setObject:[NSNumber numberWithInt:NSNotPredicateType] forKey:NSRuleEditorPredicateCompoundType]; } return result; } which never gets called (probably because it's a NSPredicateEditor and as such does not use delegate methods?). Any idea what I'm doing wrong? Thanks very much for your help! Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ 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]
Re: NSPredicateEditor error
Yes, I thought I had an NSButton, but it turned out I'd wrongly put in a NSPopupButton. --- On Tue, 10/28/08, Peter Ammon <[EMAIL PROTECTED]> wrote: > From: Peter Ammon <[EMAIL PROTECTED]> > Subject: Re: NSPredicateEditor error > To: [EMAIL PROTECTED] > Cc: cocoa-dev@lists.apple.com > Date: Tuesday, October 28, 2008, 11:41 AM > On Oct 27, 2008, at 10:07 PM, Chris Idou wrote: > > > > > I'm getting the following error: > > > > In , different > number of items (3) > > than predicate template views (4) for template > > 0x12487e0: [move:] [] NSStringAttributeType> > > > >> From experimenting, the only difference between > the > >> NSPredicateEditorRowTemplate that is failing and > my other ones that > >> work fine, is that this one has a NSButton in its > list of views. > > > > Has anyone else seen this before, and have any > insight? > > One reason for this message (which could be a lot clearer) > is that > templateViews contains a NSPopUpButtonwith no items. > NSPredicateEditor doesn't support empty popup buttons > yet. Does that > help? > > -Peter ___ 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]
Re: Getting localized NSPredicateEditor
On Oct 28, 2008, at 1:12 PM, Markus Spoettl wrote: Hello List, is there a way to make NSPredicateEditor play nice with localized versions of an application, meaning that it's rule operators and criteria are translated to the language the rest of the application is using? Right now it appears that NSPredicateEditor uses English operator names (and compound criteria descriptions), regardless of which language is used. Regards Markus Hi Markus, Apple does not provide any translations of the operator names or criteria. This is because NSPredicateEditor is designed to be localized with sentence granularity, not word by word. Translating each word independently and piecing them together doesn't produce as good a localization. For example, in Finder, you can search for "[Last modified date] is [within last] [5] [weeks]". That whole sentence is what gets localized - it appears in a strings file in Finder's bundle - and there can be a separate localization for each possible sentence. There's an example of a NSRuleEditor localized into Spanish at http://homepage.mac.com/gershwin/NibBasedSpotlightSearcher.zip (NSPredicateEditor's localization is identical). Also see NSNavRuleEditor.strings inside AppKit.framework/*.lproj for how the search in the Open panel gets localized. Of course, you can localize each word independently if you prefer, with the usual mechanism - set the title of each menu item in each popup to the translation you want. Let me know if you have any questions, -Peter ___ 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]
Getting localized NSPredicateEditor
Hello List, is there a way to make NSPredicateEditor play nice with localized versions of an application, meaning that it's rule operators and criteria are translated to the language the rest of the application is using? Right now it appears that NSPredicateEditor uses English operator names (and compound criteria descriptions), regardless of which language is used. Regards Markus -- __ Markus Spoettl smime.p7s Description: S/MIME cryptographic signature ___ 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]
Re: NSPredicateEditor error
On Oct 27, 2008, at 10:07 PM, Chris Idou wrote: I'm getting the following error: In , different number of items (3) than predicate template views (4) for template 0x12487e0: [move:] [] NSStringAttributeType> From experimenting, the only difference between the NSPredicateEditorRowTemplate that is failing and my other ones that work fine, is that this one has a NSButton in its list of views. Has anyone else seen this before, and have any insight? One reason for this message (which could be a lot clearer) is that templateViews contains a NSPopUpButtonwith no items. NSPredicateEditor doesn't support empty popup buttons yet. Does that help? -Peter ___ 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]
NSPredicateEditor error
I'm getting the following error: In , different number of items (3) than predicate template views (4) for template >From experimenting, the only difference between the >NSPredicateEditorRowTemplate that is failing and my other ones that work fine, >is that this one has a NSButton in its list of views. Has anyone else seen this before, and have any insight? ___ 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]
Re: NSPredicateEditor - row size
On Oct 27, 2008, at 11:28 AM, Peter Ammon wrote: On Oct 25, 2008, at 4:07 AM, Chris Idou wrote: Has anyone found a way to make a row in the NSPredicateEditor to have components taller than the standard height or a more complicated arrangement of components, or are you pretty much limited to one row of buttons, and text fields and similar sized components? Programs like Hazel are able to vary the height of rows at will, however it doesn't use the real NSPredicateEditor, it seems to simulate something similar with a table or something. You can insert by returning it within an override of templateViews. There's no support for multiple rows of different height though. -Peter I meant to write "You can insert a custom view by returning it within an override of templateViews," but there's no support for multiple rows of different height. ___ 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]
Re: NSPredicateEditor - row size
On Oct 25, 2008, at 4:07 AM, Chris Idou wrote: Has anyone found a way to make a row in the NSPredicateEditor to have components taller than the standard height or a more complicated arrangement of components, or are you pretty much limited to one row of buttons, and text fields and similar sized components? Programs like Hazel are able to vary the height of rows at will, however it doesn't use the real NSPredicateEditor, it seems to simulate something similar with a table or something. You can insert by returning it within an override of templateViews. There's no support for multiple rows of different height though. -Peter ___ 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]
NSPredicateEditor - row size
Has anyone found a way to make a row in the NSPredicateEditor to have components taller than the standard height or a more complicated arrangement of components, or are you pretty much limited to one row of buttons, and text fields and similar sized components? Programs like Hazel are able to vary the height of rows at will, however it doesn't use the real NSPredicateEditor, it seems to simulate something similar with a table or something. ___ 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]
Re: NsPredicateEditor
I think you can also call setCanRemoveAllRows:NO to prevent the editor from deleting the last (compound predicate) row. -barry On Sun, Sep 21, 2008 at 4:24 PM, Chris Idou <[EMAIL PROTECTED]> wrote: > > There's one or two demo apps on the apple site. I think it's called > PredicateEditorSample. If the editor is totally empty on start you may have > to initialise it with an empty NSCompoundPredicate so that you can at least > see the add button. > > You can also search the archives for some tips. > > --- On Thu, 9/18/08, Sandro Noel <[EMAIL PROTECTED]> wrote: > >> From: Sandro Noel <[EMAIL PROTECTED]> >> Subject: NsPredicateEditor >> To: "cocoa-dev Users" >> Date: Thursday, September 18, 2008, 10:12 PM >> Greetings. >> >> I would like to use NSPredicateEditor to build a filtering >> string to >> filter out items from an array. >> but i cant seem to find a tutorial on the matter, and the >> cocoa >> documentation gets me lost, there is not enough information >> in there >> for me to really grasp what i should do to make it work, it >> must be >> one of those " it's so simple it's complicated >> to understand" >> >> would someone be so kind to explain how i can achieve this. >> >> in the interface builder i have a NSPredicateEditor >> I edited the templates that are in place in the designer, >> I created an outlet for it in my controller and connected >> them together. >> but when I run the application the editor is empty. >> >> then once he predicate is running i want to compare every >> tiems in my >> array with it, and delete from the array the items that do >> not match. >> >> thank you so much. >> >> Sandro. >> ___ >> >> 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/idou747%40yahoo.com >> >> This email sent to [EMAIL PROTECTED] > > > > ___ > > 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/barrywark%40gmail.com > > This email sent to [EMAIL PROTECTED] > ___ 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]
Re: NsPredicateEditor
Thank you, that did it!!! Sandro. On 21-Sep-08, at 7:24 PM, Chris Idou wrote: There's one or two demo apps on the apple site. I think it's called PredicateEditorSample. If the editor is totally empty on start you may have to initialise it with an empty NSCompoundPredicate so that you can at least see the add button. You can also search the archives for some tips. --- On Thu, 9/18/08, Sandro Noel <[EMAIL PROTECTED]> wrote: From: Sandro Noel <[EMAIL PROTECTED]> Subject: NsPredicateEditor To: "cocoa-dev Users" Date: Thursday, September 18, 2008, 10:12 PM Greetings. I would like to use NSPredicateEditor to build a filtering string to filter out items from an array. but i cant seem to find a tutorial on the matter, and the cocoa documentation gets me lost, there is not enough information in there for me to really grasp what i should do to make it work, it must be one of those " it's so simple it's complicated to understand" would someone be so kind to explain how i can achieve this. in the interface builder i have a NSPredicateEditor I edited the templates that are in place in the designer, I created an outlet for it in my controller and connected them together. but when I run the application the editor is empty. then once he predicate is running i want to compare every tiems in my array with it, and delete from the array the items that do not match. thank you so much. Sandro. ___ 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/idou747%40yahoo.com This email sent to [EMAIL PROTECTED] ___ 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]
Re: NsPredicateEditor
There's one or two demo apps on the apple site. I think it's called PredicateEditorSample. If the editor is totally empty on start you may have to initialise it with an empty NSCompoundPredicate so that you can at least see the add button. You can also search the archives for some tips. --- On Thu, 9/18/08, Sandro Noel <[EMAIL PROTECTED]> wrote: > From: Sandro Noel <[EMAIL PROTECTED]> > Subject: NsPredicateEditor > To: "cocoa-dev Users" > Date: Thursday, September 18, 2008, 10:12 PM > Greetings. > > I would like to use NSPredicateEditor to build a filtering > string to > filter out items from an array. > but i cant seem to find a tutorial on the matter, and the > cocoa > documentation gets me lost, there is not enough information > in there > for me to really grasp what i should do to make it work, it > must be > one of those " it's so simple it's complicated > to understand" > > would someone be so kind to explain how i can achieve this. > > in the interface builder i have a NSPredicateEditor > I edited the templates that are in place in the designer, > I created an outlet for it in my controller and connected > them together. > but when I run the application the editor is empty. > > then once he predicate is running i want to compare every > tiems in my > array with it, and delete from the array the items that do > not match. > > thank you so much. > > Sandro. > ___ > > 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/idou747%40yahoo.com > > This email sent to [EMAIL PROTECTED] ___ 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]
NsPredicateEditor
Greetings. I would like to use NSPredicateEditor to build a filtering string to filter out items from an array. but i cant seem to find a tutorial on the matter, and the cocoa documentation gets me lost, there is not enough information in there for me to really grasp what i should do to make it work, it must be one of those " it's so simple it's complicated to understand" would someone be so kind to explain how i can achieve this. in the interface builder i have a NSPredicateEditor I edited the templates that are in place in the designer, I created an outlet for it in my controller and connected them together. but when I run the application the editor is empty. then once he predicate is running i want to compare every tiems in my array with it, and delete from the array the items that do not match. thank you so much. Sandro. ___ 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]
Re: NSPredicateEditor
On Jun 26, 2008, at 6:48 PM, Chris wrote: 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. The right way to store an NSPredicate is archival via NSCoding. The string representation of a NSPredicate has always been lossy. -Peter ___ 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]
Re: NSPredicateEditor
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]
Re: NSPredicateEditor
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")) Hope this helps, -Peter ___ 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]
Re: NSPredicateEditor
On Wed, Jun 25, 2008 at 4:12 PM, Peter Ammon <[EMAIL PROTECTED]> wrote: > If the holds down the option key and clicks a + button, it will insert > another compound row, so the user can make arbitrarily complex predicates. Well this is incredibly "undiscoverable UI". Bug report time! --Kyle Sluder ___ 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]
NSPredicateEditor
Consider the following code, any NSPredicateEditor gurus: NSPredicateEditorRowTemplate *tmpTemplate = [[NSPredicateEditorRowTemplate alloc] initWithCompoundTypes: [NSArray arrayWithObjects: [NSNumber numberWithInt: NSNotPredicateType], nil]]; NSPredicate * tmpPredicate = [NSPredicate predicateWithFormat:@"mykey = 'foo'"]; NSPredicate * tmpCompPredicate = [NSCompoundPredicate notPredicateWithSubpredicate:tmpPredicate]; double result = [tmpTemplate matchForPredicate:tmpCompPredicate]; NSLog(@"RESULT: %f", result); This code prints 0.0. 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. ___ 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]
Re: NSPredicateEditor
Hi Chris, If the holds down the option key and clicks a + button, it will insert another compound row, so the user can make arbitrarily complex predicates. If this doesn't seem to happen, make sure the nesting mode is set to compound. By default, NSPredicateEditor supports And, Or, and Not compound types, where "Not" is interpreted as Nor, that is, "None of the following are true". -Peter On Jun 25, 2008, at 7:19 AM, Chris wrote: Cool. Now I notice that if you manually plug in a complex predicate like "a = b or c = d and e = f", that it is capable of displaying it correctly. Do you know if there is any way to allow the user to create more complex expressions? By default it only seems to allow either AND or OR, but not both from the user, even though the machinery seems to know how to display things more complex. On 25/06/2008, at 11:57 PM, Jim Turner wrote: On Wed, Jun 25, 2008 at 1:08 AM, Chris <[EMAIL PROTECTED]> wrote: Let's say I create a NSPredicateEditor and it looks like this: [All] of the following are true: [Name] equals [ ] --- So the user enters say "Fred" and the predicate returned is "Name == Fred". Later on, I reload that predicate into the NSPredicateEditor and it looks like this: [Name] equals [ Fred ] --- But now there is no option to change it to say: [Some] of the following are true: because that line isn't shown. How do I make that line reappear the next time? By default, the NSPredicateEditor object in IB creates a compound predicate. Wrap your "Name == Fred" predicate in a compound predicate before reloading it in the editor and the Any/All/None row should return. -- Jim http://nukethemfromorbit.com ___ 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/pammon%40apple.com This email sent to [EMAIL PROTECTED] ___ 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]
Re: NSPredicateEditor
Cool. Now I notice that if you manually plug in a complex predicate like "a = b or c = d and e = f", that it is capable of displaying it correctly. Do you know if there is any way to allow the user to create more complex expressions? By default it only seems to allow either AND or OR, but not both from the user, even though the machinery seems to know how to display things more complex. On 25/06/2008, at 11:57 PM, Jim Turner wrote: On Wed, Jun 25, 2008 at 1:08 AM, Chris <[EMAIL PROTECTED]> wrote: Let's say I create a NSPredicateEditor and it looks like this: [All] of the following are true: [Name] equals [ ] --- So the user enters say "Fred" and the predicate returned is "Name == Fred". Later on, I reload that predicate into the NSPredicateEditor and it looks like this: [Name] equals [ Fred ] --- But now there is no option to change it to say: [Some] of the following are true: because that line isn't shown. How do I make that line reappear the next time? By default, the NSPredicateEditor object in IB creates a compound predicate. Wrap your "Name == Fred" predicate in a compound predicate before reloading it in the editor and the Any/All/None row should return. -- Jim http://nukethemfromorbit.com ___ 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]
Re: NSPredicateEditor
On Wed, Jun 25, 2008 at 1:08 AM, Chris <[EMAIL PROTECTED]> wrote: > Let's say I create a NSPredicateEditor and it looks like this: > > > [All] of the following are true: > > [Name] equals [ ] > --- > > So the user enters say "Fred" and the predicate returned is "Name == Fred". > > Later on, I reload that predicate into the NSPredicateEditor and it looks > like this: > > > [Name] equals [ Fred ] > --- > > But now there is no option to change it to say: > > [Some] of the following are true: > > because that line isn't shown. > > How do I make that line reappear the next time? By default, the NSPredicateEditor object in IB creates a compound predicate. Wrap your "Name == Fred" predicate in a compound predicate before reloading it in the editor and the Any/All/None row should return. -- Jim http://nukethemfromorbit.com ___ 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]
NSPredicateEditor
Let's say I create a NSPredicateEditor and it looks like this: [All] of the following are true: [Name] equals [ ] --- So the user enters say "Fred" and the predicate returned is "Name == Fred". Later on, I reload that predicate into the NSPredicateEditor and it looks like this: [Name] equals [ Fred ] --- But now there is no option to change it to say: [Some] of the following are true: because that line isn't shown. How do I make that line reappear the next time? ___ 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]
NSPredicateEditor and decimal numbers with fractions
Hi, I've set up an NSPredicateEditor with a template that forms a predicate like: [Gross Value] [is] [32.99] the format of the text field is set as Number in Interface Builder. If I input 32.99 into the field I get a predicate like this: grossAmount.amount == 32 Obviously the number is rounded off at the decimal point. Since this is a currency amount, I need the decimal fraction ("the cents"). Any Advice? Ruotger ___ 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]