Re: Connecting a button to MyView zeros integers

[Roland King]

I have no idea what stackoverflow is suggesting here but it looks entirely 
wrong as usual for that junky site. You're just creating a standalone I 
referenced object. 

Right click your view in IB then wait a second and right click it again. I 
think it's right clicks. You will then get the outlet panel which is the grey 
HUD display with all the outlets and actions. You can drag connect to your 
buttons. There's some ctrl alt shift cmd combo which does this too but I never 
remember it. You can still connect view outlets as before, just that ctrl-drag 
was repurposed a couple of xcodes ago for auto layout so you have to work a 
little harder to get the inspector up. 



> On 7 Feb 2015, at 10:22, N!K  wrote:
> 
> 
> I would like to connect a button to MyView class, but Xcode 6.1.1 only allows 
> control-dragging a button to AppDelegate to create an IBAction. I have not 
> encountered this previously. Looking for a workaround, I found this 
> recommendation in a couple of Stack Overflow and other web pages as well as a 
> YouTube video. It enables the button to work, but unfortunately it zeros all 
> the integers in MyView.
> 
> The recommendation is:
> 1. Drag an empty Object from the IB library to the column of blue icons.
> 2. Set its class to MyView.
> 3. Control-drag from the button to MyView.m
> 4. Fill in the name (“act”) in the popup.
> This puts the IBAction template into MyView, ready to fill in.
> 
> #import "MyView.h"
> 
> @implementation MyView
> 
> - (id)initWithCoder:(NSCoder *)aDecoder
> {
>self = [super initWithCoder:aDecoder];
>if (self) {
>iii=1000;
>k=99;
>}
>return self;
> }
> 
> - (IBAction)act:(id)sender {
>iii=iii+1;
>NSLog(@"  iba i= %i",iii);
> }
> 
> 
> In MyView.m, iii=1000 is initialized in initWithCoder. At the breakpoint 
> after IBAction, iii is seen in both places to have the value 1, not 1001,  by 
> hovering. It was zeroed and then incremented after clicking on Button in the 
> View. Similarly, k is initialized to 99 and then zeroed. Both are ivars in 
> MyView.h.
> 
> Clearly, zeroing all the integers is not acceptable. Can this approach be 
> saved? Having the IBAction in MyView is desirable for directly relating its 
> functions to the rest of MyView, rather than indirectly from AppDelegate. On 
> the other hand, Xcode may have very good reasons – unknown to me – for 
> restricting IBAction to AppDelegate. Maybe timing?
> 
> Thanks in advance,
> 
> Nick
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/rols%40rols.org
> 
> This email sent to r...@rols.org

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Connecting a button to MyView zeros integers

[N!K]

I would like to connect a button to MyView class, but Xcode 6.1.1 only allows 
control-dragging a button to AppDelegate to create an IBAction. I have not 
encountered this previously. Looking for a workaround, I found this 
recommendation in a couple of Stack Overflow and other web pages as well as a 
YouTube video. It enables the button to work, but unfortunately it zeros all 
the integers in MyView.

The recommendation is:
1. Drag an empty Object from the IB library to the column of blue icons.
2. Set its class to MyView.
3. Control-drag from the button to MyView.m
4. Fill in the name (“act”) in the popup.
This puts the IBAction template into MyView, ready to fill in.

#import "MyView.h"

@implementation MyView

- (id)initWithCoder:(NSCoder *)aDecoder
{
self = [super initWithCoder:aDecoder];
if (self) {
iii=1000;
k=99;
}
return self;
}

- (IBAction)act:(id)sender {
iii=iii+1;
NSLog(@"  iba i= %i",iii);
}


In MyView.m, iii=1000 is initialized in initWithCoder. At the breakpoint after 
IBAction, iii is seen in both places to have the value 1, not 1001,  by 
hovering. It was zeroed and then incremented after clicking on Button in the 
View. Similarly, k is initialized to 99 and then zeroed. Both are ivars in 
MyView.h.

Clearly, zeroing all the integers is not acceptable. Can this approach be 
saved? Having the IBAction in MyView is desirable for directly relating its 
functions to the rest of MyView, rather than indirectly from AppDelegate. On 
the other hand, Xcode may have very good reasons – unknown to me – for 
restricting IBAction to AppDelegate. Maybe timing?

Thanks in advance,

Nick
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Greg Parker]

