from:"mmalcolm crawford"



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

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 but a
bunch are from users saying they're having problems with said code...

Results 3, 4 and 5 don't seem to be related at all...
Am I missing something obvious??
Don't get me wrong, I really don't mind a RTFM style reply, but I
did search google and cocoa builder for that one and couldnt find
anything that seemed to work...

Well, the second link from the first search and the first link from
the second search point indirectly and directly to http://homepage.mac.com/mmalc/CocoaExamples/controllers.html
which contains:

With and Without Bindings
Shows a custom array controller that implements table view data source
methods to support drag and drop, including copying objects from one
window to another, drop of URLs, and re-ordering of the content array.
This example contains two implementations: the first uses
standardNSTableView data source methods, the second uses bindings.

Bookmarks
This is the original version of With and Without Bindings, and is
slightly more advanced. It shows a custom array controller that
implements table view data source methods to support drag and drop,
including copying objects from one window to another, drop of URLs,
and re-ordering of the content array.
This example only contains a bindings implementation, but supports
multiple items in a drag, whereas the With and Without Bindings
example does not; it also allows copying as well as moving within a
table.

which seem to do what you want to do.

mmalc
___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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...
It seems like when they are saying re-ordering they mean column  
sorting, which I can do just fine... but definitely not drag and  
drop re-ordering..


WithAndWithoutBindings illustrates drop at an arbitrary location in  
the destination;
Bookmarks (http://homepage.mac.com/mmalc/CocoaExamples/ 
Bookmarks.zip) provides a complete implementation of an array  
controller that supports drag and drop and reordering.


mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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

2008-11-23 Thread mmalcolm crawford



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 admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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

2008-11-22 Thread mmalcolm crawford



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) {
   // set outlets to nil
   }
   [super didReceiveMemoryWarning];
}

but this has the disadvantages that (a) in some situations it will  
cause the view to be loaded before it is subsequently unloaded, and  
(b) it isn't future proof.




mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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

2008-11-22 Thread mmalcolm crawford



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 moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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, (b) is something that the  
programmer should not care about, and (c) is not even true in the  
case of some methods, including [NSString string]

So I'll file a bug.

You will file a bug ?
I really do not see the bug here...


I do, and I already filed a bug.

Cocoa Fundamentals Guide states:

Class Factory Methods

Class factory methods are implemented by a class as a convenience for  
clients. They combine allocation and initialization in one step and  
return the created object autoreleased. These methods are of the form  
+ (type)className... (where className excludes any prefix).
http://developer.apple.com/documentation/Cocoa/Conceptual/CocoaFundamentals/CocoaObjects/chapter_3_section_6.html 



It should probably not explicitly state autoreleased — it should  
simply state that — in accordance with standard memory management  
rules, in a reference counted environment — the receiver does not own  
the returned object.



mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 discussion.  As others have  
also said, you should be thinking simply in terms of ownership, not in  
terms of whether or not something is autoreleased per se.  Changing  
the documentation will help prevent a counter-productive line of  
thinking.


mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 programming.


Whether for newcomers or not, though, the documentation should not be  
misleading or wrong.  In this case, it's at least misleading (if for  
no other reason than that it encourages an unproductive line of  
thought).



I agree, but what would you have the documentation say ?

Per my previous reply, it should simply state that — in accordance  
with standard memory management rules, in a reference counted  
environment — the receiver does not own the returned object.


That accurately describes the situation in all cases, and doesn't  
encourage the reader to unnecesarily and unproductively start thinking  
about autorelease.


mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 breakpoint inside the dealloc in the same file as  
applicationDidFinishLaunching, run your app and press the home button.
Never called, and purposely so - the application finishes anyway, so  
why spend cycles deallocating small blocks one-by-one when you can  
just throw away all memory the app used in one block...


I'm perfectly well aware of that optimisation; as an unconstrained  
statement, however, dealloc never get's called at all on the iPhone  
is untrue.  There are many situations when dealloc *will* be called,  
and so you should take that into account.




Because:
Cocoa strongly advocates you use accessor methods to set instance  
variables(*);
You are discouraged from setting instance variables directly  
anywhere other than in initializers and dealloc(*);

For me, applicationDidFinishLaunching IS an initializer...

You're free to hold your own views; as far as Cocoa is concerned,  
however, it is *not* an initialiser.




On iPhone in particular, you should avoid the use of autorelease.
The latter point in particular means that this alternative:
  self.viewController = [[[UIViewController alloc]
   initWithNibName:@MoveMeView bundle:[NSBundle  
mainBundle]] autorelease];

does not follow best practice.
Thus -- almost by a process of elimination -- you're left with the  
pattern shown in iPhone samples.


I stick with my applicationDidFinishLaunching implementation - 1  
line instead of 3.


Again you're welcome to do so, and you're welcome to deal with any  
bugs that arise as a result.


Of cause you're right were it some other method which could be  
called more than once and not applicationDidFinishLaunching, which  
is only called once and - as stated above - never paired with  
dealloc (however, applicationWillTerminate is called).



@interface MyObject : MySuperClass {
NSString *string;
}
@property (nonatomic, retain) NSString *string;
@end;

@implementation MyObject
@synthesize string;

- (id)init {

if (self = [super init]) {
// a poor example for several reasons, but take this just as  
a way

// to crease a new, owned, object
string = [[NSString alloc] initWithFormat:@now: %@, [NSDate  
date]);

}
return self;
}

- (void)applicationDidFinishLaunching:(UIApplication *)application {

string = [[NSString alloc] initWithFormat:@now: %@, [NSDate  
date]);

}

You just leaked the first value of string.

And to preempt the assertion that this would never happen --  
precisely this *did* happen to someone else who made exactly your  
point, within a week of their having made it.


mmalc




___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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


Context:

UIViewController provides a method, didReceiveMemoryWarning, which is  
invoked on view controllers when the amount of memory available to the  
application is severely constrained.  The goal of the method is to  
allow view controllers to dispose of resources that are currently not  
needed and that can be recreated later if required.  One such resource  
is the view controller's view itself.  Assuming that it does not have  
a superview, the view is disposed of ([self setView:nil];).


A issue arises in that outlets to elements within the nib file are  
typically declared as follows:


@property (nonatomic, retain) IBOutlet ElementClass *element;

Thus even though the main view is disposed of, absent any further  
action the outlets are still retained.  This is not in and of itself a  
problem -- if and when the main view is reloaded, they will simply 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:) which is more future-proof but is in  
many respects academically unsatisfying.




- (void)setView:(UIView *)aView;
{
if (!aView) {
// set outlets to nil, e.g.
self.anOutlet = nil;
}
// Invoke super's implementation last
[super setView:aView];
}


Unfortunately, although in principle this is correct, in practice it  
may fall foul of another issue.


Because UIViewController currently implements its dealloc method using  
the setView: accessor method (rather than simply releasing the  
variable directly...), self.anOutlet = nil will be called in dealloc  
as well as in response to a memory warning... This will lead to a  
crash in dealloc.


The remedy is to ensure that outlet variables are also set to nil in  
dealloc:


- (void)dealloc {
// release outlets and set variables to nil
[anOutlet release], anOutlet = nil;
[super release];
}


The iPhone engineering team is aware of this issue (read: There is no  
need to file bugs on this).


mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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  
in dealloc since that's supposed to be bad practice.  Has a bug been  
filed against that too?



Yes.

The remedy is to ensure that outlet variables are also set to nil  
in dealloc:


- (void)dealloc {
  // release outlets and set variables to nil
  [anOutlet release], anOutlet = nil;
  [super release];
}
That is indeed a workaround, but one of the reasons I moved towards  
using accessors instead (i.e. I didn't have to think about all the  
edge cases where clearing out the ivar was absolutely necessary; the  
accessor always does the right thing).


I would suggest that releasing then setting the variable to nil is a  
better strategy than using the accessor.



