Re: NSArrayController setSelectedObjects: not working with newly created objects

On Dec 7, 2008, at 8:29 AM, Matteo Manferdini wrote: NSManagedObject *newObject = [arrayController newObject]; [arrayController setSelectedObjects:[NSArray arrayWithObject:newObject]]; If I call [arrayController selectedObject] just before these two lines, the array returned contains the ac

Re: Array Controller Add method question

On Dec 6, 2008, at 7:15 PM, [EMAIL PROTECTED] wrote: I'm using an Array Controller's Add method wired to a button to enable text data entries into a table. How do I set the table to activate it's top row when pressing the Add button in preparation for input? At this point if the table cont

Re: Cleanup inside a failed init method

mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or mode

Re: self = [super init];

On Dec 3, 2008, at 2:14 PM, EVS wrote: Why does the above line of code not cause a memory leak or memory fault? This may be of interest: mmalc

Re: Can I split an implementation file?

On Nov 27, 2008, at 9:09 AM, Greg Robertson wrote: Thanks for the link, one last question (I hope) if I declare foo as a property and synthesize then I could use a category to override the foo and setFoo. But I was wondering if I could just skip the synthesize? If your intent is to provide cus

Re: NSTableView Drag-Drop re-ordering...

On Nov 26, 2008, at 2:02 AM, Jean-Nicolas Jolivet wrote: Sorry for not spotting that one earlier... I thought WithAndWithoutBinding was basically the same example only more recent...! I've updated the descriptions to try to make it more clear. mmalc _

Re: NSTableView Drag-Drop re-ordering...

On Nov 26, 2008, at 1:42 AM, Jean-Nicolas Jolivet wrote: mmm interesting, I did download WithAndWithoutBindings before posting but it doesn't seem to implement drag and drop re- ordering... not in the WithBinding version at least... I'm trying it right now and it's definitely not working...

Re: NSTableView Drag-Drop re-ordering...

On Nov 26, 2008, at 12:37 AM, Jean-Nicolas Jolivet wrote: Well it depends on which example you're talking about... you posted a google search result... The first link (a cocoa builder link) has nothing to do with row re- ordering... The second link (CocoaDev one) has a bunch of code examples

Re: NSTableView Drag-Drop re-ordering...

On Nov 26, 2008, at 12:06 AM, Jean-Nicolas Jolivet wrote: What I can't find is good info about re-ordering the table row with drag and drop, and I did search google for the obvious key words (NSTableView drag drop order, NSTableView re-order etc etc..) Did you look at the example? mmalc

Re: NSTableView Drag-Drop re-ordering...

