Another problem, this time with NSTextField
Post: #1
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;
@endCode:
#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
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).
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.
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).
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....
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
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..
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..
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
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.
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.
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| problem with time based animation | ferum | 5 | 2,785 |
Aug 4, 2006 01:45 PM Last Post: ferum |
|
| A Little Problem with NSLog (and long time no see) | Justin Brimm | 3 | 3,140 |
Oct 17, 2005 06:42 PM Last Post: Steven |
|
| Can you programmatically set the title of a NStextfield? | kensuguro | 5 | 4,209 |
Sep 6, 2005 08:09 AM Last Post: Steven |
|