Re: self registering NSValueTransformer and bindings
Re: self registering NSValueTransformer and bindings
- Subject: Re: self registering NSValueTransformer and bindings
- From: "I. Savant" <email@hidden>
- Date: Thu, 8 May 2008 07:59:56 -0400
Well, maybe it's language barrier as a non-native speaker ...but in
order for the transformer to do its job it requires a reference to
the NSTabView to be set. And I was trying to inject that reference
through a binding. That's what I wanted to say.
Perhaps, but for clarity, in the Cocoa world there's an important
distinction: IBOutlet and IBAction connections are referred to as
connections. A "binding" refers to the Cocoa Bindings mechanism.
That does not seem to be true. But to be 100% sure I've changed it to
NSValueTransformer *theTransformer = [[[MyValueTransformer alloc]
init] autorelease];
...and still get the same behavior. The correct instance is always a
MyValueTransformer and no NSValueTransformer as you said.
I would not have expected that to be the case, but ... :-)
In
*that* instance, the outlet is nil.
Doh! ...now here I was really stupid. But then again I would think
changing it to
- (void) awakeFromNib
<...>
would solve it. Turns out this is not enough. From looking at the
stacktrace it seems like the framework seems to create another
instance. So the only way I could get it to work was to register the
transformer in the init.
Well no, because the transformer needs to have been registered
before the object graph in the nib is fully realized (because the
connections and bindings that are being (re)established at that stage
will need your transformer).
- (id) init
Likewise with this. There's no guarantee this will work as expected
as your project (and the OS X environment) changes.
The documentation's example of doing this from within some class's
+initialize method has always worked perfectly for me. I really
suggest you use that approach unless you truly know another will work.
It's one of those things where the behavior (and reasons for that
behavior) depend on a lot of other factors.
And I think this could be quite neatly be abstracted away if the
transformer had access to the NSTabView. The name of the tab would
be the name of the account type the transformer is mapping to. Not
such a weird idea IMO.
I suppose that's a good argument; I just don't think it buys you
anything in return for the trouble it's causing you ...
One thing that is still missing is to get multiple instances
working. So basically getting rid of "NSStringFromClass([self
class])" and replace that with data from the object's interface
builder identity. But somehow I doubt that's easily accessible ...is
it?
This is what I mean - you should really have only one instance.
Every binding you establish references this instance by its registered
name. I may be getting confused by your explanation of your approach,
but it still seems wrong.
If you had this "entirely working" by taking a different approach
than usual, I'd graciously bow to you for having found "Another Way"
and I'd shut my trap. However, you're still saying this is mostly-
working-but-not-quite, so I'm pointing out that your somewhat
unconventional approach seems to be the cause of your problems. :-)
I reserve the right to be entirely wrong and eat 'humble pie', but
still ... simple is best (especially when 'unconventional' is causing
issues). To put this into perspective, with experience your goal is a
two-minute job using the approach I mentioned.
If you're just doing this as a learning experiment, I fully
understand, however it's best to learn the 'usual' way first, then
experiment with other solutions. Overall, you appear to be fighting
the frameworks, IMO.
--
I.S.
_______________________________________________
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