Now then, two things...
(1) In my personal code, I'm the only developer and do not integrate  
with any third party code (I only use Apple's SDKs directly).   
Having said that, I do have full control over my own objects and  
thus don't have any pitfalls in using accessors in inits and/or  
deallocs.




That's fine; if you're *sure* you'll never run into a problem such as  
this...


(2) But, I can see where in the general case, this is becoming quite  
problematic for folks.  After all, it's always dangerous to base  
your code on implementation details such as these.



... indeed, this is why best practice is given as such.

mmalc



___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 name, isn't it?


No, it's because it hasn't been updated.


That example declares dozens of IBOutlet's, whose properties are
(nonatomic,retain) and doesn't release any of them in its dealloc.


That's a bug (filed).

mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 viewController is a member of the class, you don't need the  
self..


In the original case you *do* need self. to ensure that the accessor  
method is invoked.



So why the local var?
3 lines of code instead of 1...
Isn't a main goal of Cocoa to write *less* code?


Because:
Cocoa strongly advocates you use accessor methods to set instance  
variables(*);
You are discouraged from setting instance variables directly anywhere  
other than in initializers and dealloc(*);

On iPhone in particular, you should avoid the use of autorelease.

The latter point in particular means that this alternative:

self.viewController = [[[UIViewController alloc]
initWithNibName:@MoveMeView bundle:[NSBundle  
mainBundle]] autorelease];


does not follow best practice.

Thus -- almost by a process of elimination -- you're left with the  
pattern shown in iPhone samples.


mmalc



(*) Same combined point for both:

You need to take account of memory management semantics, which might  
potentially change over time -- your example should be:


[viewController release];
viewController = [[UIViewController alloc]
initWithNibName:@MoveMeView bundle:[NSBundle  
mainBundle]];


Moreover, the accessor might have side-effects that you're then  
sidestepping (this is particularly true for KVO/bindings).




___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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.


http://www.google.com/search?client=safarirls=en-usq=Binding+a+Core+Data+string+value+to+an+NSTextViewie=UTF-8oe=UTF-8 



- e.g. NSTextField - Dev Archives, Cocoa Bindings Examples and Hints

mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 mechanism uses these methods.
It is precisely by using these methods that you avoid violation of  
encapsulation (notably on the desktop, where otherwise the instance  
variables may be set directly).
Further, as others noted, if you want to avoid declaring the  
properties publicly as read/write, you can declare then as read-only  
then re-declare them as read/write in a private extension.
Moreover it precisely avoids errors by providing a consistent pattern  
that will work across all platforms and that you can use without  
having to think about it.  As we seem to agree, having to think about  
how to declare/use outlets per se is a waste of mental effort.



That's the reason I didn't do this earlier.  The one little  
paragraph in the documentation that addresses this says I 'should'  
do it this way but doesn't explain why.


Because it should be obvious from a memory management perspective why  
this is the case.  And the documentation typically tries to avoid  
repeating the basic rules of memory management.



I'll point out that the paragraph that explains memory management of  
outlets on Mac OS X on that page is half the length of the iPhone  
paragraph, and I'd maintain that the iPhone paragraph isn't long  
enough.


I don't see what's missing from the iPhone discussion.  You're told  
that although the nib-loading mechanism doesn't retain the outlets  
directly, it uses KVC to set the outlets and what the ramifications  
are of that...



However, UIViewController has the ability to unload its view  
outlet in response to a memory warning.  Any subclass should also  
release its outlets in response to the memory warning, if the base  
class releases its view, but not otherwise.  So now there are  
three places to manage the memory of these outlets. The problem is  
that the base class doesn't always release its view in response to  
a memory warning and as far as I can tell the subclass has no  
clean way of telling if the view will be released or has been  
released.  That's the problem.


You're shifting the goalposts; this is not the problem you  
originally described.


It's not me who has shifted the goalposts.  The whole playing field  
was moved out from under me when it was decided to retain outlets by  
default, which is different from how this all works on Mac OS X.


No, it's not.  Again as the documentation points out, exactly what  
happens on Mac OS X depends on the context.  Most outlets are indeed  
not retained, but top-level objects *are* retained (so you do need to  
release them).  What The Nib Object Life Cycle doesn't mention --  
but probably should -- is that this is further complicated by what is  
the superclass of File's Owner -- if it's NSDocument,  
NSWindowController, or NSViewController, then you don't have to  
release top-level objects.


As I wrote originally, this is a mess, and requiring developers to  
think about this every time they make connections is unproductive.   
Which is why having a simple, consistent, approach that can be applied  
pervasively is beneficial.  As ever, you are free to deviate from that  
if you want to expend additional mental effort...



You can add to your list of problems 'insufficient documentation  
and education of memory management of outlets.'



It remains unclear in what respect the document is insufficient.


There are several issues:
The template clearly indicates what should be done:
Obviously the client code can't touch _view or self.view in  
didReceiveMemoryWarning.  That's why I said upthread that there's no  
clean way for the client code to tell if the view will be unloaded  
or has been unloaded.



Yes, there is...



In theory, you should simply check whether the view has a superview:
but since _view is declared as @package, you can't do that.
You could invoke 'view':
but this has the disadvantages that (a) in some situations it will  
cause the view to be loaded before it is subsequently unloaded, and  
(b) it isn't future proof.

self.view will always be non-nil.

[self.view superview] may, however, be nil, and this is what's  
important.
If you use this test, then you might temporarily load some unwanted  
objects which in the context of a memory warning is counter-productive  
but in most cases the overhead -- if any -- should be minor compared  
with the data you're expunging.  Nevertheless this is ultimately  
unsatisfactory.



This is why I 'shifted the goalposts.'  There are many issues  
related to memory management of outlets on iPhone.  Suggesting that  
everyone just follow your best practice described at the top  
obviously isn't sufficient.


On the contrary, following the best practice is sufficient, as

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  
really
feel glued on, at this point, rather than being a language feature  
that

the whole compiler knows about)


