Re: Subclassing NSControl
Re: Subclassing NSControl
- Subject: Re: Subclassing NSControl
- From: David Remahl <email@hidden>
- Date: Wed, 14 May 2003 14:10:06 +0200
Lorenzo,
Well, a protocol only requires you to implement a set of methods in
each class that conforms to it. There is no actual default
implementation attached to a protocol.
Another thing you will want to consider when you are creating your own
subclasses of controls, is that most NSControls delegate the majority
of their work to subclasses of NSCell. For example, NSButton uses an
NSButtonCell to process input and perform drawing. That is what the
setCell: method you talked about before controls.
You should read the documentation about controls and cells, and take a
look at some sample code. There is a clock control sample from last
year's WWDC on ADC. The main idea is that it should demonstrate the
accessibility API, but it is also a good demonstration of a control
which uses a cell.
/ Sincerely, David Remahl
On Wednesday, May 14, 2003, at 01:41 PM, Lorenzo wrote:
Thank you for your code.
But, just to say, maybe attaching the same protocol to the subclasses
MYTextField and MyImageView could help. I never used protocols, so I am
totally new. What do you think about?
Best Regards
--
Lorenzo
email: email@hidden
From: David Remahl <email@hidden>
Date: Wed, 14 May 2003 10:43:27 +0200
To: Lorenzo <email@hidden>
Cc: <email@hidden>, Scott Anguish <email@hidden>
Subject: Re: Subclassing NSControl
Lorenzo,
I just want to emphasize that you will have to implement
-setCommonBehaviorClass: yourself. This is what I mean (typed in
Mail):
@interface MYTextField : NSTextField
{
Class *_commonBehaviourClass;
}
- (void)setCommonBehaviourClass:(Class)aClass;
- (Class)commonBehaviourClass;
@end
@implementation MYTextField
- (void)setCommonBehaviourClass:(Class)aClass
{
if( aClass != _commonBehaviourClass )
{
_commonBehaviourClass = aClass;
[self setNeedsDisplay:YES];
}
}
- (Class)commonBehaviourClass { return _commonBehaviourClass; }
- (void)mouseDown:(NSEvent *)evt
{
if( ![_commonBehaviourClass commonMouseDown:evt] ) // if not processed
{
// my own implementation
[super mouseDown:evt];
}
}
@end
/ Rgds, David
On Wednesday, May 14, 2003, at 10:37 AM, Lorenzo wrote:
Hi,
thank you for your suggestion. I was spending all of my time
searching
for a
way to do that. Anyway, I saw that the API setCellClass: could change
the
behaviour of an NSControl, but I didn't yet found the way to make it
work.
I am going to do as you said. Thanks.
Best Regards
--
Lorenzo
email: email@hidden
From: David Remahl <email@hidden>
Date: Wed, 14 May 2003 10:24:46 +0200
To: Scott Anguish <email@hidden>
Cc: <email@hidden>, Lorenzo <email@hidden>
Subject: Re: Subclassing NSControl
On Wednesday, May 14, 2003, at 10:14 AM, Scott Anguish wrote:
On Wednesday, May 14, 2003, at 03:51 AM, Lorenzo wrote:
Hi,
I have two own subclasses:
MYTextField subclass of NSTextField
MYImageView subclass of NSImageView
For many of their behaviours these 2 classes work the same way,
e.g. they respond to the mouse clicks the same way,
if the user clicks holding down the Control key, a pop-up menu
appears...
So I thought to group these 2 subclasses under a superClass
"MYBox",
and to describe the common behaviours (like mouseDown, mouseUp)
in this new superClass "MYBox".
You can't really do that. NSTextField and NSImageView both inherit
from NSControl.
what you could do is have your own subclasses of NSTextField and
NSImageView and then have the mouseDown: and mouseUp: methods in
your
subclasses call a procedure (yep, an old fashion procedure) passing
the sender and it's parameters
void CommonMouseDownHandler(NSEvent *theEvent, NSControl *sender)
void CommonMouseUpHandler(NSEvent *theEvent, NSControl *sender)
this would let you put all the code in a single shared location,
and
still give you all the objective-C goodness of calling the
objects..
You could even use class methods and make it into a class if you
wanted to (but I don't see the advantage in this case... maybe if
you
had a single set of shared data that they needed to access a
singleton
might make sense)
I was just typing up a response to the same effect as yours...
One advantage of using a separate class with class or instance
methods
could be that you want to be able to change the set of common
behaviors
dynamically at run-time. Using a class, referenced by an instance
variable in MYTextField would allow you simply to do a
-setCommonBehaviorClass: on the text field instance and have it
shift
behaviors.
But I agree with Scott that in this case it probably isn't needed.
/ Rgds, David
_______________________________________________
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.
_______________________________________________
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.