> On Feb 6, 2015, at 3:27 PM, Jens Alfke  wrote:
> 
>> On Feb 6, 2015, at 2:00 PM, Greg Parker > > wrote:
>> 
>> Swift adds "unowned" references. These references are non-retaining. They 
>> differ from weak references and unsafe unretained references: unowned 
>> references fail with a runtime error if you try to access the pointed-to 
>> object after it has been deallocated.
> …
>> They are cheaper than weak references and safer than unsafe-unretained.
> 
> What makes them cheaper than weak references? It sounds like they both have 
> to do the same bookkeeping to track whether the pointed-to object is alive; 
> the only difference is the behavior when accessing the reference after the 
> pointed-to object is dealloced (i.e. treating the pointer as nil vs. failing 
> with an error.) Both of those seem equivalent in complexity.

The weak reference system needs to keep track of every variable pointing to a 
particular object, and erase those variables when the object is deallocated. 
That is expensive.

The unowned reference system does not keep track of every unowned variable. 
Instead it keeps a count of unowned pointers to a particular object (basically 
a second reference count of unowned references). If an object's strong 
reference count reaches zero and its unowned reference count is not zero then 
the object's destructors are called but the storage itself is not freed. A 
zombie object is put in its place. If the unowned reference count later 
decreases to zero then the zombie is freed and everybody is happy. If an 
unowned reference is used and there is a zombie present, the runtime complains.

Unowned references are inefficient if a large object dies but an unowned 
reference to it lives on, because the object's memory won't be reclaimed until 
later. They are efficient when the pointed-to object lives as long or longer 
than the unowned reference variable.


-- 
Greg Parker gpar...@apple.com  Runtime 
Wrangler


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jens Alfke]

> On Feb 6, 2015, at 2:00 PM, Greg Parker  wrote:
> 
> Swift adds "unowned" references. These references are non-retaining. They 
> differ from weak references and unsafe unretained references: unowned 
> references fail with a runtime error if you try to access the pointed-to 
> object after it has been deallocated.
…
> They are cheaper than weak references and safer than unsafe-unretained.

What makes them cheaper than weak references? It sounds like they both have to 
do the same bookkeeping to track whether the pointed-to object is alive; the 
only difference is the behavior when accessing the reference after the 
pointed-to object is dealloced (i.e. treating the pointer as nil vs. failing 
with an error.) Both of those seem equivalent in complexity.

But maybe I'm off-base on how weak references are implemented… I'd love to see 
an explanation, actually.

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

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

This email sent to arch...@mail-archive.com

[CIImageAccumulator image]: getting the BMP representation destroys the image contents

[Nick]

Hello,
I am playing with the CIMicroPaint sample code (
https://developer.apple.com/library/mac/samplecode/CIMicroPaint). This is
basically a simple paint editor (you can draw on a view with a mouse using
CoreImage).

I would like to save whatever is drawn into a file. So what I do is call
this, when the save button is pressed:

-(IBAction)saveButton:(id)sender {

NSBitmapImageRep *bir = [[NSBitmapImageRep alloc] initWithCIImage:self.
imageAccumulator.image];

NSData *bmpData = [bir representationUsingType:NSBMPFileType properties:
nil]; //THIS LINE CORRUPTS THE CIImageAccumulator.image. WHY?

 [bmpData writeToFile:[@"~/test.bmp" stringByExpandingTildeInPath]
atomically:YES];

//NSImage *img = [[NSImage alloc] initWithData:bmpData];

//imageView.image = img;

}

This is the only code i added to the original Apple sample code.
The problem i have is that i can call representationUsingType only once to
get the bmpData that i can save to disk as an image.
If i draw something, and call it again later,  i will get the old image,
not the updated one. Also the commented imageView code shows the same
problem - the NSImageView gets updated only the first time, not the
subsequent times.

What can be the cause of this?
It really looks like a bug in Apple framework code. Or is it me doing
something wrong?

I have found similar problem/questions, but they hasn't been answered:

http://stackoverflow.com/questions/23009472/ciimage-converted-to-nsdata-or-nsimage-seems-to-lose-changes-made-to-the-ciimage

http://stackoverflow.com/questions/26075375/ciimage-obtained-from-ciimageaccumulator-after-converting-to-nsdata-is-corrupted

Thank you!
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Greg Parker]

