Final follow up: I got this to work with NSPredicateEditor, and it was actually surprisingly easy (I got the entire thing put in in a couple of hours this evening). The expression dependency was easy enough to get around. For example, with the "Stop evaluating rules" option, I just made the left expression a keyPath (@"stopRules"), the operator ==, and the right expression YES. I then overrode template views to not show the operator or the right expression. It works like a charm.
Cheers, Dave On Mar 10, 2010, at 12:16 PM, Dave DeLong wrote: > OK, following up: > > I've spent a couple days playing with NSRuleEditor, and I've found some stuff > out: > > It appears to only be useful for a static tree of information (unless I > dynamically modify the tree as rows are added and removed). I've come to > this conclusion based on my tests, due primarily to this observation: > > I created a node-style class to represent the possible *options* of the > editor (not the final tree). One of these options presented an NSTokenField. > I found that if I added a row to the rule editor that displays the > tokenfield, and then add a second row (also with a tokenfield), the > tokenfield from the first row disappears and jumps to the second row. > > I understand why this is happening: the rule editor was using the same node > object for both rows, which isn't how NSPredicateEditor behaves. > NSPredicateEditor uses row templates, and then duplicates the template it > needs for a particular row. I'm looking for the same sort of behavior, > except I don't want it for predicates. > > I suppose I could create a whole bunch of NSPredicateEditorRowTemplate > subclasses for each possible action (which is fine with me) and use a > predicate editor, but how could I get around the (apparent) NSExpression > dependency? Some of my actions are just single items (like "Stop evaluating > rules"), that don't have a left or right expression. Some may have more than > one expression (like an "Other..." option that when selected, displays a > textfield). > > And suggestions on how to proceed? > > Thanks, > > Dave
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 arch...@mail-archive.com