It's not clear how this is relevant to the implementation of dealloc?

mmalc


___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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, rather than being a language feature  
that

the whole compiler knows about)

It's not clear how this is relevant to the implementation of dealloc?

Because there's essentially no good way to dispose of properties given
the way that they're implemented.


I'm not sure why this is the case?
You send a release message to instance variables for which there is a  
corresponding retain or copy property.


If you set them to nil, then you fall afoul of overridden setters  
and the like.

If you manually release them, then you explode if you later change the
property from assign to retain or vice versa.


But you have the same problem without properties.
Except that it's worse; you could change the implementation of an  
accessor method (to assign rather than retain, for example), and you'd  
have no cross-check to make sure you then did the right thing in  
dealloc.


With properties, you have a clear set of statements that publicly  
declare what are the memory management semantics, and you can cross- 
check them with your dealloc method.



There should be a way to take advantage of the built-in property
mechanism to simply say do the right thing for this property,
ideally in a single call for an entire class, or even better yet
wholly automatically as part of NSObject's -dealloc implementation or
something.

That certainly might be a welcome feature -- I'd encourage you to file  
an enhancement request.



But instead, you get good support for synthesized setters
and getters but once you step into -dealloc you're back on your own,
losing a big part of the advantage, at least if you aren't willing to
hold your nose a bit and simply set them to nil despite the warnings
against it.

Again, this doesn't seem like a regression, it's just something that  
could perhaps be taken advantage of.  You've had to put up with worse  
up until now.


mmalc


___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 sure that you use the appropriate decorator, and  
you potentially run the risk of accessing dangling pointers --  
something that's typically going be a more significant issue than not  
disposing of an object at an opportune moment...


As noted previously, the goal with best practice here is precisely to  
relieve you of having to think about such banalities(*).
If you simply follow best practices, you get a good pattern that won't  
cause a crash and that allows you to concentrate on more important  
aspects of your application.


Dealing with memory warnings is a slightly special case that's arisen  
fairly early on in the lifetime of a new platform.
As an issue, it doesn't have any direct bearing on what is in general  
the best way to deal with outlets -- it's largely orthogonal.
It should be managed better than it is now, and hopefully it will be  
in the future.  In a way that doesn't require great mental effort to  
get right.


mmalc





(*) I'm grateful to Henry for having pointed me to an apposite  
quotation from Alfred North Whitehead:


It is a profoundly erroneous truism, repeated by all copy-books and  
by eminent people when they are making speeches, that we should  
cultivate the habit of thinking of what we are doing. The precise  
opposite is the case. Civilization advances by extending the number of  
important operations which we can perform without thinking about them.  
Operations of thought are like cavalry charges in a battle--they are  
strictly limited in number, they require fresh horses, and must only  
be made at decisive moments.

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 when this will happen is in practice  
unpredictable, which is why you need to retain the object before  
doing anything else with it.



This is at best misleading.

*Please*, don't try to reformulate the memory management rules when  
answering a question.
The more time goes by, the more I am convinced that most developers'  
confusion about memory management arises from other developers'  
misleading or incorrect answers to questions such as this.


Simply point to the canonical reference material (Kyle's answer  
provides a great model):



Read this document:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Concepts/ObjectOwnership.html#//apple_ref/doc/uid/2043-BEHDEDDB
Then read this one:
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/Tasks/MemoryManagementRules.html
[...]



mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 implemented.

I'm not sure why this is the case?
You send a release message to instance variables for which there is a
corresponding retain or copy property.

This does not qualify as good in my book. A fundamental of good
programming is once and only once. You've now described the
semantics of these properties in two different places in your code
and, worse, one of those places is implicit rather than explicit.


I'm not sure what you mean here?
There is only one place where the semantics are described: In the  
property declaration.
Whether you release or not in dealloc is a corollary of that  
declaration.



But you have the same problem without properties.
Except that it's worse; you could change the implementation of an  
accessor

