Re: Subclassing NSControl
Re: Subclassing NSControl
- Subject: Re: Subclassing NSControl
- From: Lorenzo <email@hidden>
- Date: Wed, 14 May 2003 14:31:32 +0200
Hi,
I saw somewhere that clock control. I am going to look for it again.
Thank you. Very helpful.
Best Regards
--
Lorenzo
email: email@hidden
>
From: David Remahl <email@hidden>
>
Date: Wed, 14 May 2003 14:10:06 +0200
>
To: Lorenzo <email@hidden>
>
Cc: Scott Anguish <email@hidden>, <email@hidden>
>
Subject: Re: Subclassing NSControl
>
>
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.