Re: Drag 'n Drop 'n Delegation Dilemma
Re: Drag 'n Drop 'n Delegation Dilemma
- Subject: Re: Drag 'n Drop 'n Delegation Dilemma
- From: Christophe Dore <email@hidden>
- Date: Wed, 19 Jun 2002 09:30:34 +0200
IMHO...
Well, you can always poseAs NSView... It's in fact a same but simpler
(less bug-prone, i Think) way than global dictionary +category to add
ivars in all views.
Note that I don't slightly recommand poseAs: as a solution to any
problem. But when you come to consider either to subclass every NSView
subclass (what an effort !!), of handle a bug-prone and slowness-source
global dictionary to simulate more ivars, sometimes what should be
considered as a 'dirty trick' becomes the badless solution...Brian
Webster wrote:
On Tuesday, June 18, 2002, at 03:58 PM, Demitri Muna wrote:
I also create (in awakeFromNib) an observer for that same object,
listening for the message that I send from the category:
[nc addObserver:self // set controller as observer
selector:@selector(handleDragIntoMyButton:)
name:@"DNDDraggingEntered Notification"
object:searchButton]; // only listen for my object
...and then of course I have a method called "handleDragIntoMyButton"
that does what I need for that button alone.
This part of the construct won't work correctly. This is because some
of those dragging methods return values saying what drag operations
are permitted and whether a drag is accepted or not. How does the
observer tell the view that it should accept or reject a drop? There
is no way to return a value to your view from the posting of a
notification - the notification simply does not return any value.
Delegates are used in these sorts of situations because they are
exerting some control over the object by returning values from (at
least some of) its delegate methods. For instance, NSApplication
sends an applicationShouldTerminate: message only to its delegate
because the delegate is the one that decides whether the app should
terminate or not. Notifications are just that, they notify objects
but don't give them any direct way to exert control.
I don't think that, given the way drag and drop is implemented in
Cocoa, that there is a clean, cure-all solution that will allow you to
avoid subclassing in order to implement drag and drop. If I had
designed the system, I probably would have given NSView some sort of
"drag delegate" to handle dragging messages. This is a hard thing to
do after the fact, though, since you can't add instance variables to
an existing class like you can add methods using categories. I
suppose one way around this would be to have some sort of global
dictionary that maps NSViews onto their delegates, but that would
bring up a whole other slew of issues.
--
Brian Webster
email@hidden
http://homepage.mac.com/bwebster
_______________________________________________
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.