> On Feb 6, 2015, at 1:48 PM, Jonathan Mitchell  wrote:
> 
>> On 6 Feb 2015, at 21:31, Greg Parker  wrote:
>> 
>>> Come to think of it, I'm surprised that AppKit delegates are still 
>>> unsafe-unretained. Why haven't these been converted to safe weak references 
>>> yet?
>> 
>> Some classes are incompatible with (safe zeroing) weak references. For 
>> example, any class that implements custom retain count storage needs 
>> additional code to work with weak references. That means AppKit needs to be 
>> careful about binary compatibility when it changes an unretained delegate to 
>> a weak delegate.
> 
> Does Swift avoid unsafe-unretained references entirely or does it rear its 
> head when interacting with Obj-C?

Swift has strong and weak references that work like ARC.

Swift adds "unowned" references. These references are non-retaining. They 
differ from weak references and unsafe unretained references: unowned 
references fail with a runtime error if you try to access the pointed-to object 
after it has been deallocated. They are intended for cases like views pointing 
back to superviews, where you need to avoid a retain cycle and you "know" the 
pointed-to object will still be alive whenever you use it. They are cheaper 
than weak references and safer than unsafe-unretained.

Swift supports unsafe references using things like the UnsafePointer class. 
Unsafe interactions with C and Objective-C use such classes, so you shouldn't 
get unsafe references by surprise.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jonathan Mitchell]

> On 6 Feb 2015, at 21:31, Greg Parker  wrote:
> 
>> Come to think of it, I'm surprised that AppKit delegates are still 
>> unsafe-unretained. Why haven't these been converted to safe weak references 
>> yet?
> 
> Some classes are incompatible with (safe zeroing) weak references. For 
> example, any class that implements custom retain count storage needs 
> additional code to work with weak references. That means AppKit needs to be 
> careful about binary compatibility when it changes an unretained delegate to 
> a weak delegate.
> 
Does Swift avoid unsafe-unretained references entirely or does it rear its head 
when interacting with Obj-C?

J
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jonathan Mitchell]

> On 6 Feb 2015, at 17:34, Jens Alfke  wrote:
> 
> 
>> On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell  
>> wrote:
>> 
>>  // remove observers
>>  // unregister for notifications
> 
> I have to confess I'm still not completely certain whether these are needed 
> under ARC. I remember reading something about at least one of these being 
> handled automatically, but I just skimmed through some docs now and couldn't 
> find anything. I tend to put these in my classes but always wonder whether I 
> strictly need to.

I was just checking whether I needed to manually unbind any bindings that I 
make manually.
Looks like I don’t, according to the fragment below from the 
NSKeyValueBinding.header.
Binding obviously involves observation and the header note makes it explicit 
that removing observers is recommended.
I think the one exception is self observation.
I think under GC observers may have been removed automatically - cannot quite 
recall.

Header note:

Bindings are considered to be a property of the object which is bound (the 
object the following two methods are sent to) and all information related to 
bindings should be retained by the object; all standard bindings on AppKit 
objects (views, cells, table columns, controllers) unbind their bindings 
automatically when they are released, but if you create key-value bindings for 
other kind of objects, you need to make sure that you remove those bindings 
when you release them (observed objects don't retain their observers, so 
controllers/model objects might continue referencing and messaging the objects 
that was bound to them).

Jonathan
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Greg Parker]

> On Feb 6, 2015, at 1:18 PM, Jonathan Mitchell  wrote:
> 
>> On 6 Feb 2015, at 20:46, Jens Alfke  wrote:
>> 
>> Come to think of it, I'm surprised that AppKit delegates are still 
>> unsafe-unretained. Why haven't these been converted to safe weak references 
>> yet?
> 
> I presume that AppKIt (all of it?) is not compiled using ARC and hence 
> doesn’t get weak reference tracking et al?

The weak reference machinery is available to non-ARC code by calling the 
runtime functions directly. The system is fragile if you write it by hand, 
though, so we don't generally recommend it.


> Why isn AppKit compiled using ARC? Probably because it has a track record as 
> it is and would likely gain nothing in a functional sense.

The primary reason is that there is no way to compile a single library that 
uses ARC and also supports GC. AppKit needs to support GC so it can't use ARC.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Greg Parker]

> On Feb 6, 2015, at 12:46 PM, Jens Alfke  wrote:
> 
>> On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell  
>> wrote:
>> 
>> The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is 
>> unsafe_unretained I believe
>> self can be deallocated leaving tableView.delegate as a dangling pointer.
> 
> This is still a weak reference, it's just unsafe (non-zeroing.) You're right 
> that these need to be cleaned up manually.

We prefer to reserve the term "weak" for safe zeroing weak. 


> Come to think of it, I'm surprised that AppKit delegates are still 
> unsafe-unretained. Why haven't these been converted to safe weak references 
> yet?

Some classes are incompatible with (safe zeroing) weak references. For example, 
any class that implements custom retain count storage needs additional code to 
work with weak references. That means AppKit needs to be careful about binary 
compatibility when it changes an unretained delegate to a weak delegate.


-- 
Greg Parker gpar...@apple.com Runtime Wrangler



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jonathan Mitchell]

> On 6 Feb 2015, at 20:46, Jens Alfke  wrote:
> 
> Come to think of it, I'm surprised that AppKit delegates are still 
> unsafe-unretained. Why haven't these been converted to safe weak references 
> yet?
I presume that AppKIt (all of it?) is not compiled using ARC and hence doesn’t 
get weak reference tracking et al?
Why isn AppKit compiled using ARC? Probably because it has a track record as it 
is and would likely gain nothing in a functional sense.

ARC works as advertised in general usage but managing unsafe_unretained 
references is as delicate a business as it is when using manual ref counting.
 
These sorts of difficulties are the inspiration of course for managed languages 
like C# which are largely free from these niceties.
However Obj-C’s dalliance with GC didn’t work out too well and there were as 
many issues with -finalise as there are with -dealloc.

Jonathan
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[David Duncan]

> On Feb 6, 2015, at 12:46 PM, Jens Alfke  wrote:
> 
> 
>> On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell  
>> wrote:
>> 
>> The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is 
>> unsafe_unretained I believe
>> self can be deallocated leaving tableView.delegate as a dangling pointer.
> 
> This is still a weak reference, it's just unsafe (non-zeroing.) You're right 
> that these need to be cleaned up manually.
> 
> Come to think of it, I'm surprised that AppKit delegates are still 
> unsafe-unretained. Why haven't these been converted to safe weak references 
> yet?

Converting an unowned reference to a zeroing-weak reference can cause 
compatibility issues with existing applications that are not prepared for the 
additional semantics required by zeroing-weak references. While this isn’t a 
deal breaker for the future, there still needs to be a compatibility path for 
older applications, and the entire code base needs to be audited to ensure 
correct operation (either by conversion to ARC or ensuring that access goes 
through the proper gating functions).

> 
>> The problem is that there is, I believe, no way to accurately determine 
>> whether a or b is true in any particular instance!
> 
> It depends on the class. For example, NSURLConnection has a well-defined 
> order in which it sends delegate messages, so it's possible to know when it's 
> not going to send any more messages. But yeah, in a window's view hierarchy 
> it's extremely unpredictable so it's important to zero out delegate 
> references.
> 
> —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.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/david.duncan%40apple.com
> 
> This email sent to david.dun...@apple.com

--
David Duncan


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jens Alfke]

> On Feb 6, 2015, at 11:55 AM, Jonathan Mitchell  
> wrote:
> 
> The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is 
> unsafe_unretained I believe
> self can be deallocated leaving tableView.delegate as a dangling pointer.

This is still a weak reference, it's just unsafe (non-zeroing.) You're right 
that these need to be cleaned up manually.

Come to think of it, I'm surprised that AppKit delegates are still 
unsafe-unretained. Why haven't these been converted to safe weak references yet?

> The problem is that there is, I believe, no way to accurately determine 
> whether a or b is true in any particular instance!

It depends on the class. For example, NSURLConnection has a well-defined order 
in which it sends delegate messages, so it's possible to know when it's not 
going to send any more messages. But yeah, in a window's view hierarchy it's 
extremely unpredictable so it's important to zero out delegate references.

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

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

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Alex Zavatone]

Here's where I am confused.  I thought you were running into problems on the 
Mac, but I see you mention iOS 5.1 and 6.0 while you mention that you are 
running into problems with NSViewController.

If you were running into problems on iOS, I'd expect to see UIViewController, 
not NSViewController.

Do you mean UIViewController and iOS or are these Mac OS issues?

Thanks,
Alex


Sent from my iPad. Please pardon typos.

On Feb 6, 2015, at 2:55 PM, Jonathan Mitchell  wrote:

> 
>> On 6 Feb 2015, at 17:34, Jens Alfke  wrote:
>>> On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell  
>>> wrote:
>>> 
>>>// remove observers
>>>// unregister for notifications
>> 
>> I have to confess I'm still not completely certain whether these are needed 
>> under ARC. I remember reading something about at least one of these being 
>> handled automatically, but I just skimmed through some docs now and couldn't 
>> find anything. I tend to put these in my classes but always wonder whether I 
>> strictly need to.
> I would say it is necessary. Warnings result otherwise and unremoved 
> observers do seem to lead to instability.
> 
>> 
>>>// set any non-weak delegates to nil (NSTableView et al)
>> 
>> I think you meant "set any _weak_ delegates to nil", i.e. clear the delegate 
>> property of any object of whom I'm the delegate. Non-weak doesn't make 
>> sense, because if a delegate has a strong reference to self, then self can't 
>> possibly be in its dealloc method.
> Sorry. I wasn’t clear enough probably.
> Most of my issues centre around NSViewController.
> Say I have an outlet to an NSTableView and the tableView.delegate = self.
> The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is 
> unsafe_unretained I believe
> self can be deallocated leaving tableView.delegate as a dangling pointer.
> 
>> 
>> Note that this is only necessary if (a) the other object can outlive self, 
>> and (b) the other object could still send the delegate messages in the 
>> future.
>> 
> The problem is that there is, I believe, no way to accurately determine 
> whether a or b is true in any particular instance!
> Recently I have resolved issues where both NSTableView and WebView were 
> sending delegate messages and responder chain actions in situations that I 
> hadn’t expected.
> A stone dead app is the result.
> 
> Jonathan
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com
> 
> This email sent to z...@mac.com

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jonathan Mitchell]

> On 6 Feb 2015, at 17:34, Kyle Sluder  wrote:
> 
> Dealloc is too late for a lot of this stuff. I try to keep -dealloc as
> pure as possible; that is, -dealloc should only be concerned with memory
> management.
> 
I agree that dealloc is far from perfect. What it does have going for it is 
ubiquity and reliability.
In also implement a -dispose method that I trigger from -windowWIllClose.
This cascades down the view controller hierarchy but needs a bit of glue of 
course.

> Removing observers, unbinding, unregistering notifications, and timer
> invalidation all happens in -viewWillMoveToWindow: or another similar
> place.

-viewWillMoveToWindow: can called a lot if a view is repeatedly added and 
removed from the window view hierarchy.
It would also need hooked up to the view controller to be actually useful.
To be honest the “other place” doesn’t generically exist in my experience.
Hence -dealloc and -dispose.

Jonathan
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jonathan Mitchell]

> On 6 Feb 2015, at 17:34, Jens Alfke  wrote:
>> On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell  
>> wrote:
>> 
>>  // remove observers
>>  // unregister for notifications
> 
> I have to confess I'm still not completely certain whether these are needed 
> under ARC. I remember reading something about at least one of these being 
> handled automatically, but I just skimmed through some docs now and couldn't 
> find anything. I tend to put these in my classes but always wonder whether I 
> strictly need to.
I would say it is necessary. Warnings result otherwise and unremoved observers 
do seem to lead to instability.

> 
>>  // set any non-weak delegates to nil (NSTableView et al)
> 
> I think you meant "set any _weak_ delegates to nil", i.e. clear the delegate 
> property of any object of whom I'm the delegate. Non-weak doesn't make sense, 
> because if a delegate has a strong reference to self, then self can't 
> possibly be in its dealloc method.
Sorry. I wasn’t clear enough probably.
Most of my issues centre around NSViewController.
Say I have an outlet to an NSTableView and the tableView.delegate = self.
The tableView.delegate is not a zeroing weak ref - in the lingo of ARC it is 
unsafe_unretained I believe
self can be deallocated leaving tableView.delegate as a dangling pointer.

> 
> Note that this is only necessary if (a) the other object can outlive self, 
> and (b) the other object could still send the delegate messages in the future.
> 
The problem is that there is, I believe, no way to accurately determine whether 
a or b is true in any particular instance!
Recently I have resolved issues where both NSTableView and WebView were sending 
delegate messages and responder chain actions in situations that I hadn’t 
expected.
A stone dead app is the result.

Jonathan
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Convert to NSString from

[Jens Alfke]

> On Feb 6, 2015, at 9:48 AM, Raglan T. Tiger  wrote:
> 
> What is the 'best practice' for converting to NSString?

