Re: Question about NSObject based Class & delegates

use some delegation in it. How do I go > about this - currently this crashes when I assign delegates to self. > > class AudioRecordingManager: NSObject, AVAudioPlayerDelegate, > AVSpeechSynthesizerDelegate { > >let fileName = "demoRecording.m4a" >var m

Re: Question about NSObject based Class & delegates

, August 14, 2017 6:40:14 PM To: Eric E. Dolecki Cc: cocoa-dev Subject: Re: Question about NSObject based Class & delegates That should work. What’s the crash (backtrace, other messages?) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Ple

Re: Question about NSObject based Class & delegates

That should work. What’s the crash (backtrace, other messages?) —Jens ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.

Question about NSObject based Class & delegates

I have a custom class. I want to use some delegation in it. How do I go about this - currently this crashes when I assign delegates to self. class AudioRecordingManager: NSObject, AVAudioPlayerDelegate, AVSpeechSynthesizerDelegate { let fileName = "demoRecording.m4a&quo

Re: Success with NSTableView weak delegates?

On Tue, 20 Sep 2016 16:41:07 -0700, Greg Parker said: >Those crashes are expected. > >NSTableView's delegate is zeroing-weak when both of the following are true: >* Your app was built with the 10.11 SDK or newer. >* Your app is running on 10.12 or newer. > >The delegate is unsafe-unretained when

Re: Success with NSTableView weak delegates?

> On Sep 20, 2016, at 2:47 PM, Sean McBride wrote: > > On Tue, 20 Sep 2016 14:26:27 -0700, David Duncan said: > >>> On Sep 20, 2016, at 1:21 PM, Sean McBride wrote: >>> >>> Hi all, >>> >>> WWDC 2016 Session 203 "What's New in Cocoa" at around 43:37 in the >>> video, says that if you link aga

Re: Success with NSTableView weak delegates?

> On Sep 20, 2016, at 2:47 PM, Sean McBride wrote: > > On Tue, 20 Sep 2016 14:26:27 -0700, David Duncan said: > >>> On Sep 20, 2016, at 1:21 PM, Sean McBride wrote: >>> >>> Hi all, >>> >>> WWDC 2016 Session 203 "What's New in Cocoa" at around 43:37 in the >> video, says that if you link agai

Re: Success with NSTableView weak delegates?

On Tue, 20 Sep 2016 14:26:27 -0700, David Duncan said: >> On Sep 20, 2016, at 1:21 PM, Sean McBride wrote: >> >> Hi all, >> >> WWDC 2016 Session 203 "What's New in Cocoa" at around 43:37 in the >video, says that if you link against the 10.11 SDK that NSTableView's >delegate is weak. So I went

Re: Success with NSTableView weak delegates?

o a runtime check, or for trivial code like this always run the code until your MIN_ALLOWED (deployment target) is >= 10.11. > > Anyone have success with these supposedly weak tableview delegates? > > Thanks, > > -- >

Success with NSTableView weak delegates?

bleView setDelegate:nil]; [tableView setDataSource:nil]; #endif yet (with NSZombie especially), I easily reproduce message-to-zombie crashes with builds that are made against the Xcode 7.3.1 10.11 SDK. Anyone have success with these supposedly weak table

Save panel exception: "parentForItemsInColumn: is not supported for browsers with matrix delegates"

gBitmapImageType:NSPNGFileType]; } [self cleanupFromExportOfType:exportType]; }]; When running on Lion, some users are getting the following exception: parentForItemsInColumn: is not supported for browsers with matrix delegates The trace is as follows: 0 CoreFoundation 0x7fff8608c986

Re: threads and delegates

Kyle hi On 15 Dec 2010, at 16:17, Kyle Sluder wrote: > > You're already using delegates for asynchronous operation. You > therefore do not need the secondary thread. > > Asynchronous operation requires a running runloop. Your secondary > thread doesn't have one ru

Re: threads and delegates

On Wed, Dec 15, 2010 at 8:10 AM, julius wrote: > Hello all, > > I'm  hoping you can help me with a question about threads and delegates. > I don't have the terminology to pose the question suscinctly so I'll do so by > reference to the program which gave rise to

threads and delegates