On Nov 25, 2008, at 11:26 PM, Jean-Nicolas Jolivet wrote: I'm pretty sure this has been covered before, however I can't find any good examples on how to implement it??

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 22, 2008, at 8:29 AM, mmalcolm crawford wrote: Let me check on this one. It seems that, for various reasons, the setView: approach is still preferred. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 22, 2008, at 8:16 AM, mmalcolm crawford wrote: [...] Sorry, pressed Deliver on the wrong message by mistake. Let me check on this one. mmalc ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 22, 2008, at 7:58 AM, James Montgomerie wrote: if(self.anOutlet && !self.view.superview) { On Nov 19, 2008, at 12:59 AM, mmalcolm crawford wrote: You could invoke 'view': - (void)didReceiveMemoryWarning { if ([self.view superview] == nil) { //

Re: Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

On Nov 21, 2008, at 5:21 PM, Ricky Sharp wrote: But, that's only if dealloc releases objects directly and doesn't use accessors or use the workaround shown below. Yes, although following "best practice" is assumed... :-) I'm now really curious as to why UIViewController uses an accessor

Responding to view controller memory warnings (was Re: Outlets / IBOutlet declarations)

y be replaced -- but it does mean that the beneficial effect of the didReceiveMemoryWarning is reduced. There are, currently, a couple of possible remedies... On Nov 19, 2008, at 12:59 AM, mmalcolm crawford wrote: This leaves us for now with two solutions: (a) Greg's (override setView:)

Re: release and reference counting query

On Nov 21, 2008, at 11:15 AM, Marc Stibane wrote: Am 19.11.2008 um 10:05 schrieb mmalcolm crawford: On Nov 18, 2008, at 10:33 AM, Marc Stibane wrote: Lets forget for a moment that the dealloc never get's called at all on the iPhone This is simply untrue. Nope. Try to set a break

Re: Autorelease Question

On Nov 21, 2008, at 7:59 AM, Filip van der Meeren wrote: Sorry to be this crude, but the documentation isn't created for beginners. Sorry to be blunt, but some of it is. And Cocoa Fundamentals in particular is intended for newcomers to the platform and comparative newcomers to programmi

Re: Autorelease Question

On Nov 21, 2008, at 7:56 AM, Filip van der Meeren wrote: I quote: "For objects that never get released, this method should return UINT_MAX". So where do you see your bug ? The bug is in the description, and the expectations it gives rise to. There should be no need for any of this discussi

Re: Autorelease Question

On Nov 21, 2008, at 7:33 AM, Filip van der Meeren wrote: Ok, so my point with all this is that the documentation should not say that all class factory methods always return autoreleased objects because that is an implementation detail that (a) is not required by the memory management rules

Using properties (was Re: Outlets / IBOutlet declarations)

On Nov 19, 2008, at 8:40 PM, Michael Ash wrote: On Wed, Nov 19, 2008 at 5:41 PM, mmalcolm crawford <[EMAIL PROTECTED] > wrote: On Nov 19, 2008, at 2:29 PM, Michael Ash wrote: Because there's essentially no good way to dispose of properties given the way that they're imple

Re: Autorelease Question

On Nov 19, 2008, at 3:07 PM, DKJ wrote: In general, if you retain an object, or use a either a "copy" or an "init..." method to obtain it, you need to release it yourself when you're done with it. Otherwise, you can assume that the object will dispose of itself at some future time. But w

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 19, 2008, at 1:57 PM, Brian Stern wrote: I'm starting to think that maybe using the assign properties is the better way to handle this. That's certainly one approach, and one that was considered. The problem is that you then have to think through every outlet declaration to make s

Re: Outlets / IBOutlet declarations (was Re: Interface Builder &Wiring Objects)

On Nov 19, 2008, at 2:29 PM, Michael Ash wrote: On Wed, Nov 19, 2008 at 5:18 PM, mmalcolm crawford <[EMAIL PROTECTED] > wrote: On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote: (This is the one thing I hate the *most* about properties - they really feel glued on, at this point, rathe

Re: Outlets / IBOutlet declarations (was Re: Interface Builder &Wiring Objects)

On Nov 19, 2008, at 1:57 PM, Jeff Laing wrote: My understanding (and I'm a noob in this) is that "best practices" recommend that you shouldn't start sending additional messages to an object from inside its dealloc. Correct. (This is the one thing I hate the *most* about properties - they re

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 19, 2008, at 7:00 AM, Brian Stern wrote: There are competing issues. Following this best practice forces me to add public properties for all my outlets that my code never uses. This violates encapsulation and seems wasteful and error-prone. No, it's not. The nib-loading mechanis

Re: Binding a CoreData string value to an NSTextView

On Nov 18, 2008, at 8:42 PM, John Joyce wrote: Has anyone had any success Binding a CoreData string value to an NSTextView? Everything I try seems to be flumoxed by the NSAttributedString of the NSTextStorage backing store.

Re: release and reference counting query

On Nov 18, 2008, at 10:33 AM, Marc Stibane wrote: Lets forget for a moment that the dealloc never get's called at all on the iPhone This is simply untrue. viewController = [[UIViewController alloc] initWithNibName:@"MoveMeView" bundle:[NSBundle mainBundle]]; since "viewC

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 17, 2008, at 9:33 PM, Jeff Laing wrote: How about: http://developer.apple.com/samplecode/CacheInfo-MacOSX/listing1.html (for example) which has the IBOutlet tag on the instance variables rather than the properties; I'll bet its different because properties and instance vars have the same

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 18, 2008, at 10:01 AM, Brian Stern wrote: OK Erik, I'll bite. What you describe above is correct as far as it goes. However, when you say all the memory management is handled in one place, of course it's two. The object has to be released. The normal place to release objects is

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 17, 2008, at 8:53 PM, Brian Stern wrote: Here's my test project: http://bellsouthpwp2.net/b/r/brians99/projects/TestPropertiesAndOutlets.zip There are three labels that are outlets. One has a retain property, one an assign property, and the third no property. Unless they are releas

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 17, 2008, at 8:34 PM, Brian Stern wrote: Don't you find it odd that you need to release outlets in didReceiveMemoryWarning? Not at all -- assuming that you have a reference -- strong or weak -- to an item in the user interface, you want to make sure you break it if the view is sup

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 17, 2008, at 8:17 PM, Brian Stern wrote: I think it makes more sense to release the Outlets in viewDidLoad. This way I only have to release them in one spot, not two. No, it doesn't. There is no sense at all in releasing outlets in viewDidLoad. Follow the pattern I described and it'

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 17, 2008, at 8:05 PM, Roland King wrote: The iPhone version of nib unarchiving and hookup seemed very consistent to me, it makes use of properties or setFoo: if you have them, allowing you to manage objects any way you like. This applies to both iPhone and Mac OS X/desktop. This is

Re: Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 17, 2008, at 7:12 PM, Brian Stern wrote: On Nov 17, 2008, at 9:11 PM, mmalcolm crawford wrote: One other consideration, particularly in iPhone applications, is where you might have outlets to subviews of a main view that might be released in sime situations -- e.g. a

Outlets / IBOutlet declarations (was Re: Interface Builder & Wiring Objects)

On Nov 17, 2008, at 3:06 PM, mmalcolm crawford wrote: Going forward, you're encouraged to declare outlets as follows: @interface AppController : NSObject { NSTextField *myTextField; ... } @property (nonatomic, retain) IBOutlet NSTextField *myTextField; Jeff asked (posted with permi

Re: Interface Builder & Wiring Objects

On Nov 17, 2008, at 1:46 PM, Andy Lee wrote: You don't have ivars "along with" outlets. An outlet *is* a particular kind of ivar. It's an object reference that is declared in such a way that IB recognizes it and allows you to assign its value graphically in IB. Typically the declaration

Re: overt and covert retain-release question (instigated by UIViewController on iPhone)

On Nov 12, 2008, at 10:00 AM, Stuart Malin wrote: - (void) loadVew { contentView = [[UIImageView alloc] initWithFrame]; ... self.view = contentView; [contentView release]; ... } *If* this is exactly the code shown, and contentView is an instance

Re: How to manage (My)SQL data in Cocoa

On Nov 10, 2008, at 12:39 PM, dreamcat7 wrote: Sorry maybe i should have clarified that but i believed that Quincey had already explained about the datasource methods. You *must* (if you dont want to end up in a heap of self-inflicted mess) represent your data in those way - WHEN you inten

Re: How to manage (My)SQL data in Cocoa

On Nov 10, 2008, at 7:36 AM, dreamcat7 wrote: For NSTableView you MUST follow Quincey's conventions for the data representation. No, you don't. Quincey's statement that "the most natural "fit" with a NSTableView would probably be an array of dictionaries" is true, but there is no *need*

Re: Help with this crashing method

On Nov 9, 2008, at 9:03 PM, Andre Masse wrote: [userDict setObject:[NSImage imageNamed:NSImageNameUser] forKey:@"userImage"]; "A default’s value must be a property list, that is, an instance of (or for collections a combination of instances of): NSData, NSString, NSNumber, NSDate, NSArr