On Feb 4, 2012, at 19:11 , Erik Stainsby wrote:
> I have two windows. A is the source, B is the destination. A context menu
> action in A sets a string value on a message. The message arrives in window
> B, in a view which sets the stringValue of an NSTextField. I then read the
> stringValue back and echo it via NSLog() to ensure it arrived. All well and
> good. However, for some reason the NSTextField does not display the new
> value.
>
> Urk?!
>
>
> - (IBAction) setActionSelectorString:(NSString*)nodeSelector {
> NSLog(@"%s- [%04d] %@", __PRETTY_FUNCTION__, __LINE__, nodeSelector);
> if( nodeSelector != nil ) {
> [[[self view] window] makeMainWindow];
> [actionSelector setStringValue: nodeSelector];
> [[self view] setNeedsDisplay:YES];
> NSLog(@"%s- [%04d] %@", __PRETTY_FUNCTION__, __LINE__,
> [actionSelector stringValue]);
> }
> }
This is all very code-smelly. 'IBAction' is used with action methods who
signature is supposed to be like this:
- (IBAction) someAction: (id) sender
where 'sender' is typically a NSControl that sent the message, using the
target/action paradigm. In many cases, the receiver doesn't care what the
sender is, which gives you some freedom to pass an arbitrary parameter, but
typically the sender isn't going to be a string.
Your description of what's going on is at the least un-Cocoa-ish, and possibly
suspect:
> A context menu action in A sets a string value on a message.
You don't really set a value "on" a message, but I guess you're just saying
that A sends a message with a string parameter.
> The message arrives in window B,
Messages have a specific receiver, so you're saying A sent the message to
NSWindow object B?
> in a view
Well, no, now you're saying the receiver of the message was an unspecified view
in window B.
> which sets the stringValue of an NSTextField.
It sets something, though there's no clear evidence it's the text field you
think it is. For example, it's not a terribly unusual bug to end up with two
copies of a window, view or control, one of top of the other, with programmatic
changes directed to the one that's behind so that they seem to have no effect.
I think you're probably torturing the target/action mechanism here. It's much
more usual for a window *controller* to implement custom action messages,
instead of windows, views and controls. (That is, it's usual for UI elements to
*send* action messages, and for controllers to *receive* them.) It would be
simpler for A's window controller C to implement the menu action message, which
would send a regular (non-action) message with a string parameter to B's window
controller D, which -- knowing where to find the text field E from a properly
connected IBOutlet -- would modify E's contents.
_______________________________________________
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