Hello all, I'm hoping you can help me with a question about threads and delegates. I don't have the terminology to pose the question suscinctly so I'll do so by reference to the program which gave rise to it. I have an object which implements a number of delegate methods of

NSTextField and key event delegates

anges there that might be relevant? Something related to the planned deprecation of the NSTextInput protocol in favor of the NSTextInputClient protocol perhaps? If anyone should be inclined, the relevant code is available at the URL below[1]. The relevant methods are tab_complete: and the &qu

Re: Implementing delegates with formal protocols

On Aug 28, 2009, at 3:02 PM, Corbin Dunn wrote: On Aug 28, 2009, at 2:57 PM, Rick Mann wrote: Thanks for the suggestions. I have one suggestion saying to extend my protocol to conform to NSObject, and another saying I should use NSObject instead of ID. Is one approach better than the oth

Re: Implementing delegates with formal protocols

On Aug 28, 2009, at 15:02:13, Corbin Dunn wrote: On Aug 28, 2009, at 2:57 PM, Rick Mann wrote: Thanks for the suggestions. I have one suggestion saying to extend my protocol to conform to NSObject, and another saying I should use NSObject instead of ID. Is one approach better than the o

Re: Implementing delegates with formal protocols

On Aug 28, 2009, at 2:57 PM, Rick Mann wrote: Thanks for the suggestions. I have one suggestion saying to extend my protocol to conform to NSObject, and another saying I should use NSObject instead of ID. Is one approach better than the other? Yes; David's suggestion is preferred. It is

Re: Implementing delegates with formal protocols

Thanks for the suggestions. I have one suggestion saying to extend my protocol to conform to NSObject, and another saying I should use NSObject instead of ID. Is one approach better than the other? TIA! On Aug 28, 2009, at 14:43:16, David Duncan wrote: On Aug 28, 2009, at 2:36 PM, Rick Ma

Re: Implementing delegates with formal protocols

Usually delegates are weak references and not retained to avoid retain cycles or loops. Sent from my phone On Aug 28, 2009, at 2:36 PM, Rick Mann wrote: I have a similar issue when trying to retain and release the delegate (which I think can sometimes be avoided but should be used for

Re: Implementing delegates with formal protocols

Sorry, NSObject* delegate; Note the * Sent from my phone On Aug 28, 2009, at 2:36 PM, Rick Mann wrote: I'm trying to implement a delegate pattern in my code, where the delegate conforms to a formal protocol. But when I make the delegate ivar id and try to send it performSelectorOnMainT

Re: Implementing delegates with formal protocols

Use NSObject. Instead of id<...> Sent from my phone On Aug 28, 2009, at 2:36 PM, Rick Mann wrote: I'm trying to implement a delegate pattern in my code, where the delegate conforms to a formal protocol. But when I make the delegate ivar id and try to send it performSelectorOnMainThread:.

Re: Implementing delegates with formal protocols

On Aug 28, 2009, at 2:36 PM, Rick Mann wrote: I'm trying to implement a delegate pattern in my code, where the delegate conforms to a formal protocol. But when I make the delegate ivar id and try to send it performSelectorOnMainThread:..., it complains that that action is "not found in pr

Implementing delegates with formal protocols

I'm trying to implement a delegate pattern in my code, where the delegate conforms to a formal protocol. But when I make the delegate ivar id and try to send it performSelectorOnMainThread:..., it complains that that action is "not found in protocol(s). I have a similar issue when trying

Re: Multiple delegates Window

On Jul 25, 2009, at 6:21 PM, Andy Lee wrote: On Jul 25, 2009, at 5:55 PM, Gevik wrote: I was wondering if it is possible to connect more than one delegate from the Window in IB. No, but you could make an object that forwards delegate messages to multiple other objects, and have that be the

Re: Multiple delegates Window

On Jul 25, 2009, at 5:55 PM, Gevik wrote: I was wondering if it is possible to connect more than one delegate from the Window in IB. No, but you could make an object that forwards delegate messages to multiple other objects, and have that be the window delegate. --Andy __

Re: Multiple delegates Window

Correction... I meant to say "There is only one DELEGATE outlet..." not "There is only one WINDOW outlet..." ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the mod

Re: Multiple delegates Window

There is only one window outlet, so you can only hook up one object as the window's delegate. I am currently running into a similar issue with a text field delegate. See the discussion in the thread "[iPhone] Why can't a UITextField be its own delegate?" My solution, which has stirred some

Re: Multiple delegates Window

On Sat, Jul 25, 2009 at 4:55 PM, Gevik wrote: > I was wondering if it is possible to connect more than one delegate from the > Window in IB. > When I create a new Cocoa application in XCode, the Delegate_AppDelegate.m/h > is created automatically. > I would like to add a second object with specific

Re: Multiple delegates Window

On Sat, Jul 25, 2009 at 2:55 PM, Gevik wrote: > How do I do this? You don't. Read up on the delegate pattern again, and how it's implemented in Cocoa. You can't have one pointer point at two different things, so therefore you can't have two delegates hooked up to one

Multiple delegates Window

I was wondering if it is possible to connect more than one delegate from the Window in IB. When I create a new Cocoa application in XCode, the Delegate_AppDelegate.m/h is created automatically. I would like to add a second object with specific functionality as a delegate object. How do I do th

Re: Calling delegates explicitly

> On Sat, 2009/05/16, Jason Stephenson wrote: > From: Jason Stephenson > Subject: Re: Calling delegates explicitly > To: "Cocoa Cocoa-Dev" > Date: Saturday, 2009 May 16, 23:04 >> Eric E. Dolecki wrote: >> If I understand you, make a method which you can cal

Re: Calling delegates explicitly

] because that is up to the class that implements -setDelegate:. To be clear-- and I'd suggest an END-OF-THREAD until the OP posts a followup question with more content-- I didn't generalize anything. The OP's question was: Can we call delegates explicitly, Please reply soon.