The best practice is to know how the string data was encoded, and pass that 
encoding to the NSString initializer. There isn't any single encoding constant 
that's best, because different data formats use different string encodings.

(A special case of this is filesystem paths — for these you should use the 
special NSString methods to convert to/from them. These are basically UTF-8 but 
with some specific details about normalization, and NSString knows about those 
details.)

If you really don't have any idea what the encoding is, the best heuristic is:
(1) Try UTF-8. If it succeeds, use that.
(2) If UTF-8 fails, fall back to WinLatin1, aka CP-1252, aka 
NSWindowsCP1252StringEncoding. This will always succeed.
(3) Never, ever use NSMacOSRomanStringEncoding … unless you're trying to open a 
file created on the 'classic' Mac OS (≤ 9) or by an app that weirdly uses that 
encoding (some old Carbon versions of Excel, I've heard.)

The rationale is that:
* All plain ASCII text will decode fine as any of these encodings, since 
they're all supersets of it.
* Most modern code uses UTF-8.
* Non-ASCII non-UTF-8 string data will typically fail to parse as UTF-8 because 
it contains invalid byte sequences.
* Older code tends to use ISO-Latin-1 or the default Windows encoding 
(WinLatin1). 
* Fortunately WinLatin1 is a superset of ISO-Latin-1 so you can just try the 
latter.
* No one's used MacRoman encoding since the OS X transition, except for a few 
slow-moving legacy codebases.

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

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

This email sent to arch...@mail-archive.com

Convert to NSString from

[Raglan T. Tiger]

I have read that the recommended string encoding to use when converting strings 
from CString and Str to NSString is NSUTF8StringEncoding.

However, in too many cases this returns nil.  I have found that using 
NSMacOSRomanStringEncoding always returns an NSString.

What is the 'best practice' for converting to NSString?

-rags



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Jens Alfke]

> On Feb 6, 2015, at 6:48 AM, Jonathan Mitchell  wrote:
> 
>   // remove observers
>   // unregister for notifications

I have to confess I'm still not completely certain whether these are needed 
under ARC. I remember reading something about at least one of these being 
handled automatically, but I just skimmed through some docs now and couldn't 
find anything. I tend to put these in my classes but always wonder whether I 
strictly need to.

>   // set any non-weak delegates to nil (NSTableView et al)

I think you meant "set any _weak_ delegates to nil", i.e. clear the delegate 
property of any object of whom I'm the delegate. Non-weak doesn't make sense, 
because if a delegate has a strong reference to self, then self can't possibly 
be in its dealloc method.

Note that this is only necessary if (a) the other object can outlive self, and 
(b) the other object could still send the delegate messages in the future.

>   // invalidate any timers

This is incorrect, because NSTimer's target property is a strong delegate. So 
if self is currently the target of any NSTimer, it couldn't be deallocated. In 
fact, if you're in a dealloc method and still have a reference to such a timer, 
it indicates there's a refcounting error in your code! Worse, invalidating it 
in -dealloc will certainly cause a crash because it'll call -release on you 
during your dealloc…

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

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

This email sent to arch...@mail-archive.com

Re: ARC dealloc best pratice

[Kyle Sluder]

On Fri, Feb 6, 2015, at 08:48 AM, Jonathan Mitchell wrote:
> So I want to have a best practice template to follow in my dealloc.
> At present the template looks like so. When I need a dealloc I paste this
> in and fill in the blanks 
> 
> - (void) dealloc
> {
>   // remove observers
> 
>   // remove any explicit bindings
> 
>   // unregister for notifications
> 
>   // set any non-weak delegates to nil (NSTableView et al)
> 
>   // invalidate any timers
> 
> }

Dealloc is too late for a lot of this stuff. I try to keep -dealloc as
pure as possible; that is, -dealloc should only be concerned with memory
management.

Removing observers, unbinding, unregistering notifications, and timer
invalidation all happens in -viewWillMoveToWindow: or another similar
place.

--Kyle Sluder
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is it possible for a WebView to not share sessions with Safari on Mac OS X?

[Mike Abdullah]

> On 6 Feb 2015, at 14:41, Juanjo Conti  wrote:
> 
> I'm using 10.9 and they do share.
> 
> Do you know if a screen saver can be sandboxed?

My understanding is screensavers get loaded as a plug-in/bundle into another 
app by the system, so it’s up to that system program to be sandboxed or not.

In which case, sounds like you need to drop down to the WebResourceLoadDelegate 
and start customising requests so they don’t use the standard cookie storage.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

