Re: NSPredicateEditorRowTemplates and preserving user input
Re: NSPredicateEditorRowTemplates and preserving user input
- Subject: Re: NSPredicateEditorRowTemplates and preserving user input
- From: Peter Ammon <email@hidden>
- Date: Fri, 29 Aug 2008 14:17:57 -0700
On Aug 29, 2008, at 8:51 AM, Jim Turner wrote:
Hi List,
I noticed something today while building a new popup-popup-popup
template: when the user changes the comparator (a simple is/is not in
my case), the third popup resets itself to the default value instead
of maintaining the selection the user had already chosen. The same is
true if the third view in my template is a text field. If they enter
text, then change the value from "contains" to "begins with", the text
they've entered is removed.
Hi Jim,
This is a known issue and I don't think there's a workaround yet, sorry.
I understand that templates are copied like mad behind the scenes of
the editor and that popups are treated differently, but I'm not sure
how I go about fixing this. I tried subclassing NSPopUpButton to see
what is passed for setObjectValue but the editor doesn't seem to like
a subclassed NSPopUpButton. Instead, it ignores it and displays
nothing. Very strange.
If you subclass NSPopUpButton, NSPredicateEditor assumes it has
special behavior and you want it to be treated like other views. It's
only instances of NSPopUpButton themselves that get the different
treatment of being merged together to build the tree of options.
-Peter
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden