Access Contacts (Address Book) Question

[Manfred Schwind]

Hi,

when an app tries to access the contacts (via Address Book Framework), OS X 
recently asks the user first if this should be allowed. This question is asked 
only once per app, then the app is "on the list" and this list can be seen in 
System Preferences - Security & Privacy - Privacy - Contacts. There you can 
also change your decision later on (not sure if many people know this).

My first question is:
How can I delete an app from this list to test the behaviour of the app when OS 
X asks the address book question?

Furthermore I am not entirely sure, but I think when this contacts questions 
was asked for Pages I saw a description WHY Pages want to access the contacts. 
But I could not find any API to set such a description. So my second question 
is if there is such an API that I may have overlooked? It would be really great 
to be able to inform the user why an app want to access contacts to help him 
decide wether or not he wants to allow it. Is this overall new "sandboxed" 
contacts accessing behaviour of OS X documented somewhere?

Regards,
Mani
--
mani.de - friendly software


___

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: Access Contacts (Address Book) Question

[Andreas Mayer]

Am 17.09.2012 um 09:48 schrieb Manfred Schwind :

> Furthermore I am not entirely sure, but I think when this contacts questions 
> was asked for Pages I saw a description WHY Pages want to access the 
> contacts. But I could not find any API to set such a description. So my 
> second question is if there is such an API that I may have overlooked?

You can set it in the Info.plist. It's explained in the "Privacy Support in iOS 
and OS X" WWDC video.


Andreas
___

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: Access Contacts (Address Book) Question

[Dennis]

On Sep 17, 2012, at 12:48 AM, Manfred Schwind wrote:

> when an app tries to access the contacts (via Address Book Framework), OS X 
> recently asks the user first if this should be allowed. This question is 
> asked only once per app, then the app is "on the list" and this list can be 
> seen in System Preferences - Security & Privacy - Privacy - Contacts. There 
> you can also change your decision later on (not sure if many people know 
> this).
> 
> My first question is:
> How can I delete an app from this list to test the behaviour of the app when 
> OS X asks the address book question?
> 
> Furthermore I am not entirely sure, but I think when this contacts questions 
> was asked for Pages I saw a description WHY Pages want to access the 
> contacts. But I could not find any API to set such a description. So my 
> second question is if there is such an API that I may have overlooked? It 
> would be really great to be able to inform the user why an app want to access 
> contacts to help him decide wether or not he wants to allow it. Is this 
> overall new "sandboxed" contacts accessing behaviour of OS X documented 
> somewhere?

This is discussed in the WWDC video for session 710, starting about 20 minutes 
in. I believe it should provide answers to all your questions.
___

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

NSPasteboard type for InDesign

[Chris Paveglio]

I'm trying to build a little app to drag and drop image files (or any files 
really) onto an InDesign document. What is the correct file type to use? NSURL 
or a string with the file path? I've tried both but neither work for me.
I'm sure I might have another problem with my drag and drop implementation, but 
I want to clarify that I am using the right file type so I can eliminate that 
as one of my problems.
BTW any example code for DnD appreciated! ;-)

Chris
___

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: NSPasteboard type for InDesign

[Kyle Sluder]

On Sep 17, 2012, at 8:59 AM, Chris Paveglio  wrote:

> I'm trying to build a little app to drag and drop image files (or any files 
> really) onto an InDesign document. What is the correct file type to use? 
> NSURL or a string with the file path?

Can't answer that for sure. It depends on what drag types InDesign accepts, if 
anything. In general, when dragging files, you want to use NSURLs.

> I've tried both but neither work for me.

InDesign might simply not support dropping files onto it.

> I'm sure I might have another problem with my drag and drop implementation, 
> but I want to clarify that I am using the right file type so I can eliminate 
> that as one of my problems.
> BTW any example code for DnD appreciated! ;-)

There should be a bunch on developer.apple.com, but make sure it's using the 
new-style NSPasteboardWriting API.

--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: NSPasteboard type for InDesign

[Jens Alfke]

On Sep 17, 2012, at 8:59 AM, Chris Paveglio  wrote:

> I'm trying to build a little app to drag and drop image files (or any files 
> really) onto an InDesign document. What is the correct file type to use? 
> NSURL or a string with the file path? I've tried both but neither work for me.

If InDesign windows accept image files dragged in from the Finder, then you 
could drag such a file to the PasteboardPeeker app [look it up, it’s very 
useful] to see what pasteboard types the Finder provides. Then you know that 
InDesign recognizes some subset of those types, which will give you something 
to start from.

But in general, yes, file URLs should be the right thing. Adobe apps don’t 
always play by the rules when using the pasteboard, though, unfortunately. (Or 
didn’t in the past; I haven’t tried lately.)

—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: Sandboxing not so bad

[James Merkel]

Maybe you are correct. I have found a couple of other cases where Sandboxing 
limits the functionality of my application.
I'm beginning to think maybe I should  not Sandbox.

By the way, none of the applications I have downloaded from the MAS are 
Sandboxed.
Seems to be a lot of exceptions being made.

Jim Merkel

On Sep 15, 2012, at 2:55 PM, koko  wrote:

> Yes,  a piece of cake for a piece of cake app.
> 
> Try doing something like iterating the file system so you can present to the 
> user all files of unique types you understand that can be anywhere on the 
> system.
> 
> The sandbox is like a cat box … to be avoided at all costs.
> 
> -koko
> 
> On Sep 15, 2012, at 3:01 PM, James Merkel wrote:
> 
>> 
>> On Sep 13, 2012, at 12:45 PM, James Merkel  wrote:
>> 
>>> Sandboxing is not as restrictive than I though it would be.
>>> 
>>> For example, the documentation for the entitlement: 
>>> com.apple.security.files.user-selected.read-write says this entitlement 
>>> provides:  "Read/write access to files the user has selected using an Open 
>>> or Save dialog" .
>>> I was reading more into that than I should have. If you use the Open dialog 
>>> to access a file, then you can read and write to the file. You don't have 
>>> to use the Save dialog to write to the file. And that file
>>> can be anywhere on the file system (except for system files I guess).
>>> 
>>> And yes the app is really sandboxed. If no entitlements are enabled I can't 
>>> do anything (except read and write to recent documents in the Open Recent 
>>> menu).
>>> 
>>> So with just that entitlement and a Printing Entitlement I can do just 
>>> about everything I could previously do before Sandboxing.
>>> The only thing I can't do is write comments to the Finder GetInfo window -- 
>>> because  that uses Applescript. But I can live without that.
>>> 
>>> So unless I'm missing something, sandboxing is a piece of cake.
>>> 
>>> Thanks,
>>> 
>>> Jim Merkel
>>> 
>> 
>> Just noticed -- perviously I had the capability to make a change to all 
>> files in a folder based on the changes to a particular open file from that 
>> folder.
>> With Sandboxing, I can't do that anymore since those other files weren't 
>> opened from an Open dialog.
>> So maybe Sandboxing is not so wonderful.
>> On the other hand, one could also say that my previous implementation didn't 
>> follow human interface guidelines.
>> 
>> Jim Merkel
>> 
>> 
>> ___
>> 
>> 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/koko%40highrolls.net
>> 
>> This email sent to k...@highrolls.net
>> 
> 


___

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: Another sandboxing snafu

[Corbin Dunn]

On Sep 13, 2012, at 4:15 PM, Graham Cox  wrote:

> Grrr... and here's exactly the sort of stupid thing that I was referring to a 
> moment ago in another thread...
> 
> 
> I'm attempting to show an NSOpenPanel as a sheet, app is sandboxed. This has 
> always worked perfectly fine:
> 
>   NSOpenPanel*op = [NSOpenPanel openPanel];
>   
>   [op setAllowsMultipleSelection:NO];
>   [op setCanChooseDirectories:NO];
>   [op setAllowedFileTypes:[NSImage imageFileTypes]];
>   
>   void (^completionHandler)(NSInteger result) = ^(NSInteger result)
>   {
>   if( result == NSFileHandlingPanelOKButton )
>   {
> 
>   // do stuff with URL from panel (omitted)
>   }
>   };
>   
>   
>   [op beginSheetModalForWindow:[self windowForSheet] 
> completionHandler:completionHandler];
> 
> 
> But now when this code runs, the following is logged:
> 
> 
> 14/09/12 9:02:18.578 AM WindowServer[108]: CGXSetWindowShape: Operation on a 
> window 0xf87 requiring rights kCGSWindowRightOwner by caller Artboard
> 14/09/12 9:02:18.578 AM Artboard[47282]: _NXPlaceWindow: error setting window 
> shape (1001)
> 14/09/12 9:02:18.583 AM com.apple.security.pboxd[47286]: 
> : the delegate 
>  was sent 
> -splitView:resizeSubviewsWithOldSize: and left the subview frames in an 
> inconsistent state:
> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Split view bounds: 
> {{0, 0}, {0, 0}}
> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Subview frame: 
> {{0, 0}, {-316, 0}}
> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Subview frame: 
> {{-315, 0}, {315, 0}}
> 14/09/12 9:02:18.585 AM com.apple.security.pboxd[47286]: The subview frames 
> are not in the same order as the subviews array. NSSplitView requires that 
> these orders be kept consistent, otherwise behavior is undefined.


This logging indicates a bug in the frameworks. If you can reproduce it, please 
log your app and reproducible steps to bugreporter.apple.com.

thanks!!

corbin

> 
> 
> 
> Anyone got this simple use of NSOpenPanel to work with sandboxing?
> 
> 
> --Graham
> 
> 
> 
> ___
> 
> 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/corbind%40apple.com
> 
> This email sent to corb...@apple.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

Position of my item in the statusBar

[Erik Stainsby]

HI,

I'm wondering if anyone can explain to me (or point me in the right direction) 
as to how I can determine the current position of my stats bar item at runtime. 
It seems that the status bar mechanisms are unpublished except for the very 
basic use of popping an item into the collection and hanging a menu from it.  
I'd like to know where on screen my item's image is so that I can place a panel 
window adjacent to it.  

Advice?
 
Erik Stainsby
erik.stain...@roaringsky.ca



___

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: Position of my item in the statusBar

[Tim Schröder]

Use something like this: 

NSRect frame = [[statusItem valueForKey:@"window"] frame];

Tim


Am 17.09.2012 um 22:55 schrieb Erik Stainsby :

> HI,
> 
> I'm wondering if anyone can explain to me (or point me in the right 
> direction) as to how I can determine the current position of my stats bar 
> item at runtime. It seems that the status bar mechanisms are unpublished 
> except for the very basic use of popping an item into the collection and 
> hanging a menu from it.  I'd like to know where on screen my item's image is 
> so that I can place a panel window adjacent to it.  
> 
> Advice?
> 
> Erik Stainsby
> erik.stain...@roaringsky.ca
> 
> 
> 
> ___
> 
> 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/tim%40timschroeder.net
> 
> This email sent to t...@timschroeder.net


___

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: Position of my item in the statusBar

[Kyle Sluder]

On Mon, Sep 17, 2012, at 02:12 PM, Tim Schröder wrote:
> Use something like this: 
> 
> NSRect frame = [[statusItem valueForKey:@"window"] frame];

Don't do this. -[NSStatusItem window] is private API and is not
guaranteed to exist.

Create a view, assign it to your status item, and use that for your
frame.

--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: Position of my item in the statusBar

[Nick Zitzmann]

On Sep 17, 2012, at 2:55 PM, Erik Stainsby  wrote:

> HI,
> 
> I'm wondering if anyone can explain to me (or point me in the right 
> direction) as to how I can determine the current position of my stats bar 
> item at runtime. It seems that the status bar mechanisms are unpublished 
> except for the very basic use of popping an item into the collection and 
> hanging a menu from it.  I'd like to know where on screen my item's image is 
> so that I can place a panel window adjacent to it.  
> 
> Advice?


The only way I know of doing this involves relying on an implementation detail 
of status items, so I wouldn't recommend relying on this advice always being 
true. As of the last few versions of OS X at the time of this writing, status 
items work by creating a borderless window that belongs to the creating 
application, so if you set a status item's target, and then cycle through the 
app's windows to find a window with a contentView with a target that is 
identical to the status item's target, then that window is the status item's 
window. You should be able to get the status item's frame from that window.

Nick Zitzmann



___

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: Another sandboxing snafu

[Graham Cox]

On 18/09/2012, at 4:12 AM, Corbin Dunn  wrote:

>> 14/09/12 9:02:18.578 AM WindowServer[108]: CGXSetWindowShape: Operation on a 
>> window 0xf87 requiring rights kCGSWindowRightOwner by caller Artboard
>> 14/09/12 9:02:18.578 AM Artboard[47282]: _NXPlaceWindow: error setting 
>> window shape (1001)
>> 14/09/12 9:02:18.583 AM com.apple.security.pboxd[47286]: 
>> : the delegate 
>>  was sent 
>> -splitView:resizeSubviewsWithOldSize: and left the subview frames in an 
>> inconsistent state:
>> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Split view bounds: 
>> {{0, 0}, {0, 0}}
>> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Subview frame: 
>> {{0, 0}, {-316, 0}}
>> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Subview frame: 
>> {{-315, 0}, {315, 0}}
>> 14/09/12 9:02:18.585 AM com.apple.security.pboxd[47286]: The subview frames 
>> are not in the same order as the subviews array. NSSplitView requires that 
>> these orders be kept consistent, otherwise behavior is undefined.
> 
> 
> This logging indicates a bug in the frameworks. If you can reproduce it, 
> please log your app and reproducible steps to bugreporter.apple.com.


I certainly will; but haven't reproduced it in a separate project yet


My feeling is that the sidebar split view problem is a consequence of the first 
part: CGXSetWindowShape: Operation on a window 0xf87 requiring rights 
kCGSWindowRightOwner by caller

which has a sandbox/rights denial flavour to it, possibly. It would be useful 
to know what that actually MEANS so I can look for an originating cause.

--Graham


___

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: Another sandboxing snafu

[Corbin Dunn]

On Sep 17, 2012, at 4:19 PM, Graham Cox  wrote:

> 
> On 18/09/2012, at 4:12 AM, Corbin Dunn  wrote:
> 
>>> 14/09/12 9:02:18.578 AM WindowServer[108]: CGXSetWindowShape: Operation on 
>>> a window 0xf87 requiring rights kCGSWindowRightOwner by caller Artboard
>>> 14/09/12 9:02:18.578 AM Artboard[47282]: _NXPlaceWindow: error setting 
>>> window shape (1001)
>>> 14/09/12 9:02:18.583 AM com.apple.security.pboxd[47286]: 
>>> : the delegate 
>>>  was sent 
>>> -splitView:resizeSubviewsWithOldSize: and left the subview frames in an 
>>> inconsistent state:
>>> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Split view bounds: 
>>> {{0, 0}, {0, 0}}
>>> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Subview frame: 
>>> {{0, 0}, {-316, 0}}
>>> 14/09/12 9:02:18.584 AM com.apple.security.pboxd[47286]: Subview frame: 
>>> {{-315, 0}, {315, 0}}
>>> 14/09/12 9:02:18.585 AM com.apple.security.pboxd[47286]: The subview frames 
>>> are not in the same order as the subviews array. NSSplitView requires that 
>>> these orders be kept consistent, otherwise behavior is undefined.
>> 
>> 
>> This logging indicates a bug in the frameworks. If you can reproduce it, 
>> please log your app and reproducible steps to bugreporter.apple.com.
> 
> 
> I certainly will; but haven't reproduced it in a separate project yet

It's okay to include your app as an executable; we can debug that.

> 
> 
> My feeling is that the sidebar split view problem is a consequence of the 
> first part: CGXSetWindowShape: Operation on a window 0xf87 requiring rights 
> kCGSWindowRightOwner by caller

Possibly...it is hard to say. The split view log is something else though, and 
needs to be fixed in an internal framework that uses AppKit. 

corbin


> 
> which has a sandbox/rights denial flavour to it, possibly. It would be useful 
> to know what that actually MEANS so I can look for an originating cause.
> 
> --Graham
> 
> 

___

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: Position of my item in the statusBar

[Erik Stainsby]

On 2012-09-17, at 2:17 PM, Kyle Sluder  wrote:

> On Mon, Sep 17, 2012, at 02:12 PM, Tim Schröder wrote:
>> Use something like this: 
>> 
>> NSRect frame = [[statusItem valueForKey:@"window"] frame];
> 
> Don't do this. -[NSStatusItem window] is private API and is not
> guaranteed to exist.
> 
> Create a view, assign it to your status item, and use that for your
> frame.
> 
> --Kyle Sluder


Is it any safer to assume a window will be returned from this code ? 

RSStatusItemViewController * _statusViewCtrl = [[RSStatusItemViewController 
alloc]init];
[self.statusItem setView:[_statusViewCtrl view]];
NSWindow * statusWindow = [[_statusViewCtrl view] window];

NSRect rect = [statusWindow frame];

I mean I assign the view through setView: - does that implicitly guarantee 
there will be a window context when I invoke  [myView window] later on?  I see 
nothing contractual.  It works, and I am glad, but I don't know if I can trust 
it.


Erik Stainsby
erik.stain...@roaringsky.ca

___

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: Position of my item in the statusBar

[Kyle Sluder]

On Sep 17, 2012, at 6:55 PM, Erik Stainsby  wrote:

> On 2012-09-17, at 2:17 PM, Kyle Sluder  wrote:
> 
>> On Mon, Sep 17, 2012, at 02:12 PM, Tim Schröder wrote:
>>> Use something like this: 
>>> 
>>> NSRect frame = [[statusItem valueForKey:@"window"] frame];
>> 
>> Don't do this. -[NSStatusItem window] is private API and is not
>> guaranteed to exist.
>> 
>> Create a view, assign it to your status item, and use that for your
>> frame.
>> 
>> --Kyle Sluder
> 
> 
> Is it any safer to assume a window will be returned from this code ? 

Sadly it's not absolutely guaranteed, because Apple never outright claims that 
the view will be placed in a window, but since the express purpose of having 
-setView: is so you can do normal view things like respond to events, and 
events are dispatched by window, it's fairly safe to assume it will work. 
Certainly a lot safer than assuming the private -window method will continue to 
exist forever.

Personally, I believe that if Apple hands you Thing A and Thing B, and gives 
you a way to hook A and B together, then the documentation should explicitly 
describe the entire interaction between A and B. Pragmatically, this isn't the 
case.

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

window errors

[Rick C.]

Hi,

Can someone shed some light on what this is:

http://pastie.org/pastes/4580387

I'm having the same errors with my app but have never noticed this until either 
10.8 or Xcode 4.5.  Thanks!

rc
___

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