Re: Calling delegates explicitly

:. Thanks, E. On May 16, 2009, at 4:27 PM, Jason Stephenson wrote: Uli Kusterer wrote: On 16.05.2009, at 19:28, Bill Bumgarner wrote: On May 16, 2009, at 10:21 AM, Sourabh Sahu wrote: Can we call delegates explicitly, Please reply soon. Yes. But it is a bad idea. What exactly was

Re: Calling delegates explicitly

wrote: Can we call delegates explicitly, Please reply soon. Yes. But it is a bad idea. What exactly was the question, and why is it a bad idea? I'm unable to follow the conversation, it seems ... ? I am not entirely certain either, but I know that if you're writing the code for

Re: Calling delegates explicitly

Uli Kusterer wrote: On 16.05.2009, at 19:28, Bill Bumgarner wrote: On May 16, 2009, at 10:21 AM, Sourabh Sahu wrote: Can we call delegates explicitly, Please reply soon. Yes. But it is a bad idea. What exactly was the question, and why is it a bad idea? I'm unable to follo

Re: Calling delegates explicitly

On 16.05.2009, at 19:28, Bill Bumgarner wrote: On May 16, 2009, at 10:21 AM, Sourabh Sahu wrote: Can we call delegates explicitly, Please reply soon. Yes. But it is a bad idea. What exactly was the question, and why is it a bad idea? I'm unable to follow the conversation, it

Re: Calling delegates explicitly

On May 16, 2009, at 10:21 AM, Sourabh Sahu wrote: Can we call delegates explicitly, Please reply soon. Yes. But it is a bad idea. b.bum ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator

Calling delegates explicitly

Hi All, Can we call delegates explicitly, Please reply soon. Thanks Sourabh DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Persistent Systems Ltd. It is intended only for the use of the individual or entity to which it is addressed

Re: Help with implementing delegates

On Fri, Mar 27, 2009 at 4:48 PM, Drew Lawson wrote: > According to Greg Guerin: > >> albert jordan Mobility wrote: >> >> > In Foo, I have set up the following delegate method >> > >> > -(void) test: (dgtest *) sender:didFinish: (BOOL) complete >> >> Over-colonization?  Try: >> >>    -(void) test:

Re: Help with implementing delegates

On Mar 27, 2009, at 7:48 PM, Drew Lawson wrote: According to Greg Guerin: albert jordan Mobility wrote: In Foo, I have set up the following delegate method -(void) test: (dgtest *) sender:didFinish: (BOOL) complete [...] You just gave me a newbie headache. How is that original parsed?

