Re: Help w/ first step of creating Help Book for app

[Volker in Lists]

Hi Shane,

try the special mailing list Apple has going for help authoring: 
Apple-help-authoring

Probably full on topic there!

Cheers,
Volker



___

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 arch...@mail-archive.com

Re: Using table view cells from nibs

[Quincey Morris]

On May 28, 2010, at 23:39, Tino Rachui wrote:

> I've created a table view cell in interface builder with a custom height. 
> However when I load and use that kind of cell at runtime it disregards my 
> custom height. I have to use 'heightForRowAtIndexPath' to set the desired 
> cell height. Is there anything I'm missing?

Well, the row height and the cell height are different things. The table view's 
built-in behavior places the cell at the top (AFAIK) of the row height.

A custom cell can place itself at the vertical center (for example) of the row 
height, but that doesn't help you.  You *need* to use 'heightForRowAtIndexPath' 
to make the rows tall enough for your custom cells. (Or, if possible, just set 
a larger row height in the table view in IB, if a single height works for all 
rows.)


___

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 arch...@mail-archive.com

Re: drawing border of NSPopUpButtonCell drawInteriorWithFrame:inView:

[Graham Cox]

On 29/05/2010, at 3:20 PM, Shane wrote:

>   [path lineToPoint:NSMakePoint(cellFrame.size.width, 
> cellFrame.size.height)];


Should be:

[path lineToPoint:NSMakePoint( cellFrame.origin.x + cellFrame.size.width, 
cellFrame.size.height )];

Or more succinctly:

[path lineToPoint:NSMakePoint( NSMaxX( cellFrame ), NSMaxY( cellFrame ))];

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

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

Re: six things I wasn't able to do with Cocoa

[Chris Hanson]

On May 27, 2010, at 12:43 PM, Bill Appleton wrote:

> *5)** **I **can't create a simple list*
> 
> I did it the only way I could -- with a table that has one column, etc. Man
> that was painful for a simple list. Is there a better way?

In what way did you find creating an NSTableView with one column painful?

What would you expect to be different about a “simple list” — a table with only 
one column — compared to a table with multiple columns?

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

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

Re: authenticating peers

[Michael Ash]

On Fri, May 28, 2010 at 10:34 PM, Jens Alfke  wrote:
>
> On May 28, 2010, at 6:59 PM, Michael Ash wrote:
>
>> An attacker can execute a man-in-the-middle attack...
>> An attacker can simply impersonate your app...
>> Neither of these can be defended against, even theoretically, when 
>> communicating peer-to-peer.
>
> Not true; if you use SSL or some equivalent, both peers can use certificates 
> to identify themselves. This works if either (a) the certs are signed by a 
> reputable authority (as in the traditional use of SSL by web servers), or if 
> (b) each peer has previously verified the other’s identity and remembered the 
> cert (as is done by SSH.)
>
> GameKit doesn’t do anything like this, though, although I can’t say for sure 
> because Apple’s never published any information about the protocol used (to 
> my knowledge).

Man-in-the-middle: if I execute the attack the first time you talk to
a given peer, you have no way of detecting me.

Impersonation: I use a legitimate copy to talk to you once. Now we
have two peers which have identified themselves. Afterwards, I take my
copy of the app and modify it to emit malicious code. When we connect
again, I use the credentials we already exchanged to identify my side
again, then hit you with malicious data.

How does your scheme protect against that? It doesn't, and can't. It
is impossible for you to tell the difference between "I am talking to
a legitimate copy of this application" and "I am talking to something
that appears to be a legitimate copy of this application, but will
actually send me evil data."

Mike
___

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 arch...@mail-archive.com

Re: Help w/ first step of creating Help Book for app

[Bill Cheeseman]

The problem with the current version of Apple's document is that it attempts to 
cover the new kind of Help book that works only in Snow Leopard, as well as the 
old kind of Help book that works in Leopard and Tiger as well as Snow Leopard. 
However, from section to section and even sentence to sentence it doesn't 
explain which kind of Help book it is talking about. You therefore cannot 
create a valid, working Help book by reading the Apple document alone.

For example, the folder structure of an application bundle that you reproduced 
in your post is for the new kind of Help book that works only on Snow Leopard. 
The new kind of Help book is a full-scale bundle of its own, with its own 
Contents folder, Resources folder, Info-plist file, and so on. In the Finder, 
it belongs at the root level of your application bundle's Resources folder. 
This is a plus for developers, because it allows them to manage their Help 
books completely separately from the Xcode project until its done, when it can 
easily be added to the Xcode project with a simple menu command (Add > Existing 
Files, or something like that). For example, with new-style Help books, 
developers can put all of their language-specific localization folders 
(English.lproj, etc.) in the one Help book, which they can then send out to 
localization contractors as a single folder. To create a Help book the old way, 
that works on Leopard and older as well as Snow Leopard, you have to put a 
non-bundled Help folder in your application bundle's English.lproj folder, 
another non-bundled Help folder in the German language .lproj folder, and so 
on, scattering the language-specific Help folders all over your application 
bundle's Resources folder in separate language-specific folders.

So if your application is supposed to run on Leopard or older as well as Snow 
Leopard, do it the way Matt Neuburg's movie does it, and read Apple's document 
with a grain of salt. The direct URL for the movie is 
.

As far as I know, the only writeup available at this time that specifically 
addresses the new Snow Leopard Help book format is Recipe 11 of my new book, 
"Cocoa Recipes for Mac OS X: The Vermont Recipes," (second ed., Peachpit, 
2010), which devotes about 35 pages to the topic. At the end of that Recipe, I 
also show how to convert a new-style Help book to an old-style Help book. There 
are some internal differences as well as the structural differences I mentioned 
above.

Apart from all that, I think you have misunderstood the role of the Groups & 
Files pane in an Xcode project window. The structure of groups (they aren't 
really folders, although that's what they look like) and files in the project 
window is for the most part a matter of convenience to help you keep your 
project conceptually organized within Xcode. It does not necessarily (and 
usually does not) mirror the folder structure on disk. On disk, almost all of 
the files in your project are at the root level of your project folder. The 
major exception is language-specific files and folders, which go in their own 
language-specific folders in the project folder in the Finder. For old-style 
Help books, you would create a Surfwriter Help folder inside the English.lproj 
subfolder in your project folder, and you would put all your English Help pages 
and subfolders, and the index file that is generated by Help Indexer, inside 
that English-language Surfwriter Help folder. You would put a German-language 
Help folder inside the German.lproj (de.lproj?) folder with its own help pages, 
subfolders, and index file, and so on. For new-style Help books, the Finder 
folder structure is different. You would put a Surfwriter Help folder at the 
root level of your project folder on disk, and you would make it a bundle all 
by itself by giving it its own Contents folder, Resources subfolder, Info.plist 
file, individual language-specific .lproj folders, and so on.

When writing your Help file text, you typically would not use Xcode, although 
it does have a perfectly good text editor in which you can write raw HTML by 
hand if you like. But it's easier to write HTML by hand using BBEdit or 
TextWrangler, or any other text editor that understands HTML. And if you don't 
want to write raw HTML in a text editor, follow Matt's advice and use iWeb or a 
graphical Web page editor. Either way, you might find it a little less 
confusing to work out of the Help book in the Finder, not the Help book in the 
Groups & Files pane. Even when not using an outside localization contractor, I 
find it easier to keep my Help book development completely separate from the 
Xcode project until the end. However, you can do it out of the Groups & Files 
pane if you like, because the internal structure of each language-specific Help 
book in the Groups & Files pane should mirror its structure in the Finder, 
notwithstanding what I said above about the differences between the 

Question about how to make a custom sheet

[Anders Sommer Lassen]

Hi,

I am working on an application that use several custom sheets or dialogs. 

I have read most documentation about this, but I am still a bit confused on how 
to do this in a simple and standardized way.

Most of the documentation explains how to add a panel to the main nib file, and 
how to get the sheet displayed and closed. This works fine in my application. 

My problem is how to get a custom class attached to the sheet, so controls on 
the sheet can be controlled during user interaction. This step is not mentioned 
in the documentation.

I have read somewhere that I do not need to create a separate nib file to get 
this to work, and that creating a separate nib file is mostly done to speed up 
load time.

My question is then, how to do this using the main nib file.

Should I use a custom class that derives from NSObject and make an instance of 
this in my nib?

If yes, how can I control this instance from my primary controller class?

Kind regards,

Anders

___

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 arch...@mail-archive.com

Re: Question about how to make a custom sheet

[John Johnson]

Perhaps NSWindowController subclass is what you're looking for. A sheet is just 
another window. Then set the File's Owner of the NIB file that houses the sheet 
to this subclass.

> My problem is how to get a custom class attached to the sheet, so controls on 
> the sheet can be controlled during user interaction. This step is not 
> mentioned in the documentation.
___

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 arch...@mail-archive.com

Re: Question about how to make a custom sheet

[Fritz Anderson]

On 29 May 2010, at 9:20 AM, Anders Sommer Lassen wrote:

> Should I use a custom class that derives from NSObject and make an instance 
> of this in my nib?

Yes.

> If yes, how can I control this instance from my primary controller class?

I assume your primary controller is either File's Owner, or is itself 
instantiated in the NIB (such as the application controller). The primary 
controller should have an IBOutlet for the sheet controller. Link it to the 
sheet controller in the NIB.

— F

___

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 arch...@mail-archive.com

Re: Using table view cells from nibs

[Luke Hiesterman]

I'm not sure why you're trying to separate the ideas of row and cell height. I 
don't think there's any reason why you should ever attempt to have a cell whose 
height is different from the height returned in heightForRowAtIndexPath. In 
fact, you shouldn't even be setting cell frames yourself. The table view does 
this for you based on the width of the table and the height the delegate 
returns. 

To speak to the original poster, heightForRowAtIndexPath is THE way to set the 
height of your cells. If you expect a certain height when you design your cell 
in IB then you should make sure to return that height from your delegate. 

Luke

Sent from my iPad

On May 29, 2010, at 1:32 AM, Quincey Morris  wrote:

> On May 28, 2010, at 23:39, Tino Rachui wrote:
> 
>> I've created a table view cell in interface builder with a custom height. 
>> However when I load and use that kind of cell at runtime it disregards my 
>> custom height. I have to use 'heightForRowAtIndexPath' to set the desired 
>> cell height. Is there anything I'm missing?
> 
> Well, the row height and the cell height are different things. The table 
> view's built-in behavior places the cell at the top (AFAIK) of the row height.
> 
> A custom cell can place itself at the vertical center (for example) of the 
> row height, but that doesn't help you.  You *need* to use 
> 'heightForRowAtIndexPath' to make the rows tall enough for your custom cells. 
> (Or, if possible, just set a larger row height in the table view in IB, if a 
> single height works for all rows.)
> 
> 
> ___
> 
> 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/luketheh%40apple.com
> 
> This email sent to luket...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Using table view cells from nibs

[Quincey Morris]

On May 29, 2010, at 08:56, Luke Hiesterman wrote:

> I'm not sure why you're trying to separate the ideas of row and cell height. 
> I don't think there's any reason why you should ever attempt to have a cell 
> whose height is different from the height returned in heightForRowAtIndexPath.

Well, the specific case I was thinking of is getting vertically centered text 
in a NSTableView row. AFAIK there's no way to get this using standard 
frameworks behaviors. The only way to get text vertically centered (AFAIK) is 
to subclass the standard text cell and make it draw itself in a different place 
relative to the row height. To me, that makes row height and cell height 
different things.

> The table view does this for you based on the width of the table and the 
> height the delegate returns. 

Not (AFAIK) for NSTextFieldCell. The height returned by 'cellSizeForBounds:' is 
the height of the actual text, not the row height.

By contrast, the table view does change the cell height for button cells, and 
the cell's behavior is to draw its content vertically centered. This has the 
annoying side effect, when a row contains both a checkbox with text and a text 
field with text, of not lining up the text baselines, unless the row height 
matches the text height exactly.

If there's anything wrong with my understanding here, I'd be *very* happy to 
know different.


___

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 arch...@mail-archive.com

Re: Using table view cells from nibs

[Luke the Hiesterman]

I realized we're talking about different things. My mind when instantly to 
UITableView and I didn't realize we were talking about NSTableView. I can only 
speak for UITableView :)

Luke

On May 29, 2010, at 9:45 AM, Quincey Morris wrote:

> On May 29, 2010, at 08:56, Luke Hiesterman wrote:
> 
>> I'm not sure why you're trying to separate the ideas of row and cell height. 
>> I don't think there's any reason why you should ever attempt to have a cell 
>> whose height is different from the height returned in 
>> heightForRowAtIndexPath.
> 
> Well, the specific case I was thinking of is getting vertically centered text 
> in a NSTableView row. AFAIK there's no way to get this using standard 
> frameworks behaviors. The only way to get text vertically centered (AFAIK) is 
> to subclass the standard text cell and make it draw itself in a different 
> place relative to the row height. To me, that makes row height and cell 
> height different things.
> 
>> The table view does this for you based on the width of the table and the 
>> height the delegate returns. 
> 
> Not (AFAIK) for NSTextFieldCell. The height returned by 'cellSizeForBounds:' 
> is the height of the actual text, not the row height.
> 
> By contrast, the table view does change the cell height for button cells, and 
> the cell's behavior is to draw its content vertically centered. This has the 
> annoying side effect, when a row contains both a checkbox with text and a 
> text field with text, of not lining up the text baselines, unless the row 
> height matches the text height exactly.
> 
> If there's anything wrong with my understanding here, I'd be *very* happy to 
> know different.
> 
> 
> ___
> 
> 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/luketheh%40apple.com
> 
> This email sent to luket...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Question about how to make a custom sheet (solved)

[Anders Sommer Lassen]

Thanks, this was very helpful.

Anders


On May 29, 2010, at 4:29 PM, Fritz Anderson wrote:

> On 29 May 2010, at 9:20 AM, Anders Sommer Lassen wrote:
> 
>> Should I use a custom class that derives from NSObject and make an instance 
>> of this in my nib?
> 
> Yes.
> 
>> If yes, how can I control this instance from my primary controller class?
> 
> I assume your primary controller is either File's Owner, or is itself 
> instantiated in the NIB (such as the application controller). The primary 
> controller should have an IBOutlet for the sheet controller. Link it to the 
> sheet controller in the NIB.
> 
>   — F
> 

___

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 arch...@mail-archive.com

Re: Using table view cells from nibs

[Quincey Morris]

On May 29, 2010, at 09:48, Luke the Hiesterman wrote:

> I realized we're talking about different things. My mind when instantly to 
> UITableView and I didn't realize we were talking about NSTableView. I can 
> only speak for UITableView :)

Well, you made the correct assumption. I didn't read the *end* of 
'heightForRowAtIndexPath' to realize that it must have been UITableView the OP 
was talking about.

So, since you have nothing better to do on a Saturday morning than browse this 
list, how about you and 5 of your friends go stage an intervention on 
NSTableView? ;)


___

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 arch...@mail-archive.com

Re: Using table view cells from nibs

[Tino Rachui]

Thanks Luke and Quincey, I think understand better now. Seems like 
'heightForRowAtIndexPath' is the right thing to do. I have different table rows 
so configuring a fixed row height in IB (which is possible) is not an option 
for me.
And 'yes' I'm talking about UITableView. ;)

Regards,
Tino


Am 29.05.2010 um 17:56 schrieb Luke Hiesterman:

> I'm not sure why you're trying to separate the ideas of row and cell height. 
> I don't think there's any reason why you should ever attempt to have a cell 
> whose height is different from the height returned in 
> heightForRowAtIndexPath. In fact, you shouldn't even be setting cell frames 
> yourself. The table view does this for you based on the width of the table 
> and the height the delegate returns. 
> 
> To speak to the original poster, heightForRowAtIndexPath is THE way to set 
> the height of your cells. If you expect a certain height when you design your 
> cell in IB then you should make sure to return that height from your 
> delegate. 
> 
> Luke
> 
> Sent from my iPad
> 
> On May 29, 2010, at 1:32 AM, Quincey Morris  
> wrote:
> 
>> On May 28, 2010, at 23:39, Tino Rachui wrote:
>> 
>>> I've created a table view cell in interface builder with a custom height. 
>>> However when I load and use that kind of cell at runtime it disregards my 
>>> custom height. I have to use 'heightForRowAtIndexPath' to set the desired 
>>> cell height. Is there anything I'm missing?
>> 
>> Well, the row height and the cell height are different things. The table 
>> view's built-in behavior places the cell at the top (AFAIK) of the row 
>> height.
>> 
>> A custom cell can place itself at the vertical center (for example) of the 
>> row height, but that doesn't help you.  You *need* to use 
>> 'heightForRowAtIndexPath' to make the rows tall enough for your custom 
>> cells. (Or, if possible, just set a larger row height in the table view in 
>> IB, if a single height works for all rows.)
>> 
>> 
>> ___
>> 
>> 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/luketheh%40apple.com
>> 
>> This email sent to luket...@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:
> http://lists.apple.com/mailman/options/cocoa-dev/tino.rachui%40googlemail.com
> 
> This email sent to tino.rac...@googlemail.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: NSURLConnection weirdiness

[Nava Carmon]

Thanks for answering. 

Indeed I found a pattern and probably the explanation, now I need to found the 
appropriate solution:
What happen is that My iphone application presents the data that comes as an 
xml files, which I fetch from a various urls on the same server. There are 
problematic urls, that when I try to reach them from safari or from within the 
application give an error - mostly timeout error. When I initialize the 
NSURLConnection I define a timeout in my NSURLMutableRequest in order not to 
stuck the GUI and let the user to work with application. On timeout I get 
didFailWithError in NSURLConnectionDelegate and show a message that there was 
not response from the server and the user can continue working. The matter is 
that the connection or underlying socket somehow is preserved and the 
connection with the server is not closed. So when I try to get another url from 
the same server I can't reach it since the server is still stuck with the 
previous problematic request! 
Now I can understand why from the other device or the browser  I can reach 
urls, that are not reachable after problematic request on my device, simply 
because they open another socket to the same server. 
The question is how do I totally close (force closing) the problematic 
connection, that is stuck till the server will "get out" of this unsuccessful 
fetch? I tried close connection and cancel connection, but seems these APIs do 
nothing :(. Is the NSURLConnection way to go in such cases? Each time I need to 
get xml file I create another NSURLConnection. I read somewhere that it's not a 
good practice...

Again, thanks for the help. 

On May 29, 2010, at 5:04 AM, Jerry Krinock wrote:

> 
> On 2010 May 28, at 02:58, Nava Carmon wrote:
> 
>> When I enter same link in Safari it takes a second to bring data.
> 
> I understand that you're saying it "works OK at the same time from the same 
> IP address from Safari", meaning that you have ruled out being throttled by 
> this "certain server", or your ISP.  OK, because these would be the first two 
> suspects on my list.
> 
>> And after another trial I can access the link.
> 
> I'm assuming you mean exactly the same URL.  Some servers give better service 
> to web browsers than to apps requesting via their API.
> 
>> What might be the reason for such a weird behavior?  How can I improve it?
> 
> You're going to have to discover a pattern.  For another data point with 
> these types of problems, you'll usually want to open a Terminal window and 
> send your request using the unix command curl(1).
> 
>> What is the role of cache policy with NSURLConnection?
> 
> Long answer:
> 
> http://developer.apple.com/mac/library/documentation/cocoa/conceptual/URLLoadingSystem/Concepts/CachePolicies.html
> 
> For consistency in testing, you'll probably want to use 
> NSURLRequestReloadIgnoringCacheData.
> 
> Let us know if you find anything interesting.  Actually, a better list for 
> this question would be macnetworkp...@lists.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:
> http://lists.apple.com/mailman/options/cocoa-dev/ncarmon%40mac.com
> 
> This email sent to ncar...@mac.com


Nava Carmon
ncar...@mac.com

"Think good and it will be good!"

___

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 arch...@mail-archive.com

Re: authenticating peers

[Jens Alfke]

This is rapidly heading off-topic, but:

On May 29, 2010, at 4:15 AM, Michael Ash wrote:

> Man-in-the-middle: if I execute the attack the first time you talk to
> a given peer, you have no way of detecting me.

This is avoided using an out-of-band exchange of a secret over a trusted 
channel (direct line-of-sight, voice, etc.) The common “enter this 4-digit 
number on the other device” task (e.g. pairing your iPhone’s Remote app with 
iTunes) is a type of this. In my Cloudy project the secret was derived from a 
hash of the public key[1]; a MITM would have to find a hash collision in real 
time to spoof it.

> Impersonation: I use a legitimate copy to talk to you once. Now we
> have two peers which have identified themselves. Afterwards, I take my
> copy of the app and modify it to emit malicious code.

Sure this is a problem, but it’s not a problem of authentication. If I decide 
to trust you, but you’re not trustworthy, that’s a social problem not a 
technical one. Or if your device / account / key is compromised, you need a 
revocation protocol to contain the damage.

If the point you’re making is that you can’t trust the incorruptibility of data 
even if it was received from a trusted source, then we’re in violent agreement 
:) So back to the topic of the thread: passing remote data to NSUnarchiver is a 
security hole. Don’t do it.

—Jens

[1] 
http://jens.mooseyard.com/2008/04/cloudy-verification/___

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 arch...@mail-archive.com

Re: Help w/ first step of creating Help Book for app

[Jason Terhorst]

If you don't want to code all of your help document pages by hand, this tool 
might be handy: 
http://www.omnigroup.com/blog/entry/Helpify_1.5_Help_Us_Help_You_Help_Users/

I've seen others out there that worked by editing in a special app and styled 
it like Apple's old help docs, but can't find them off-hand.

This Omni tool requires OmniOutliner, but it generates everything you need 
automagically.

- Jason Terhorst



On May 29, 2010, at 11:50 AM, cocoa-dev-requ...@lists.apple.com wrote:

> 
> Message: 9
> Date: Sat, 29 May 2010 07:22:16 -0400
> From: Bill Cheeseman 
> Subject: Re: Help w/ first step of creating Help Book for app
> To: Shane 
> Cc: Cocoa-Dev Mail Cocoa-Dev 
> Message-ID: <999ff1c1-8be3-4867-a7a8-35cef16c7...@gmail.com>
> Content-Type: text/plain; charset=us-ascii
> 
> The problem with the current version of Apple's document is that it attempts 
> to cover the new kind of Help book that works only in Snow Leopard, as well 
> as the old kind of Help book that works in Leopard and Tiger as well as Snow 
> Leopard. However, from section to section and even sentence to sentence it 
> doesn't explain which kind of Help book it is talking about. You therefore 
> cannot create a valid, working Help book by reading the Apple document alone.
> 
> For example, the folder structure of an application bundle that you 
> reproduced in your post is for the new kind of Help book that works only on 
> Snow Leopard. The new kind of Help book is a full-scale bundle of its own, 
> with its own Contents folder, Resources folder, Info-plist file, and so on. 
> In the Finder, it belongs at the root level of your application bundle's 
> Resources folder. This is a plus for developers, because it allows them to 
> manage their Help books completely separately from the Xcode project until 
> its done, when it can easily be added to the Xcode project with a simple menu 
> command (Add > Existing Files, or something like that). For example, with 
> new-style Help books, developers can put all of their language-specific 
> localization folders (English.lproj, etc.) in the one Help book, which they 
> can then send out to localization contractors as a single folder. To create a 
> Help book the old way, that works on Leopard and older as well as Snow 
> Leopard, you have to pu
> t a non-bundled Help folder in your application bundle's English.lproj 
> folder, another non-bundled Help folder in the German language .lproj folder, 
> and so on, scattering the language-specific Help folders all over your 
> application bundle's Resources folder in separate language-specific folders.
> 
> So if your application is supposed to run on Leopard or older as well as Snow 
> Leopard, do it the way Matt Neuburg's movie does it, and read Apple's 
> document with a grain of salt. The direct URL for the movie is 
> .
> 
> As far as I know, the only writeup available at this time that specifically 
> addresses the new Snow Leopard Help book format is Recipe 11 of my new book, 
> "Cocoa Recipes for Mac OS X: The Vermont Recipes," (second ed., Peachpit, 
> 2010), which devotes about 35 pages to the topic. At the end of that Recipe, 
> I also show how to convert a new-style Help book to an old-style Help book. 
> There are some internal differences as well as the structural differences I 
> mentioned above.
> 
> Apart from all that, I think you have misunderstood the role of the Groups & 
> Files pane in an Xcode project window. The structure of groups (they aren't 
> really folders, although that's what they look like) and files in the project 
> window is for the most part a matter of convenience to help you keep your 
> project conceptually organized within Xcode. It does not necessarily (and 
> usually does not) mirror the folder structure on disk. On disk, almost all of 
> the files in your project are at the root level of your project folder. The 
> major exception is language-specific files and folders, which go in their own 
> language-specific folders in the project folder in the Finder. For old-style 
> Help books, you would create a Surfwriter Help folder inside the 
> English.lproj subfolder in your project folder, and you would put all your 
> English Help pages and subfolders, and the index file that is generated by 
> Help Indexer, inside that English-language Surfwriter Help folder. You would 
> put a Germ
> an-language Help folder inside the German.lproj (de.lproj?) folder with its 
> own help pages, subfolders, and index file, and so on. For new-style Help 
> books, the Finder folder structure is different. You would put a Surfwriter 
> Help folder at the root level of your project folder on disk, and you would 
> make it a bundle all by itself by giving it its own Contents folder, 
> Resources subfolder, Info.plist file, individual language-specific .lproj 
> folders, and so on.
> 
> When writing your Help file text, you typically would not use Xcode, althoug

Re: NSURLConnection weirdiness

[Jens Alfke]

On May 29, 2010, at 11:53 AM, Nava Carmon wrote:

> When I initialize the NSURLConnection I define a timeout in my 
> NSURLMutableRequest in order not to stuck the GUI and let the user to work 
> with application. On timeout I get didFailWithError in 
> NSURLConnectionDelegate and show a message that there was not response from 
> the server and the user can continue working.

If you’re running the NSURLConnection asynchronously (which I think you are, 
since you use a delegate), you can already unblock the UI and let the user 
continue to work. That’s a better design than waiting until the connection 
finishes, especially in a mobile app. (For example, my Twitter client returns 
to the timeline as soon as I press the Post button, and sends the post to the 
Twitter servers in the background.)

> The matter is that the connection or underlying socket somehow is preserved 
> and the connection with the server is not closed. So when I try to get 
> another url from the same server I can't reach it since the server is still 
> stuck with the previous problematic request! 

Hm. It’s true that CFNetwork uses HTTP keep-alive mode, where it can reuse a 
socket for multiple requests. But I don’t think it’ll send a second request on 
the same socket until the previous one is complete. (I.e. I don’t believe it 
supports pipelining.) Instead it should be opening a new socket while the first 
one is busy, up to a max of I think 4 sockets per host.

I don’t know if there’s any way, using public API, to disable keep-alive. It’s 
possible using a lower-level API like CFStream would let you get around this. I 
would ask on the macnetworkprog list. (And make sure to mention that this is on 
iPhone, as the APIs aren’t exactly the same as on Mac.)

> Each time I need to get xml file I create another NSURLConnection. I read 
> somewhere that it's not a good practice…

No, that’s fine. The API was designed so that one connection = one request; 
note that there’s no way to re-use a NSURLConnection object for a second 
request. Under the hood the CFNetwork framework will be as efficient as it can, 
by re-using sockets when possible.

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

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

Re: NSURLConnection weirdiness

[Nava Carmon]

On May 29, 2010, at 10:12 PM, Jens Alfke wrote:

> 
> On May 29, 2010, at 11:53 AM, Nava Carmon wrote:
> 
>> When I initialize the NSURLConnection I define a timeout in my 
>> NSURLMutableRequest in order not to stuck the GUI and let the user to work 
>> with application. On timeout I get didFailWithError in 
>> NSURLConnectionDelegate and show a message that there was not response from 
>> the server and the user can continue working.
> 
> If you’re running the NSURLConnection asynchronously (which I think you are, 
> since you use a delegate), you can already unblock the UI and let the user 
> continue to work. That’s a better design than waiting until the connection 
> finishes, especially in a mobile app. (For example, my Twitter client returns 
> to the timeline as soon as I press the Post button, and sends the post to the 
> Twitter servers in the background.)

Yes, you're right, but the point is that it's a "GET" method and the user has 
to wait till he sees the desired data. I show kind of activity indicator, till 
it loads and parses. It's a customer requirement.

> 
>> The matter is that the connection or underlying socket somehow is preserved 
>> and the connection with the server is not closed. So when I try to get 
>> another url from the same server I can't reach it since the server is still 
>> stuck with the previous problematic request! 
> 
> Hm. It’s true that CFNetwork uses HTTP keep-alive mode, where it can reuse a 
> socket for multiple requests. But I don’t think it’ll send a second request 
> on the same socket until the previous one is complete. (I.e. I don’t believe 
> it supports pipelining.) Instead it should be opening a new socket while the 
> first one is busy, up to a max of I think 4 sockets per host.
> 
> I don’t know if there’s any way, using public API, to disable keep-alive. 
> It’s possible using a lower-level API like CFStream would let you get around 
> this. I would ask on the macnetworkprog list. (And make sure to mention that 
> this is on iPhone, as the APIs aren’t exactly the same as on Mac.)

May be I should try some other API to get these xml files? detaching a thread 
and init a parser with URL? Would it be better approach in this case?

Nava Carmon
ncar...@mac.com

"Think good and it will be good!"

___

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 arch...@mail-archive.com

Re: NSError* reference in method Re: deprecated method

[Quincey Morris]

On May 29, 2010, at 14:14, Bill Tschumy wrote:

> So I looked at the documentation for what "countForFetchRequest" returns when 
> there is an error.

It's a documentation bug. Consulting the actual header file, you'll find:

> // returns the number of objects a fetch request would have returned if it 
> had been passed to -executeFetchRequest:error:.   If an error occurred during 
> the processing of the request, this method will return NSNotFound. 
> - (NSUInteger) countForFetchRequest: (NSFetchRequest *)request error: 
> (NSError **)error;

which clears up the question.


___

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 arch...@mail-archive.com

Re: authenticating peers

[Michael Ash]

On Sat, May 29, 2010 at 3:04 PM, Jens Alfke  wrote:
> This is rapidly heading off-topic, but:
> On May 29, 2010, at 4:15 AM, Michael Ash wrote:
>
>> Man-in-the-middle: if I execute the attack the first time you talk to
>> a given peer, you have no way of detecting me.
>
> This is avoided using an out-of-band exchange of a secret over a trusted
> channel (direct line-of-sight, voice, etc.) The common “enter this 4-digit
> number on the other device” task (e.g. pairing your iPhone’s Remote app with
> iTunes) is a type of this. In my Cloudy project the secret was derived from
> a hash of the public key[1]; a MITM would have to find a hash collision in
> real time to spoof it.
>
>> Impersonation: I use a legitimate copy to talk to you once. Now we
>> have two peers which have identified themselves. Afterwards, I take my
>> copy of the app and modify it to emit malicious code.
>
> Sure this is a problem, but it’s not a problem of authentication. If I
> decide to trust you, but you’re not trustworthy, that’s a social problem not
> a technical one. Or if your device / account / key is compromised, you need
> a revocation protocol to contain the damage.
> If the point you’re making is that you can’t trust the incorruptibility of
> data even if it was received from a trusted source, then we’re in violent
> agreement :) So back to the topic of the thread: passing remote data to
> NSUnarchiver is a security hole. Don’t do it.

I think we both agree overall, but I believe your response above
misses the point. You seem to be concerned with authentication, i.e.
making sure that you're talking to who you think you're talking to.
But authentication is completely orthogonal to trust. Talking about
exchanging PINs and using certificates and such is irrelevant to the
problem at hand.

Mike
___

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 arch...@mail-archive.com

Re: Help w/ first step of creating Help Book for app

[Shane]

Thank you very much for such a clear reply. You sold a book. :)
___

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 arch...@mail-archive.com

Re: authenticating peers

[Barry Skidmore]

Answer:
Never trust any data that you did not generate yourself and are 100%  
certain it is bug free.


Meaning:
Don't process it at all ever until you run sanity checks against it.   
Trust is an entirely different animal.


Thanks,
Barry

On May 29, 2010, at 4:42 PM, Michael Ash  wrote:

On Sat, May 29, 2010 at 3:04 PM, Jens Alfke   
wrote:

This is rapidly heading off-topic, but:
On May 29, 2010, at 4:15 AM, Michael Ash wrote:

Man-in-the-middle: if I execute the attack the first time you talk  
to

a given peer, you have no way of detecting me.


This is avoided using an out-of-band exchange of a secret over a  
trusted
channel (direct line-of-sight, voice, etc.) The common “enter this 
 4-digit