method (to assign rather than retain, for example), and you'd have no
cross-check to make sure you then did the right thing in dealloc.
With properties, you have a clear set of statements that publicly  
declare
what are the memory management semantics, and you can cross-check  
them with

your dealloc method.

This is true but I don't really see the point. I never said properties
were worse than manual accessors, just that this omission really hurts
their utility.


In which case we may be mostly in violet (sic) agreement.
I obviously see significant benefits to using properties, and agree  
that their utility *might* be enhanced if they could also handle  
dealloc.  I got the impression that others here were suggesting that  
they provide little or no benefit at all...


mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 has the modifier  
IBOutlet in front of it, as in:

@interface AppController : NSObject {
   IBOutlet NSTextField *myTextField;
   ...
}


Going forward, you're encouraged to declare outlets as follows:

@interface AppController : NSObject {
   NSTextField *myTextField;
   ...
}

@property (nonatomic, retain) IBOutlet NSTextField *myTextField;


http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/Articles/chapter_5_section_3.html 



mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 permission):

One remaining question. Are you expected to release the outlet when  
your

controller is dealloc'd?  And did you have to prior to properties?
I believed the answer to the latter was no but I'm prepared to be
wrong on that..


Since the property is declared with the 'retain' attribute, the memory  
management semantics are made clear here.  Yes, you should release the  
outlet in dealloc.


The problem heretofor was that the story was a mess -- whether or not  
you released the outlet was dependent upon what class File's Owner  
inherited from, and whether or not you had accessor methods.  The  
principal advantage with the property-based pattern is that memory  
management is consistent across all classes across all patterns.  It  
will also work on modern runtimes that use instance variable synthesis  
(where there may be no instance variable declaration with which to  
attach the IBOutlet).


There may be some variation; if you have a delegate that may be  
connected using a delgate, then you may have:


@interface AppController : NSObject {
  id delegate;
  ...
}
@property (nonatomic, assign) IBOutlet id delegate;

although again use of a property declaration makes the memory  
management semantics clear (in this case you would of course not  
release delegate in dealloc).



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 UIViewController whose view is  
released in didReceiveMemoryWarning. To ensure that you don't prolong  
the lifetime of objects you got from the nib, you should set (use your  
accessor methods to) set those variables to nil in the relevant  
method, e.g.:


@interface MyController : UIViewController {
  UILabel *label;
  ...
}
@property (nonatomic, retain) IBOutlet UILabel *label;

then

- (void)didReceiveMemoryWarning {
self.label = nil;
[super didReceiveMemoryWarning];
}


mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 UIViewController whose
view is released in didReceiveMemoryWarning. To ensure that you
don't prolong the lifetime of objects you got from the nib, you
should set (use your accessor methods to) set those variables to
nil in the relevant method, e.g.:

@interface MyController : UIViewController {
UILabel *label;
...
}
@property (nonatomic, retain) IBOutlet UILabel *label;

then

- (void)didReceiveMemoryWarning {
self.label = nil;
[super didReceiveMemoryWarning];
}

OK, this issue has come up for me very recently. It appears that on
iPhoneOS IBOutlets are retained, regardless of the presence of
properties.

No, on iPhone outlets are consistently *not* retained -- which is
precisely why you do need to retain top-level objects on iPhone. But
absent accessor methods, connections are made using KVC...

This is documented here:
http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/chapter_3_section_4.html#//apple_ref/doc/uid/1051i-CH4-SW6

Even worse, in the presence of an assign property the outlet is
still retained. Whatever code is retaining the outlets never
releases them. So it seems that client code must release all outlets.

As I stated originally, following the pattern I describe above makes
memory management consistent in all situations.

The documentation on this is vague, with a lot of 'should's and not
clear statements of what really happens.

The documentation at http://developer.apple.com/iphone/library/documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/chapter_3_section_4.html#//apple_ref/doc/uid/1051i-CH4-SW6
is explicit, there are just many different situations to consider
if you don't follow the property pattern.

mmalc

Actually this isn't (only) related to didReceiveMemoryWarning (which
I hadn't considered related to this problem until you raised it).

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 why using properties simplifies matters...

mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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's consistent...

mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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 supposed to disappear.
If you have a strong reference you want to make sure that the item is  
disposed of when the other items from the nib go away; if you have a  
weak reference you want to make sure you don't send a message to a  
deallocated object (it'll go when the view goes...).


mmalc

___

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.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [EMAIL PROTECTED]

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