Re: Help with implementing delegates

According to Greg Guerin: > albert jordan Mobility wrote: > > > In Foo, I have set up the following delegate method > > > > -(void) test: (dgtest *) sender:didFinish: (BOOL) complete > > Over-colonization? Try: > >-(void) test: (dgtest *) sender didFinish: (BOOL) complete > > Note the re

Fwd: Help with implementing delegates

I am having problems with implementing delegates, and I'm sure I'm doing something silly. Would appreciate help from the experts. I can get a simple case to work, where I invoke a delegate method with no parameters passed, but I can't get the case where I invoke

Re: Help with implementing delegates

albert jordan Mobility wrote: In Foo, I have set up the following delegate method -(void) test: (dgtest *) sender:didFinish: (BOOL) complete Over-colonization? Try: -(void) test: (dgtest *) sender didFinish: (BOOL) complete Note the removal of the colon between sender and didFinish. Al

Help with implementing delegates

I am having problems with implementing delegates, and I'm sure I'm doing something silly. Would appreciate help from the experts. I can get a simple case to work, where I invoke a delegate method with no parameters passed, but I can't get the case where I invoke

Re: NSArrays and tableView delegates

On 05/12/2008, at 9:25 AM, Ashley Clark wrote: (Leopard 10.5.5 with GC on) If you're running this program under GC then none of what you said makes sense anyway since retain/release/autorelease are all no-ops under GC and -dealloc is never called there. Ah the benefit of a simple sent

Re: NSArrays and tableView delegates

ions:(id)sender; - (IBAction) deleteSelectedTransactions:(id)sender; - (void) setAccountSortDescriptors: (NSArray *) descriptors; - (NSArray *) accountSortDescriptors; - (void) importFile:(NSString *)aFile; //delegates - (int)numberOfRowsInTableView:(NSTableView *)tableView; - (id)tableView:(NSTableV

NSArrays and tableView delegates

nsactions:(id)sender; - (IBAction) deleteSelectedTransactions:(id)sender; - (void) setAccountSortDescriptors: (NSArray *) descriptors; - (NSArray *) accountSortDescriptors; - (void) importFile:(NSString *)aFile; //delegates - (int)numberOfRowsInTableView:(NSTableView *)tableView; - (id)tableView:(NST

another best-practices question: separate delegates for controls?

that NSMenus check for the existence of method menuNeedsUpdate: only in the case that numberOfItemsInMenu: and menu:updateItem:atIndex:shouldCancel: are not implemented. So if I used the first delegate for my first menu, then later added a second menu using the latter delegates, I've just brok

Re: Sent Actions, Delegates, Outlets

which can only have one connected object. Am I correct? They're really for two different things. Often a delegate interface supports a superset of what notifications will notify observers of; for example, see the descriptions of the delegates for NSWindow and NSApplication, and compar

Re: Sent Actions, Delegates, Outlets

On Jul 23, 2008, at 10:51 PM, Graham Cox wrote: 2) I have found that IB automatically treats all member variables of my custom view's class that are of type "id" or "id<...>" as outlets, i.e. they appear in the list of outlets on Ctrl+click. This is not always desirable. How do I prevent some o

Re: Sent Actions, Delegates, Outlets

Warning: Blatant self serving plug: Target/Action, Delegates, and Notifications are all software design patterns. They aren't even unique to Cocoa, but Cocoa has particularly elegant implementations. You can read/review all about these patterns and more including analysis of

Re: Sent Actions, Delegates, Outlets

y have one connected object. Am I >> correct? > > They're really for two different things. Often a delegate interface > supports a superset of what notifications will notify observers of; for > example, see the descriptions of the delegates for NSWindow and > NSApplication

Re: Sent Actions, Delegates, Outlets

ch can only have one connected object. Am I correct? They're really for two different things. Often a delegate interface supports a superset of what notifications will notify observers of; for example, see the descriptions of the delegates for NSWindow and NSApplication, and compar

Re: Sent Actions, Delegates, Outlets

