Re: Determining when dragging begins and ends

On May 08, 2010, at 12:14 AM, Dave DeLong wrote: > So in a nutshell: > > How can I reliably know when dragging begins and ends? > > Thanks, > > Dave You can subclass NSOutlineView and call to your delegate on the NSDraggingSource protocol methods: - (NSDragOperation)draggingEntered: - (NSDr

Re: Program crashed after edit values at NSTableView

Graham, after setDataSource to nil, seems do the trick. No more crashing. Thanks. Peter C On 8 May 2010, at 1:10 PM, Graham Cox wrote: > > On 08/05/2010, at 2:21 PM, Peter C wrote: > >> How do I prevent [] or NSTableView updating after window is close ? > > > Looks like the table view is as

Re: How do you set the text in an NSTextView?

On 8 May 2010, at 07:02:59, G S wrote: Interface Builder shows that this control is an NSScrollView. Repeatedly clicking on it does not drill down any further; NSScrollView is the end of the line. The class is never shown as NSTextView. Check out what happens if you Control-drag from t

Re: NSBrowser dragging

Dear Corbin, Thanks for responding, however I must contradict you, vertical drag with ComplexBrower does work under 10.6. It does so because its cell is an NSTextfieldCell which inherits from NSActionCell. "Since NSBrowserCell does not inherit from NSActionCell, it doesn’t hold a target and act

Re: self = [super init], nil?

Patrick, I don't really know if I am right, because of lack of experience. Please, correct me if I'm wrong, but... Why would anyone write code like that? I mean, if one subclasses NSObject and doesn't override +init, it will return self -- or, maybe, nil -- anyways. So, I would assume that [s

Re: self = [super init], nil?

Patrick, I made some mistakes in the code. Wherever I wrote +init (or something similar), I really meant -init. It's an instance method, not a class method. That's what happens when you type code in Mail before having breakfast... Cheers, Flavio On 08/05/2010, at 10:13, Flavio Donadio wrote:

Re: self = [super init], nil?

> I don't really know if I am right, because of lack of experience. Please, > correct me if I'm wrong, but... Why would anyone write code like that? > > I mean, if one subclasses NSObject and doesn't override +init, it will return > self -- or, maybe, nil -- anyways. > > So, I would assume tha

Re: self = [super init], nil?

On May 8, 2010, at 9:06 AM, Joanna Carter wrote: > If you declare +init, you are writing a static method, not an instance method. And while we're correcting things, there's no such thing as a "static method" in Objective-C. There are class methods. The use of "static" in this way is a C++-ism

Re: self = [super init], nil?

Hi Ken > And while we're correcting things, there's no such thing as a "static method" > in Objective-C. There are class methods. The use of "static" in this way is > a C++-ism. Aaarrggh!!! My problem is that I used Delphi ever since v1, which call them class methods, but for the past f

Re: self = [super init], nil?

On May 8, 2010, at 7:12 AM, gandreas wrote: A subtle but important point is that after init's self=[super init] is the only time you normally could have self being NULL (the only other time I can think of is when you do some form of IMP caching and explicitly call the method with nil as th

Re: self = [super init], nil?

On May 7, 2010, at 2:34 PM, Patrick M. Rutkowski wrote: > it worth checking for nil after doing self = [super init]? Yes. It's part of a design pattern, which looks like this: --- - (id)init { if (self = [super init]) { } return self; } --- See "Constraints and Conventions". http

Re: self = [super init], nil?

On May 8, 2010, at 8:12 AM, Kyle Sluder wrote: Now that we have blocks, I expect we'll be using a lot less of this, but with our current codebase it pays to be safe. To be clear, I'm not suggesting that I check the return value of every -init call. Rather, I only check the ones that ar

Re: self = [super init], nil?

Flavio Donadio wrote (Saturday, May 8, 2010 6:13 AM -0300): So, in case a class' +init method can return nil and you want to subclass it, the code should be more like: + (id*)init { if ([super init] != nil) { ... [return self]; } else { return nil; // or return

Re: self = [super init], nil?

On May 8, 2010, at 8:28 AM, James Bucanek wrote: I'd like to point out that this is one of those counterintuitive cases where more code is less. The code self = [super init]; if (self!=nil) ... produces fewer machine instructions than if ([super init]!=nil) ... W

NSImage and NSImageView questions

Dear programmers, I am hoping that the list can help me solve what I assume are 3 simple issues. I am starting to explore the murky details of working with images. 1. I have an NSImageView which scales the image to fit, aligned centered. My question is, how do I find the NSRect of the image in

Re: self = [super init], nil?

On May 8, 2010, at 7:45 AM, Joanna Carter wrote: > Hi Ken > >> And while we're correcting things, there's no such thing as a "static >> method" in Objective-C. There are class methods. The use of "static" in >> this way is a C++-ism. > > Aaarrggh!!! > > My problem is that I used Delphi

Re: self = [super init], nil?

On Sat, May 8, 2010 at 7:45 AM, Joanna Carter wrote: > Unfortunately, "static" seems to have developed a mind of its own :-) As they say, it's not a new version of the C without an additional definition of "static"! --Kyle Sluder ___ Cocoa-dev mailing

