Another problem, this time with NSTextField

Member
Posts: 64
Joined: 2005.06
Post: #1
Mad This is really getting frustrating, I keep trying to both get and set the string value of an NSTextField, but it has no effect. setStringValue does nothing at all, and stringValue was returning null. I have to take off for work in about 3 minutes, so I'll just go ahead and post the entire class (small). I've already checked to make sure that all the methods are indeed being called as they should, and they are.

P.S. I managed to fix NSLog last night, by reseting all of XCode's preferences.

Code:
#import <Cocoa/Cocoa.h>

@interface CommandField : NSTextField
{
    NSString *commandString;
}

- (void)updateCommandString;
- (NSString *)commandString;
- (void)setCommandFieldString:(NSString *)commands;

@end

Code:
#import "CommandField.h"

@implementation CommandField

- (id)init
{
    if (self = [super init])
    {
    }
    
    return self;
}

- (void)updateCommandString
{
    commandString = [self stringValue];
    [self setCommandFieldValue: @""];
}

- (NSString *)commandString
{
    return commandString;
}

- (void)setCommandFieldString:(NSString *)commands
{
    [self setStringValue: commands];
}

@end
Quote this message in a reply
Member
Posts: 257
Joined: 2004.06
Post: #2
Uh, out of curiosity, why are you subclassing NSTextField? Also, do you have a CommandField object in your nib file that's properly connected to your app?

The brains and fingers behind Malarkey Software (plus caretaker of the world's two brattiest felines).
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #3
Not to offend, but this suspiciously looks like an unconnected outlet in IB.
Quote this message in a reply
Member
Posts: 64
Joined: 2005.06
Post: #4
The CommandField class is in the NIB, but there's no outlets; all interactions between objects are done in XCode... and I'm subclassing NSTextField, because I need to heavily modify it for phrase interpretation. Although I might be able to do that elsewhere, now that you mention it.
Quote this message in a reply
Member
Posts: 257
Joined: 2004.06
Post: #5
BUt you need the outlet so that your app knows about the NSTextField you're trying to change the display of.

The brains and fingers behind Malarkey Software (plus caretaker of the world's two brattiest felines).
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #6
I've actually got lots of experience in text field manipulation.

Short answer: Use NSTextView it's way easier.

Long answer: hang on, here goes....
Code:
- (void)setCommandFieldString:(NSString *)commands
{
    //unfortunately we don't have direct access to the textfield string
    [NSWindow *window = [self window];

    //so we pull the field editor
    NSText *fieldEditor = [window fieldEditor:YES forObject:self];
    
    //note that this will replace the entire contents and isn't
    // strictly the *fastest* method for doing this
    [fieldEditor setString: commands];

    //but if you're not worried about formatting, this is probably
    // the easiest method.

    //If you want to do rich text, send me an email personally
    // and I'll dig up my code for a post.
}

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #7
I would agree that likely the problem is not connecting the text field up in IB. Though all the inheritance etc. is handled in XCode, it needs an object to manipulate in the first place...

I would also agree that it's a lot easier and cleaner to use an NSTextField and just contain that in another class. That way, everything is contained together. I don't know if it's Java's crappy UI creation scheme, but some people's strategies seem to be to subclass everything thrown their way when they should just contain the object in another class and use it there. IMO, it's worthless to create a whole new subclass to add 1 object and add 3 methods taking 1-2 lines each, 2 of which are get and set methods..
Quote this message in a reply
Member
Posts: 469
Joined: 2002.10
Post: #8
Doing custom behavior for NSControls is ugly. Subclassing is a viable option in this case, especially if he's going to add a lot more custom behavior. Though ideally you'd want to have a delegate handle most event and behavior stuff.

---Kelvin--
15.4" MacBook Pro revA
1.83GHz/2GB/250GB
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #9
It's mainly style, really. I personally would never subclass a class to add 1 small thing to it unless I had to, since it requires a lot more worthless typing. I'd rather just have it contained. Now if I had to add a lot of new behaviors to it, that's a different story.
Quote this message in a reply
Member
Posts: 208
Joined: 2005.04
Post: #10
Don't forget that objective-C has a nifty little feature called categories. Categories allow you to add methods (sorry, but you can't add instance variables) to an existing class. They are great for adding one or two behaviours to things like NSTextField or NSString.
Quote this message in a reply
5thPeriodProductions
Unregistered
 
Post: #11
Is that the +[code here] deal? I've never heard of Categories before.
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  problem with time based animation ferum 5 3,142 Aug 4, 2006 01:45 PM
Last Post: ferum
  A Little Problem with NSLog (and long time no see) Justin Brimm 3 3,508 Oct 17, 2005 06:42 PM
Last Post: Steven
  Can you programmatically set the title of a NStextfield? kensuguro 5 5,664 Sep 6, 2005 08:09 AM
Last Post: Steven