Re: NSStepper and NSTextField changes
Re: NSStepper and NSTextField changes
- Subject: Re: NSStepper and NSTextField changes
- From: Brad Oliver <email@hidden>
- Date: Fri, 13 Dec 2002 00:15:57 -0600
On 12/12/02 11:45 PM, "Brian Webster" <email@hidden> wrote:
>
You don't say so specifically, but from the description it sounds like
>
you have the steppers hooked up directly to the text fields via the
>
takeObjectValue: action (or one of its variants, e.g. takeIntValue:),
>
so I'm going to operate on that assumption here.
Yes, exactly.
>
So for example, if you have outlets to myTextField and myStepper, which
>
you want to be setting the values for myInteger in your controller, you
>
can create an action method and connect both the text field and stepper
>
to call the action.
Yes, that appears to match what I have discovered. This seems
counter-intuitive to me as I'm not interested in the value of the stepper,
and in general I'm hard-pressed to think of a situation where I would be, in
lieu of the value of the control the stepper modifies. In my case, I'm only
interested in the text field.
Unfortunately, AppKit doesn't give me much help in this regard, and I
discovered this particular gotcha after I'd hooked up all the controls. I'm
averse to changing this because in this particular tabbed dialog
monstrosity, there are 600-odd connections, and this brings InterfaceBuilder
to it's knees when I start changing them - it literally takes several
seconds for each click to register in IB.
I'm also boggled that changing the text field through means other than
direct user input doesn't provide a notification of any kind. It would seem
to me that the stepper modification case would be fairly common.
>
If you have a large number of text fields and steppers to deal with,
>
you might consider creating a matrix of text fields and a matrix of
>
steppers rather than having lots of individual outlets pointing to all
>
the controls.
This will definitely not work in my case, as these controls are spread
throughout many tabs of a dialog rather than concentrated in one place.
For the record, I implemented the hack the other person mentioned, which
worked exactly as I had hoped. It's not exactly a one-line fix, but it'll
do. :-) It follows for the sake of the archives.
In reading through the list archives, I noticed that in general, poseAsClass
is frowned upon, and upon further investigation I can see why. However I'm
lucky: in my app, the below doesn't cause problems with any other usage of
NSTextField.
In my main header file:
@interface LBOTextField : NSTextField
{
}
and in my main source file:
@implementation LBOTextField
+ (void)load
{
[self poseAsClass:[NSTextField class]];
}
- (void)takeIntValueFrom : (id)sender
{
[[NSNotificationCenter defaultCenter] postNotificationName:
@"NSControlTextDidChangeNotification" object: self];
return [super takeIntValueFrom: sender];
}
- (void)takeDoubleValueFrom : (id)sender
{
[[NSNotificationCenter defaultCenter] postNotificationName:
@"NSControlTextDidChangeNotification" object: self];
return [super takeDoubleValueFrom: sender];
}
- (void)takeFloatValueFrom : (id)sender
{
[[NSNotificationCenter defaultCenter] postNotificationName:
@"NSControlTextDidChangeNotification" object: self];
return [super takeFloatValueFrom: sender];
}
- (void)takeStringValueFrom : (id)sender
{
[[NSNotificationCenter defaultCenter] postNotificationName:
@"NSControlTextDidChangeNotification" object: self];
return [super takeStringValueFrom: sender];
}
@end
--
Brad Oliver
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.