Thanks for the reply Peter.
Just for the archives, my subclassed NSPopUpButton wasn't showing up
because, like you said, it was being treated differently and I was
initializing it with NSZeroRect. Giving it a starting size and
sending it sizeToFit in templateViews got it on screen.
Jim
On Fri, Aug 29, 2008 at 4:17 PM, Peter Ammon [EMAIL PROTECTED] wrote:
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 (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]
