• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Categories, Protocols, Delegates and ToolTips
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Categories, Protocols, Delegates and ToolTips


  • Subject: Re: Categories, Protocols, Delegates and ToolTips
  • From: Paul Cezanne <email@hidden>
  • Date: Wed, 19 Jun 2002 11:41:53 -0400

>If you implement in a category methods that already exist, your implementation will replace the original, which could be risky.

why? As long as I call super I should be ok, no? (Ok, I can see how I might do stuff that would be "bad" but since I am adding functionality seperate from the control, I think I am ok here.)


>> If I make a subclass of NSControl than I can't assign the connections in Interface Builder, a button needs a datatype that is a descendant of NSButton, not NSControl.
>
>I do not understand what you mean.

I subclass, not make a category, of NSControl, lets call it NSRolloverControl, like this

@interface NSRolloverControl : NSControl

now if I drag the .h file into IB, I cannot make an NSButton object a NSRolloveControl object. (Which I'm not complaining about, because it isn't an NSButton, this was just one of the paths of frustration I went down.)

>
>(1) Subclass NSControl and either send an NSNotification or send an action to nil (it would then be caught by the first responder that can respond). For instance:

Right now I've done the subclassing via a Category like you (and Georg Tuparev) suggested and it works! Right now I'm only putting out a printf but hey, I'm halfway there. I think I will use your idea for the sendAction and let the window that has the UI element draw it.

>(3) Use poseAs: to replace NSControl with your subclass. poseAs: as the same ivar limitation as categories (you cannot add instance variables), but at you've got access to super's implementation. And you can do without ivar in that case.

I did some brief reading on this and it seemed fairly complicated.

That reminds me, a lot of Cocoa is very cool, very powerful (I remember seeing a Next box at a trade show in the late 80s and thinking, man, that is the way to code.) but the coding paradigms are so different from C++ that the learning curve is very steep. Reading doesn't seem to help, coding seems to be the only way to do it. How do I convince my boss to send me to the Big Nerd Ranch and learn for a week. I've surely lost a week's worth in the past few months stumbling around.

This is a problem that Cocoa adoption is going to face. It is cool, but very different.

Thanks for your help everyone!
_______________________________________________
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.

  • Follow-Ups:
    • Re: Categories, Protocols, Delegates and ToolTips
      • From: Malte Tancred <email@hidden>
    • Re: Categories, Protocols, Delegates and ToolTips
      • From: Malte Tancred <email@hidden>
    • Re: Categories, Protocols, Delegates and ToolTips
      • From: Marco Scheurer <email@hidden>
References: 
 >Re: Categories, Protocols, Delegates and ToolTips (From: Marco Scheurer <email@hidden>)

  • Prev by Date: Re: Patterns in Cocoa ?
  • Next by Date: Re: Categories, Protocols, Delegates and ToolTips
  • Previous by thread: Re: Categories, Protocols, Delegates and ToolTips
  • Next by thread: Re: Categories, Protocols, Delegates and ToolTips
  • Index(es):
    • Date
    • Thread