number on the other device” task (e.g. pairing your iPhone’s  
Remote app with
iTunes) is a type of this. In my Cloudy project the secret was  
derived from
a hash of the public key[1]; a MITM would have to find a hash  
collision in

real time to spoof it.


Impersonation: I use a legitimate copy to talk to you once. Now we
have two peers which have identified themselves. Afterwards, I  
take my

copy of the app and modify it to emit malicious code.


Sure this is a problem, but it’s not a problem of authentication.  
If I
decide to trust you, but you’re not trustworthy, that’s a social  
problem not
a technical one. Or if your device / account / key is compromised,  
you need

a revocation protocol to contain the damage.
If the point you’re making is that you can’t trust the  
incorruptibility of
data even if it was received from a trusted source, then we’re in  
violent
agreement :) So back to the topic of the thread: passing remote  
data to

NSUnarchiver is a security hole. Don’t do it.


I think we both agree overall, but I believe your response above
misses the point. You seem to be concerned with authentication, i.e.
making sure that you're talking to who you think you're talking to.
But authentication is completely orthogonal to trust. Talking about
exchanging PINs and using certificates and such is irrelevant to the
problem at hand.

Mike
___

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/atri%40me.com

This email sent to a...@me.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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Activating application raises windows meant to be invisible

[David Reitter]