ARC dealloc best pratice

[Jonathan Mitchell]

I have a mid sized (200+ nib files and associated NSView + NSWindow 
controllers) ARC enabled app.
I have Zombie objects ON and have chased down a number of issues, most of which 
can be traced back to an incorrectly defined dealloc.

My recent experiences have demonstrated the treacherous nature of these sorts 
of issues.
One development machine seemed impervious to an issue, another exhibited it 
with unfailing regularity.

So I want to have a best practice template to follow in my dealloc.
At present the template looks like so. When I need a dealloc I paste this in 
and fill in the blanks 

- (void) dealloc
{
// remove observers

// remove any explicit bindings

// unregister for notifications

// set any non-weak delegates to nil (NSTableView et al)

// invalidate any timers

}

In particular I have issues with non weak delegates and making sure that I get 
them set to nil.
I am not aware of anyway of automatically analyzing the source to help ensure 
that I haven’t missed something.

Are the following correct:

1. I presume that all the Cocoa framework objects such as NSTableView, 
NSPopOver etc that have non weak delegates need set to nil (in other words - 
AppKit doesn’t use ARC).
2. This applies even if I don’t have an outlet to say a NSTableView - which 
effectively means that I have to have outlets to all such objects.
3. At present I have not tried to ensure that NSWindow delegates (typically 
NSWindowController instances) are nil. Should I?

Jonathan











___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is it possible for a WebView to not share sessions with Safari on Mac OS X?

[Juanjo Conti]

I'm using 10.9 and they do share.

Do you know if a screen saver can be sandboxed?

On Fri, Feb 6, 2015 at 11:36 AM, Mike Abdullah 
wrote:

>
> On 6 Feb 2015, at 14:30, Juanjo Conti  wrote:
>
> At the moment if I open, for example, "gmail.com" in a WebView, and I'm
> logged in (in that site) when I open it in Safari, the WebView shows me
> logged in. I'd like the WebView to be independent from Safaria and shows
> the login form. After logging in using the WebView, I'd like to save that
> session (cookies?) to remain logged in the next time I open that site using
> a WebView, regardless if I'm still logged in Safari.
>
> Was I clear?
>
>
> Yep, cookies are the important bit here.
>
> What version of OS X is this on? I thought cookies stopped being shared
> somewhere around 10.9, but maybe I recall wrong.
>
> More easily, sandbox your app. That’ll stop the store being shared :-)
>



-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is it possible for a WebView to not share sessions with Safari on Mac OS X?

[Mike Abdullah]

> On 6 Feb 2015, at 14:30, Juanjo Conti  wrote:
> 
> At the moment if I open, for example, "gmail.com " in a 
> WebView, and I'm logged in (in that site) when I open it in Safari, the 
> WebView shows me logged in. I'd like the WebView to be independent from 
> Safaria and shows the login form. After logging in using the WebView, I'd 
> like to save that session (cookies?) to remain logged in the next time I open 
> that site using a WebView, regardless if I'm still logged in Safari.
> 
> Was I clear?


Yep, cookies are the important bit here.

What version of OS X is this on? I thought cookies stopped being shared 
somewhere around 10.9, but maybe I recall wrong.

More easily, sandbox your app. That’ll stop the store being shared :-)
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is it possible for a WebView to not share sessions with Safari on Mac OS X?

[Juanjo Conti]

At the moment if I open, for example, "gmail.com" in a WebView, and I'm
logged in (in that site) when I open it in Safari, the WebView shows me
logged in. I'd like the WebView to be independent from Safaria and shows
the login form. After logging in using the WebView, I'd like to save that
session (cookies?) to remain logged in the next time I open that site using
a WebView, regardless if I'm still logged in Safari.

Was I clear?

Thanks in advance,

On Fri, Feb 6, 2015 at 11:21 AM, Mike Abdullah 
wrote:

>
> > On 6 Feb 2015, at 14:15, Juanjo Conti  wrote:
> >
> > As a first look it seems that no. Or, at least, the default behavior is
> to
> > share sessions but I'd like to find the way around this. Any ideas? Any
> > approach I can try?
> >
> > I now that in Cocoa Touch the default is the opposite.
>
> Can you clarify what you mean by “sessions”?
>
>


-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Is it possible for a WebView to not share sessions with Safari on Mac OS X?

[Mike Abdullah]