On Thu, Jul 24, 2008 at 9:15 AM, Graham Cox <[EMAIL PROTECTED]> wrote: > > On 24 Jul 2008, at 3:58 pm, Oleg Krupnov wrote: > >> Currently the "Sent Actions" section does not even appear in my custom >> view's connections menu at all, how would I make it appear? > > > To clarify: the reason it's not

Re: Sent Actions, Delegates, Outlets

On 24 Jul 2008, at 3:58 pm, Oleg Krupnov wrote: Currently the "Sent Actions" section does not even appear in my custom view's connections menu at all, how would I make it appear? To clarify: the reason it's not listed is because the built-in support is for NSControl and its subclasses. If

Re: Sent Actions, Delegates, Outlets

On 24 Jul 2008, at 3:58 pm, Oleg Krupnov wrote: target/action Is this the same as the following? action is sent to target on a click. The other things you mention are either not detected or not sent on to the target. I don't quite understand how target/action works under the hood. If I

Re: Sent Actions, Delegates, Outlets

> target/action Is this the same as the following? > action is sent to target on a click. The other things you mention are either > not detected or not sent on to the target. I don't quite understand how target/action works under the hood. If I were an implementor of NSButton, how would I declar

Re: Sent Actions, Delegates, Outlets

g the view? I assume it is to use a delegate outlet, right? one or more of: NSNotification/NSNotificationCenter target/action delegate KVO However I noticed that not all views use delegates to trigger external actions. For example, NSButton don't seem to have a delegate, but they have t

Sent Actions, Delegates, Outlets

t, right? However I noticed that not all views use delegates to trigger external actions. For example, NSButton don't seem to have a delegate, but they have the "Sent Actions" section in the menu that appears on Ctrl+click in the IB, that is initially empty ("selector"), b

RE: Delegates

Sigh. So I'm dating myself with the comment about dating myself... (playful grin) R, John -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeff LaMarche Sent: Monday, May 19, 2008 4:04 PM To: Cocoa Developers Subject: Re: Delegates On May 19, 200

Re: Delegates

On 19 May 2008, at 21:23, I. Savant wrote: On Mon, May 19, 2008 at 2:54 PM, Michael Vannorsdel <[EMAIL PROTECTED] > wrote: There's nothing that guarantees a Cocoa delegate will act for another object and that the represented object won't act how it wants as well. Sometimes a delegate metho

Re: Delegates

On May 19, 2008, at 5:00 PM, john darnell wrote: yeah, I know...I'm dating myself with the use of the word "grok" Huh? You're not dating anything. :P I think grok gets used on this list at least a few times a week. Grok is part of the geek lexicon, even among people who have no idea wher

RE: Delegates