Peter,

On May 28, 2010, at 1:04 AM, Peter Ammon wrote:

> If a window is ordered out, AppKit will not order it back in when the app is 
> activated.  Is it possible that a different window is created, or that the 
> window was not ordered out to begin with?

Yes, orderOut is called on the window as far as I can tell.

> Is it possible that one of the windows is set to hide on deactivate? 

No, that's not the case (also see below).

It's entirely possible that the application shows the window somehow.  How can 
I find out?  I have tried setting breakpoints on orderFront: and also 
makeKeyAndOrderFront: - no luck.   Also, by the time 
applicationShouldHandleReopen: is called, the window is already visible.

Where would I set a breakpoint to catch the point where the window is actually 
made visible?

Thanks
- David


(gdb) print * (NSWindow *) [view window]
$2 = {
   = {
 = {
  isa = 0x1002b0b38
}, 
members of NSResponder: 
_nextResponder = 0x0
  }, 
  members of NSWindow: 
  _frame = {
origin = {
  x = 1080, 
  y = 366
}, 
size = {
  width = 589, 
  height = 617
}
  }, 
  _contentView = 0x1020ad510, 
  _delegate = 0x1020ca410, 
  _firstResponder = 0x1020ca410, 
  _lastLeftHit = 0x0, 
  _lastRightHit = 0x0, 
  _counterpart = 0x0, 
  _fieldEditor = 0x0, 
  _winEventMask = -1071906784, 
  _windowNum = -1, 
  _level = 0, 
  _backgroundColor = 0x100f07240, 
  _borderView = 0x102092150, 
  _postingDisabled = 0 '\000', 
  _styleMask = 14 '\016', 
  _flushDisabled = 0 '\000', 
  _reservedWindow1 = 0 '\000', 
  _cursorRects = 0x0, 
  _trectTable = 0x0, 
  _miniIcon = 0x0, 
  _unused = 0, 
  _dragTypes = 0x0, 
  _representedURL = 0x0, 
  _sizeLimits = 0x0, 
  _frameSaveName = 0x0, 
  _regDragTypes = 0x1020cea00, 
  _wFlags = {
backing = 2, 
visible = 0, 
isMainWindow = 0, 
isKeyWindow = 0, 
hidesOnDeactivate = 0, 
dontFreeWhenClosed = 0, 
oneShot = 0, 
deferred = 1, 
cursorRectsDisabled = 0, 
haveFreeCursorRects = 0, 
validCursorRects = 0, 
docEdited = 0, 
dynamicDepthLimit = 0, 
worksWhenModal = 0, 
limitedBecomeKey = 0, 
needsFlush = 0, 
viewsNeedDisplay = 0, 
ignoredFirstMouse = 0, 
repostedFirstMouse = 0, 
windowDying = 0, 
tempHidden = 0, 
floatingPanel = 0, 
wantsToBeOnMainScreen = 0, 
optimizedDrawingOk = 0, 
optimizeDrawing = 1, 
titleIsRepresentedFilename = 0, 
excludedFromWindowsMenu = 0, 
depthLimit = 0, 
delegateReturnsValidRequestor = 1, 
lmouseupPending = 0, 
rmouseupPending = 0, 
wantsToDestroyRealWindow = 0, 
wantsToRegDragTypes = 1, 
sentInvalidateCursorRectsMsg = 0, 
avoidsActivation = 0, 
frameSavedUsingTitle = 0, 
didRegDragTypes = 0, 
delayedOneShot = 0, 
postedNeedsDisplayNote = 0, 
postedInvalidCursorRectsNote = 0, 
initialFirstResponderTempSet = 0, 
autodisplay = 1, 
tossedFirstEvent = 0, 
isImageCache = 0, 
interfaceStyle = 0, 
keyViewSelectionDirection = 0, 
defaultButtonCellKETemporarilyDisabled = 0, 
defaultButtonCellKEDisabled = 0, 
menuHasBeenSet = 0, 
wantsToBeModal = 0, 
showingModalFrame = 0, 
isTerminating = 0, 
win32MouseActivationInProgress = 0, 
makingFirstResponderForMouseDown = 0, 
needsZoom = 0, 
sentWindowNeedsDisplayMsg = 0, 
liveResizeActive = 0
  }, 
  _defaultButtonCell = 0x0, 
  _initialFirstResponder = 0x0, 
  _auxiliaryStorage = 0x1020aafe0
}___

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 arch...@mail-archive.com