Re: NSTextField recieves string but does not display it?
Re: NSTextField recieves string but does not display it?
- Subject: Re: NSTextField recieves string but does not display it?
- From: Quincey Morris <email@hidden>
- Date: Sat, 04 Feb 2012 20:38:20 -0800
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- [d] %@", __PRETTY_FUNCTION__, __LINE__, nodeSelector);
> if( nodeSelector != nil ) {
> [[[self view] window] makeMainWindow];
> [actionSelector setStringValue: nodeSelector];
> [[self view] setNeedsDisplay:YES];
> NSLog(@"%s- [d] %@", __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 (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