> On 6 Feb 2015, at 14:15, Juanjo Conti  wrote:
> 
> As a first look it seems that no. Or, at least, the default behavior is to
> share sessions but I'd like to find the way around this. Any ideas? Any
> approach I can try?
> 
> I now that in Cocoa Touch the default is the opposite.

Can you clarify what you mean by “sessions”?


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Is it possible for a WebView to not share sessions with Safari on Mac OS X?

[Juanjo Conti]

As a first look it seems that no. Or, at least, the default behavior is to
share sessions but I'd like to find the way around this. Any ideas? Any
approach I can try?

I now that in Cocoa Touch the default is the oposite.

-- 

Juanjo Conti http://goog_2023646312>@carouselapps.com
>

Software Engineer - Carousel Apps 

-- 
Carousel Apps Limited, registered in England & Wales with registered number 
7689440 and registered office Unit 2 Artbrand Studios, 7 Leathermarket 
Street, London SE1 3HN. Any communication sent by or on behalf of Carousel 
App Ltd or any of its subsidiary, holding or affiliated companies or 
entities (together "Watu") is confidential and may be privileged or 
otherwise protected. If you receive it in error please inform us and then 
delete it from your system. You should not copy it or disclose its contents 
to anyone. Messages sent to and from Watu may be monitored to ensure 
compliance with our internal policies and to protect our business. Emails 
are not secure and cannot be guaranteed to be error free. Anyone who 
communicates with us by email is taken to accept these risks.
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Show count of Core Data to-many relationship in NSTableView cell with bindings?

[Steve Mills]

On Feb 6, 2015, at 01:56:24, Quincey Morris 
 wrote:

> You can’t bind *through* an array or set collection class. However, you can 
> use these:
> 
>   
> https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/KeyValueCoding/Articles/CollectionOperators.html
> 

On Feb 6, 2015, at 02:03:34, Ken Thomases  wrote:

> You can't use KVO or bindings through arrays or sets, even to their immediate 
> properties.
> 
> For KVC, if you were to attempt to do [theTableCellView 
> valueForKeyPath:@"objectValue.images.count"], that would attempt to get the 
> "count" property of each _element_ of objectValue.images and return a set 
> containing all of those counts (wrapped in NSNumbers).  In theory, if KVO 
> through sets worked, then observing the key path objectValue.images.count 
> would not notify you when the count of objectValue.images changed.  It would 
> notify you when the set returned by [theTableCellView 
> valueForKeyPath:@"objectValue.images.count"] changed (or might have changed). 
>  That's not what you want, anyway.
> 
> However, there are collection operators 
> ,
>  including @count.  You can bind to that with model key path 
> objectValue.images.@count.

W doggies! Just when I was about to go to bed, you guys come through 
with the goods and make my night. :) Thanks so much. I need to read the KVC and 
KVO articles again.

--
Steve Mills
Drummer, Mac geek


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Show count of Core Data to-many relationship in NSTableView cell with bindings?

[Ken Thomases]

On Feb 6, 2015, at 1:43 AM, Steve Mills  wrote:

> I have a Core Data entity called Keyword that has a to-many relationship to 
> another entity called Image. In a table that displays these Keywords, I want 
> one column to show the number of Images that use that particular Keyword. I 
> tried setting the Value binding for the Table View Cell to bind to the Table 
> Cell View with model key path of objectValue.images.count. That doesn't work 
> - throws an exception:
> 
> [<_NSFaultingMutableSet 0x620246e0> 
> addObserver:forKeyPath:options:context:] is not supported. Key path: count
> 
> Is it not possible to bind to an entity's relationship properties? The 
> Keyword class has a property named assets of class NSSet, so it seems like 
> the binding should be able to access it just like the attribute properties.

You can't use KVO or bindings through arrays or sets, even to their immediate 
properties.

For KVC, if you were to attempt to do [theTableCellView 
valueForKeyPath:@"objectValue.images.count"], that would attempt to get the 
"count" property of each _element_ of objectValue.images and return a set 
containing all of those counts (wrapped in NSNumbers).  In theory, if KVO 
through sets worked, then observing the key path objectValue.images.count would 
not notify you when the count of objectValue.images changed.  It would notify 
you when the set returned by [theTableCellView 
valueForKeyPath:@"objectValue.images.count"] changed (or might have changed).  
That's not what you want, anyway.

However, there are collection operators 
,
 including @count.  You can bind to that with model key path 
objectValue.images.@count.

Regards,
Ken


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com