I believe it was Carl Jung who said that ideas needed meathooks in the mind to help us retain/organize our thoughts and many of you have helped me figure out the right meathooks to use when attempting to grok the meaning of delegates (yeah, I know...I'm dating myself with the use of the

Re: Delegates

On May 19, 2008, at 1:54 PM, Michael Vannorsdel wrote: I'm just saying Cocoa delegates don't always act in dictionary form. I know this discussion can go round and round, but I still think reading the english dictionary for delegates won't tell you the whole story on

Re: Delegates

Ditto, I'll surrender the last word to you. Though I'm interested to know if the OP is having any success or not. This thread got a little sidetracked. On May 19, 2008, at 2:23 PM, I. Savant wrote: I think that's the last I'll comment on the dictionary definition matter; it's a silly arg

Re: Delegates

case of 1, no harm (as in notifications). In the case of 2-4, the delegating object *will* wait for the delegate to complete and return execution to. VERY UNLIKE notifications. It behaves very differently. > I'm just saying Cocoa delegates don't always act in dictionary form. > I kn

Re: Delegates

On May 19, 2008, at 2:54 PM, Michael Vannorsdel wrote: I know this discussion can go round and round, but I still think reading the english dictionary for delegates won't tell you the whole story on Cocoa delegates. There's also Wikipedia: <http://en.wikip

Re: Delegates

D'oh, I see that point was already made. --Andy On May 19, 2008, at 2:52 PM, Andy Lee wrote: Another difference between delegates and observers is that delegates sometimes have the power of veto over some operation (e.g., - applicationShouldTerminate: and -textShouldEndEditing:), wh

Re: Delegates

On 19 May '08, at 9:22 AM, john darnell wrote: As far as I can tell, it is kind of like a virtual function (virtual because I, the programmer, am expected to flesh it out) that resembles an event attached to a given class. You're basically correct, but I think you're overcomplicating the co

Re: Delegates

ect on the represented object's course of action on that matter. I'm just saying Cocoa delegates don't always act in dictionary form. I know this discussion can go round and round, but I still think reading the english dictionary for delegates won't tell you the whole s

Re: Delegates

Another difference between delegates and observers is that delegates sometimes have the power of veto over some operation (e.g., - applicationShouldTerminate: and -textShouldEndEditing:), whereas observers of notifications are merely notified. --Andy On May 19, 2008, at 1:41 PM, I. Savant

Re: Delegates

> In this respect, an object is entrusting a task or responsibility to > something else that has no direct control over the 'superior' object's > workings, but the 'superior' object is relying on the 'delegate' to > perform some task if necessary or to find something out and let it's > 'superior'

Re: Delegates

On Mon, May 19, 2008 at 2:00 PM, Michael Vannorsdel <[EMAIL PROTECTED]> wrote: > Even delegation is not a commonly known term in my experience (it's used for > several differing ideas in the US). Not sure what you mean there. To 'delegate' is to "entrust (a task or responsibility) to another

Re: Delegates

fit Cocoa delegates, but it's really close. I just hope to trigger the start of grasping the concept by giving little simplified (sometimes overly) ideas and hope it's enough for someone to run with who will eventually see the bigger, more complex, picture. It's difficult t

Re: Delegates

On Mon, May 19, 2008 at 1:37 PM, Michael Vannorsdel <[EMAIL PROTECTED]> wrote: > Indeed. I was just trying to keep it in simple terms as not to overwhelm > the OP with heavy details. I just wanted the concept to make some sense in > better known terms at the risk of oversimplifying. I figured

Re: Delegates

> I think that was 'observers', not 'Observers'. > (i.e. not in the Cocoa/KVO sense) > > Sometimes wonder if we're going to run out of words to describe things > because everything is overloaded with some technical meaning. > Still ... my point is the same. I think this is a semantics argument w

Re: Delegates

Indeed. I was just trying to keep it in simple terms as not to overwhelm the OP with heavy details. I just wanted the concept to make some sense in better known terms at the risk of oversimplifying. On May 19, 2008, at 11:01 AM, I. Savant wrote: Well, no, not really. This is significantl

Re: Delegates

On 19 May 2008, at 18:01, I. Savant wrote: On Mon, May 19, 2008 at 12:52 PM, Michael Vannorsdel <[EMAIL PROTECTED] > wrote: Delegates act like observers. Well, no, not really. I think that was 'observers', not 'Observers'. (i.e. not in the Cocoa/KVO sense) Somet

Re: Delegates

that with virtual functions the overloading is done in a subclass at compile time, and with delegates it's done with any class at runtime. Say we had two classes (ClassA & ClassB). ClassB DOES NOT have to be any relation to ClassA (Super, Sub-Class, or anything else). An instance

Re: Delegates

Delegates *are* often automatically registered for their delegated object's notifications, however. The differences between these and "regular" delegate methods should be apparent in the documentation, though, since the former will take a single argument of NSNotification *.

Re: Delegates

On Mon, May 19, 2008 at 12:52 PM, Michael Vannorsdel <[EMAIL PROTECTED]> wrote: > Delegates act like observers. They register with another object saying > "hey, if you do something important I want to know about it and have a > chance to act on it too". Well

Re: Delegates

On May 19, 2008, at 11:22 AM, john darnell wrote: I've been trying to get my head wrapped around the concept of "delegates" and I thought I would run it by the list to see if I am approaching the correct idea behind a delegate. As far as I can tell, it is kind of like a v

Re: Delegates

> I've been trying to get my head wrapped around the concept of > "delegates" and I thought I would run it by the list to see if I am > approaching the correct idea behind a delegate. Is there something about your question this document doesn't address

Re: Delegates

Delegates act like observers. They register with another object saying "hey, if you do something important I want to know about it and have a chance to act on it too". Each class that allows delegates have a list of delegate methods. These are the methods the class is willing

Re: Delegates

ading what you've written, you're pretty close, and I'm sure you'll figure out what you've missed as you go along. On May 19, 2008, at 11:22 AM, john darnell wrote: Hello Everyone: I've been trying to get my head wrapped around the concept of "delegates"

Delegates

Hello Everyone: I've been trying to get my head wrapped around the concept of "delegates" and I thought I would run it by the list to see if I am approaching the correct idea behind a delegate. As far as I can tell, it is kind of like a virtual function (virtual because I,

AppKiDo, delegates, known bugs

There was a question here recently that asked for clarification on the use of a delegate method. I thought I'd mention that one of the goals of my application AppKiDo was to help people see what delegates are. In the Quicklist drawer, you can click on "Classes with delegates&q

Re: NSPredicateEditorRowTemplate and templateView delegates

d by the editor and I wonder if the delegate isn't getting copied as well. Is there a better way of setting the delegate of a text field in a NSPredicateEditorRowTemplate? Hi Jim, As you surmised, delegates are not propagated by copy. NSPredicateEditor posts NSControlTextDidChangeNotific

NSPredicateEditorRowTemplate and templateView delegates

I've a NSPredicateEditor with some basic popup-popup-view style templates (where the view is a NSTextField). I am attempting to set the text field's delegate to one of my objects so I can be notified when the control text changes. Everything appears to be setup correctly except my controlTextDidC

Re: controllers, delegates, retain, release ...

On Feb 22, 2008, at 20:39, Jack Repenning wrote: I have some code inherited from someone else (so I have no answers to why it's the way it presently is) that's handling retention in a way I find confusing, and think is not in accordance with the spirit of the law. But I can't quite figure

Re: controllers, delegates, retain, release ...

Interesting discussion, thanks. Not surprising, I suppose, if there's some split on a "matter of taste" like whether it's legitimate to have an object manage its own lifecycle ([self autorelease]). FWIW, I chose Quincey's solution, [[alloc]init]autorelease] in Controller, and [[super init

Re: controllers, delegates, retain, release ...

On Feb 23, 2008, at 12:10 AM, Adam P Jenkins wrote: Where is this magic documented? The documentation for CFRetain doesn't mention this usage. See: Using CFRetain on an object doesn't quite

Re: controllers, delegates, retain, release ...

On Feb 22, 2008, at 5:17 PM, Charles Steinman wrote: --- Jack Repenning <[EMAIL PROTECTED]> wrote: On Feb 22, 2008, at 1:13 PM, Keith Duncan wrote: This would be a problem should the code base ever be compiled with GC support. Interesting point, that retain/release supports a lifecycle

Re: controllers, delegates, retain, release ...

--- Jack Repenning <[EMAIL PROTECTED]> wrote: > On Feb 22, 2008, at 1:13 PM, Keith Duncan wrote: > > This would be a problem should the code base ever > be compiled with > > GC support. > > Interesting point, that retain/release supports a > lifecycle model > (free-floating, self-managed obj

Re: controllers, delegates, retain, release ...

On Feb 22, 2008, at 1:13 PM, Keith Duncan wrote: This would be a problem should the code base ever be compiled with GC support. Interesting point, that retain/release supports a lifecycle model (free-floating, self-managed object) that can't be supported by GC -==- Jack Repenning Chief

Re: controllers, delegates, retain, release ...

FWIW, I wouldn't call it wrong for an object to manage its own lifetime. You'll leak UIs if the notification never appears, but this is apparently not a problem. This would be a problem should the code base ever be compiled with GC support. Granted that is unlikely as this is an existing co

Re: controllers, delegates, retain, release ...

On Feb 22, 2008, at 10:39, Jack Repenning wrote: In the current structure, Controller performs { UI *ui = [[UI alloc] initWithContext: context]; [ui run: @selector(doSomething) title: @"Title"]; } That is: the UI object is alloc'ed (creating a release obligation), but is not (auto)released

controllers, delegates, retain, release ...

I have some code inherited from someone else (so I have no answers to why it's the way it presently is) that's handling retention in a way I find confusing, and think is not in accordance with the spirit of the law. But I can't quite figure out how to do it "right". Is there a pattern I s