Re: self = [super init], nil?

Joanna, You're right. On 08/05/2010, at 11:06, Joanna Carter wrote: > BTW, you should not declare id* as the return type, it should be simply id. > > - (id) init > { > if (self = [super init]) > { >// rest of initialisation > } > > return self; > } I made lots of mistakes in my exam

Re: self = [super init], nil?

On Sat, May 8, 2010 at 10:00 AM, Flavio Donadio wrote: > > - (id)init > { >        self = [super init]; >        // blah blah blah ... >        return self; // return type will be NSObject!! > } NO! Please reread the fundamental ObjC documentation. And remember, you must *always* reassign self!

Re: self = [super init], nil?

Kyle, Thank Gosh you can't see my face now... I am blushing! Shame on me! I've been doing the wrong thing for ages! Cheers, Flavio On 08/05/2010, at 14:04, Kyle Sluder wrote: > On Sat, May 8, 2010 at 10:00 AM, Flavio Donadio wrote: >> >> - (id)init >> { >>self = [super init]; >>

Re: self = [super init], nil?

Kyle Sluder wrote (Saturday, May 8, 2010 8:48 AM -0700): It might produce less code, it might not. If you're operating at the ObjC level of abstraction and worrying about the codegen of self=[super init], your priorities are out of order. I'm a coding genius. My

Re: self = [super init], nil?

On Sat, May 8, 2010 at 10:35 AM, James Bucanek wrote: > There are completely legitimate reasons to want to optimize one's code, and > examining the overhead of -init seems perfectly rational to me. This seemed > to be the brunt of the original poster's question. My point throughout has been that

Re: self = [super init], nil?

Flavio Donadio wrote (Saturday, May 8, 2010 10:00 AM -0300): Let's say I create a subclass of NSObject (let's call it "MyOddObject") and override its -init method: - (id)init { self = [super init]; // blah blah blah ... return self; // return type will be NSObje

Re: self = [super init], nil?

Kyle Sluder wrote (Saturday, May 8, 2010 10:47 AM -0700): On Sat, May 8, 2010 at 10:35 AM, James Bucanek wrote: There are completely legitimate reasons to want to optimize one's code, and examining the overhead of -init seems perfectly rational to me. This seeme

Re: self = [super init], nil?

On May 8, 2010, at 12:35 PM, James Bucanek wrote: > Kyle Sluder wrote (Saturday, May 8, 2010 8:48 > AM -0700): > >> It might produce less code, it might not. If you're operating at the ObjC >> level of abstraction and worrying about the codegen of self=[super init

Re: Determining when dragging begins and ends

After playing around with stuff, I realized that this was probably the best option. It means tweaking my model slightly, but it'll probably be the better option in the long run. Thanks, Graham! Dave On May 7, 2010, at 11:07 PM, Graham Cox wrote: > Why not cache the count anyway? If it is tak

Re: self = [super init], nil?

Hi Henry > The forces of darkness won, and that's how Java now has rebarbative > terminology such as 'non-static method' to > mean 'instance method'. Observe carefully, Grasshopper: if you do not see > the word ''static' before a method, then > you know that it is a 'non-static method'.Y

Re: self = [super init], nil?

Hi Kyle > As they say, it's not a new version of the C without an additional > definition of "static"! :-) Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderat

How to do cancellable HTTP request using CFNetwork APIs

Hi All. I'm using CFNetwork APIs to create a cancellable web operation using the synchronous, non-blocking APIs like so: do { bytesRead = 0; if ( CFReadStreamHasBytesAvailable(inStream) ) { bytesRead = CFReadStreamRead(inStream, buffer, sizeof(buffer)); if ( bytesRea

isKindOfClass:

isKindOfClass: is an instance method and doesn't work on a class you get from NSClassFromString(). Apple docs: Returns a Boolean value that indicates whether the receiver is an instance of given class or an instance of any class that inherits from that class. for example, you can't do this:

Re: isKindOfClass:

On May 8, 2010, at 3:51 PM, Kevin Callahan wrote: > for example, you can't do this: > > Class classFromString = NSClassFromString(string); > > [classFromString isKindOfClass:[SomeClass class]]; > > I don't want to instantiate classFromString in order to check if it's a > subclass of SomeClass.

Re: isKindOfClass:

On May 8, 2010, at 12:51 PM, Kevin Callahan wrote: > isKindOfClass: is an instance method and doesn't work on a class you get from > NSClassFromString(). Hi Kevin, +[NSObject isSubclassOfClass:] is what you're looking for.

Re: isKindOfClass:

On May 8, 2010, at 12:59 PM, Andy Lee wrote: > On May 8, 2010, at 3:51 PM, Kevin Callahan wrote: >> for example, you can't do this: >> >> Class classFromString = NSClassFromString(string); >> >> [classFromString isKindOfClass:[SomeClass class]]; >> >> I don't want to instantiate classFromStrin

Re: isKindOfClass:

Try NSClassFromString(@"NSCFString"); --Waqar Sent from my iPad On May 8, 2010, at 12:51 PM, Kevin Callahan wrote: > isKindOfClass: is an instance method and doesn't work on a class you get from > NSClassFromString(). > > Apple docs: Returns a Boolean value that indicates whether the recei

Re: prevent drag from QTMovieView

did you try overriding the -mouseDragged: method in your subclass? On May 8, 2010, at 1:15 AM, Rainer Standke wrote: > Hello, > > I have a Collection View whose prototype view includes a QTMovieView. I need > the collection view to be a drag source, and that works fine. > > I need the QTMovieV

Re: isKindOfClass:

How on earth does this solve the poster's problem? More importantly it's relying on private API, so is very brittle. On 8 May 2010, at 21:04, Waqar Malik wrote: > Try NSClassFromString(@"NSCFString"); > > --Waqar > > Sent from my iPad > > On May 8, 2010, at 12:51 PM, Kevin Callahan wrote: >

Re: isKindOfClass:

On Sat, May 8, 2010 at 3:51 PM, Kevin Callahan wrote: > isKindOfClass: is an instance method and doesn't work on a class you get from > NSClassFromString(). Because NSObject is a root class (i.e. it has no superclass), you *can* send its -isKindOfClass: message to a Class object. Instance method

Re: isKindOfClass:

On Sat, May 8, 2010 at 5:14 PM, Sherm Pendley wrote: > On Sat, May 8, 2010 at 3:51 PM, Kevin Callahan wrote: >> isKindOfClass: is an instance method and doesn't work on a class you get >> from NSClassFromString(). > > Because NSObject is a root class (i.e. it has no superclass), you > *can* send

Re: Ticker Style Scrolling Text

Joachim- I managed to make do with just a custom NSView, but I've got another quick question. I noticed that in your app you don't bring up the NSStatusItem menu but rather a custom menu and I may have to do the same if I can't find a solution for the following: Currently I've taken my NSStatu