Re: Localization and Regions

[Gerriet M. Denkmann]

On 8 Nov 2011, at 13:45, Gary L. Wade wrote:

> That's how it's always worked. 

I just did show the font panel in TextEdit and looked at Arial:

10.5 shows Bold, Italic. etc. (English)
10.6 and 10.7 show Fett, Kursiv etc. (German).

So this NSFont behaviour (which I guess is used in the font panel) was correct 
in 10.5 and is broken since 10.6.
My machine cannot run anything before 10.5, so I do not know how NSFont did 
behave then.


Kind regards,

Gerriet.

___

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: Localization and Regions

[Gerriet M. Denkmann]

On 8 Nov 2011, at 13:45, Gary L. Wade wrote:

> That's how it's always worked. One can argue that Apple should ask the user, 
> when moving a more-specific locale (en-GB) away from a less-specific locale 
> (en), if the less-specific locale should "stick around" and be moved up into 
> the intuitive order following the more-specific locale. Naturally, such an 
> argument should be voiced as a radar feature request.
> --
> Gary L. Wade (Sent from my iPhone)
> http://www.garywade.com/

I am not quite sure that you are correct.

1. I tried some of my own apps and they (if not having en_GB) just use en. 
Never use de.

2. I found "Internationalization Programming Topics" → "Language and Locale 
Designations" → "Language-Specific Project Directories" which says:
"In Mac OS X, the bundle routines look for the requested resource in any 
region-specific directories first, followed by more generalized language 
directories."

I guess this means: Mac OS X looks for en_GB first, then, if not finding it, 
looks for en, then for my other language preferences (like de).
Which is what my own apps do.
And what NSFont does not.


Kind regards,

Gerriet.


> On Nov 7, 2011, at 10:31 PM, "Gerriet M. Denkmann"  
> wrote:
> 
>> Assuming that I have the following language preferences (System Preferences 
>> → Language and Text → Language):
>> 
>> British English,
>> Deutsch
>> Français
>> English
>> 
>> what is a program supposed to do if it has:
>> en.lproj
>> de.lproj
>> but NOT en_GB.lproj ?
>> 
>> I guess (but did not find an authoritative answer) that it should look for:
>> en_GB
>> en
>> de
>> fr
>> en
>> it's development language (Localization native development region = 
>> CFBundleDevelopmentRegion)
>> 
>> But with my language settings -[NSFont displayName] returns German font 
>> names.
>> Obviously NSFont does not have en_GB font names, and it does NOT look into 
>> it's en.lproj but jumps directly to de.lproj.
>> 
>> When I change my language preferences to:
>> British English,
>> English
>> Deutsch
>> Français
>> 
>> NSFont works as expected.
>> 
>> 
>> Is this correct? Or should I file a bug?
>> I have no recollection of seeing this before Lion (I'm using 10.7.2).
>> 
>> Also: this language mixture (mostly English, sometimes mixed with some 
>> German) is seen in several places, but the font display name is an easily 
>> reproducible example.
>> 
>> 
>> Kind regards,
>> 
>> Gerriet.

___

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: Localization and Regions

[Gary L. Wade]

That's how it's always worked. One can argue that Apple should ask the user, 
when moving a more-specific locale (en-GB) away from a less-specific locale 
(en), if the less-specific locale should "stick around" and be moved up into 
the intuitive order following the more-specific locale. Naturally, such an 
argument should be voiced as a radar feature request.
--
Gary L. Wade (Sent from my iPhone)
http://www.garywade.com/

On Nov 7, 2011, at 10:31 PM, "Gerriet M. Denkmann"  wrote:

> Assuming that I have the following language preferences (System Preferences → 
> Language and Text → Language):
> 
> British English,
> Deutsch
> Français
> English
> 
> what is a program supposed to do if it has:
> en.lproj
> de.lproj
> but NOT en_GB.lproj ?
> 
> I guess (but did not find an authoritative answer) that it should look for:
> en_GB
> en
> de
> fr
> en
> it's development language (Localization native development region = 
> CFBundleDevelopmentRegion)
> 
> But with my language settings -[NSFont displayName] returns German font names.
> Obviously NSFont does not have en_GB font names, and it does NOT look into 
> it's en.lproj but jumps directly to de.lproj.
> 
> When I change my language preferences to:
> British English,
> English
> Deutsch
> Français
> 
> NSFont works as expected.
> 
> 
> Is this correct? Or should I file a bug?
> I have no recollection of seeing this before Lion (I'm using 10.7.2).
> 
> Also: this language mixture (mostly English, sometimes mixed with some 
> German) is seen in several places, but the font display name is an easily 
> reproducible example.
> 
> 
> Kind regards,
> 
> Gerriet.
___

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

Localization and Regions

[Gerriet M. Denkmann]

Assuming that I have the following language preferences (System Preferences → 
Language and Text → Language):

British English,
Deutsch
Français
English

what is a program supposed to do if it has:
en.lproj
de.lproj
but NOT en_GB.lproj ?

I guess (but did not find an authoritative answer) that it should look for:
en_GB
en
de
fr
en
it's development language (Localization native development region = 
CFBundleDevelopmentRegion)

But with my language settings -[NSFont displayName] returns German font names.
Obviously NSFont does not have en_GB font names, and it does NOT look into it's 
en.lproj but jumps directly to de.lproj.

When I change my language preferences to:
British English,
English
Deutsch
Français

NSFont works as expected.


Is this correct? Or should I file a bug?
I have no recollection of seeing this before Lion (I'm using 10.7.2).

Also: this language mixture (mostly English, sometimes mixed with some German) 
is seen in several places, but the font display name is an easily reproducible 
example.


Kind regards,

Gerriet.
 

___

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: Any success with SMLoginItemSetEnabled?

[Mark Munz]

While you should file a bug, expect it to be duped and don't hold your
breath on when they'll fix it.
To date, Apple has not fixed *any* of the (fairly well) known sandbox
issues, including this one. Verify that it is a sandbox issue and not
a registration issue. If it is the latter, you're kind stuck until
Apple actually fixes some of these issues.

5 1/2 months without any fixes on any of sandbox-related issues, but
they did give us another 4 months for us to stress about it. Nice
holiday gift from Apple to Mac developers. If we're lucky, we may get
the fixes before the Mar 1 deadline comes.


Mark

-- 
Mark Munz
unmarked software
http://www.unmarked.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: Allocating too much memory kills my App rather than returning NULL

[Greg Parker]

On Nov 7, 2011, at 5:11 PM, Don Quixote de la Mancha wrote:
> This is for the iOS.  Do iOS devices have hardware-acellerated video?
> My profiling with Instruments suggests that they don't because of the
> amount of time that the iOS spends doing block fills on behalf of my
> App.

They do. However, "hardware acceleration" is not as simple as "blit from main 
memory is fast".


> Before I started writing iOS code I did embedded systems development
> and Mac OS X device drivers.  In both of those environments, Failure
> Is Not An Option.  While you can certainly run out of memory or
> encounter other errors, one just has to back out gracefully.

This turns out not to be practical in a complex layered application 
environment. How do you even begin to write recovery code when any method 
dispatch could fail? How do you test it?


> It's quite likely that much of our tests in the Simulator that should
> fail really don't because OS X has far more reasources than is
> available to the iOS, and little or no effort is made to limit the
> resources available to simulated Apps.

The simulator and the device differ in many ways, including but not limited to 
CPU speed, GPU speed, physical memory size, virtual memory layout, and 
filesystem case sensitivity. You must test on real devices too.


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

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

Re: Private Method?

[Graham Cox]

On 08/11/2011, at 12:16 PM, Don Quixote de la Mancha wrote:

> no method would be private.


True, but Public/Private is really more of a way to organise your code for its 
use by other humans. The compiler can enforce it to a degree, but the real 
reason for having private methods is to hide them from users of your code.

--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: Private Method?

[Fritz Anderson]

On 7 Nov 2011, at 7:16 PM, Don Quixote de la Mancha wrote:

> I don't really know, but it seems to me that there just *has* to be a
> way to enumerate all of the elements in those selector tables.  If
> there is, then no method would be private.

It took me a minute, but now I really know: class_copyMethodList(), in the 
Objective-C Runtime Reference.

This isn't a new discovery. I think if you read five pages on the subject, and 
look in the mirror, you'll see "There Are No Private Methods In Objective-C" 
tattooed on your forehead.

— 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: Private Method?

[David Duncan]

On Nov 7, 2011, at 5:16 PM, Don Quixote de la Mancha wrote:

> I don't really know, but it seems to me that there just *has* to be a
> way to enumerate all of the elements in those selector tables.  If
> there is, then no method would be private.


There is, and there is no true definition of a private method in Obj-C (see 
class_copyMethodList)
--
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: Private Method?

[Don Quixote de la Mancha]

While the method isn't publicly visible to other compilation units,
there will be an entry for its selector in the table of selectors that
is possessed by each class.

A simple-minded way to do Objective-C  method dispatch would be to
have an an array, list or tree of structures, with one struct element
being the selector and the other being a pointer to the C function
that is the actual implement of the method.

objc_msgsend() would then search the array, list or tree looking for
that selector, then call the C function.

When you ask a class if it responds to a selector, the class searches
its own table of selector/function pointer pairs, returning YES if it
finds a matching selector in the table.

I don't really know, but it seems to me that there just *has* to be a
way to enumerate all of the elements in those selector tables.  If
there is, then no method would be private.

-- 
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quix...@dulcineatech.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: Allocating too much memory kills my App rather than returning NULL

[Don Quixote de la Mancha]

On Mon, Nov 7, 2011 at 3:59 PM, Jens Alfke  wrote:
> On Nov 4, 2011, at 6:40 PM, Don Quixote de la Mancha wrote:
> I store the grid as an array-of-arrays rather than a two dimensional
> array.  That is, I have an array of pointers which has the same number
> of elements as there are rows.
>
> What’s the reason for that? I think it will hurt performance, both because
> it’s more expensive to look up the rows, and because locality of reference
> will suffer. Also, drawing will be slower because you can’t draw the entire
> board in one blit as you could if it were a pixmap.

Naive implementations of Conway's Game of Life require two grids, one
for the previous generation, with the other grid getting the new
generation.

To save memory, I only have two rows for the second grid.  As the
lines I am propagating advance downward, I place one of the two-line
grid lines into the original grid, then replace it with the now
out-of-date line from the original grid.

This is just a preliminary implementation though.  The rules of
Conway's Life call for an infinite grid.  The propagation speed of my
presently finite grid scales with the area of the grid.  It's real
fast if I have one cell per screen pixel on an iOS device, but slows
down very rapidly if I make it much bigger.  For that reason I plan to
move to a new algorithm that I have in mind that only stores the
living cells, that is, the bits that are set to 1.  The rules of Life
strongly favor dead cells - 0 bits - so this will dramatically cut
down on memory consumption.

> (Actually, for best performance you should look into using a GPU shader
> function to update the automaton. That should really scream, and I’d be
> shocked if some enterprising demo-scene coder hasn’t implemented it
> already.)

This is for the iOS.  Do iOS devices have hardware-acellerated video?
My profiling with Instruments suggests that they don't because of the
amount of time that the iOS spends doing block fills on behalf of my
App.

> At this point in my application there is only one thread.
>
> Yes, but the OS runs other threads for tasks like animations, network I/O,
> etc. and those are allocating memory too.
>
> Also I'm pretty sure the iOS memory allocator is multithreaded, and
> that Apple's code would be good about checking for runtime failures.
> If it does not, then that is a bug in the iOS.
>
> The allocator is multithreaded; it’s your approach to backing out that’s not
> thread-safe. If you accidentally eat up all available memory, you can’t
> assume you have time to back out by freeing everything before anything else
> tries/fails to allocate memory. There are other threads that could be
> calling malloc at arbitrary times relative to your thread.
> In general, higher-level code is not very graceful about handling
> out-of-memory situations. That’s because they’re rare nowadays [although
> less rare on iOS…] and because bulletproofing your code against them is
> excruciatingly difficult. There are so very many memory allocations, and
> once one fails you can’t do anything to handle the failure that might
> allocate more memory (such as creating an error object…) I’ve dealt with
> this in the Bad Old Days of the Classic OS, and it’s nearly impossible to
> get right.

Food for thought.

Those would all still be iOS bugs, which Apple ought to know about.
If my further investigation determines that something like that could
be happening I will certainly file a bug.  As it is I'm getting ready
to write up a minimal test case to help determine whether it could be
some completely unrelated bug elsewhere in my code.

Before I started writing iOS code I did embedded systems development
and Mac OS X device drivers.  In both of those environments, Failure
Is Not An Option.  While you can certainly run out of memory or
encounter other errors, one just has to back out gracefully.

BTW a bug I already reported is that the Simulator allows simulated
Apps a *LOT* more memory than do physical iOS devices.  At least that
was the case with some previous version of Xcode.  I found that the
Simulator would allow my App to have more or less the entire amount of
address space available to any Mac OS X App.  I advised Apple to use I
think it was the setrlimit() system call to limit simulated Apps to
the amount of memory a real iOS App would be expected to have.

Their response?  Submit a test case!

Look man, how hard can it be?  Just take any of Apple's sample iOS
code, have it malloc() a gigabyte then run it in the Simulator.  The
allocation will succeed!

It's quite likely that much of our tests in the Simulator that should
fail really don't because OS X has far more reasources than is
available to the iOS, and little or no effort is made to limit the
resources available to simulated Apps.



-- 
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quix...@dulcineatech.com
___

Cocoa-dev 

Re: Private Method?

[Jens Alfke]

On Nov 6, 2011, at 2:10 PM, Bryan Harrison wrote:

> I'm reviewing some sample code and am looking at a class with a method 
> declared in @implementation which isn't mentioned in any @interface.
> 
> Is this a private method, something else entirely, or merely sloppy coding?  

That’s considered a private method. (Unlike in C++ there’s no way to absolutely 
prevent external code from calling it, but the compiler will give you warnings 
if you try to do it directly.)

In Objective-C it’s considered good style to have the @interface section show 
*only* the public API of the class. Internal methods should go only in the 
@implementation. (If you need a forward declaration you can do that with a 
class continuation in the .m file.)

This keeps the header more readable and hides the implementation details of the 
class from view. It also speeds up compilation a bit, and can avoid the need to 
#import more headers from your .h file.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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: Allocating too much memory kills my App rather than returning NULL

[Jens Alfke]

On Nov 4, 2011, at 6:40 PM, Don Quixote de la Mancha wrote:

> I store the grid as an array-of-arrays rather than a two dimensional
> array.  That is, I have an array of pointers which has the same number
> of elements as there are rows.  Each row is array of unsigned longs,
> with the number of elements being the number of columns divided by
> thirty-two.

What’s the reason for that? I think it will hurt performance, both because it’s 
more expensive to look up the rows, and because locality of reference will 
suffer. Also, drawing will be slower because you can’t draw the entire board in 
one blit as you could if it were a pixmap.

(Actually, for best performance you should look into using a GPU shader 
function to update the automaton. That should really scream, and I’d be shocked 
if some enterprising demo-scene coder hasn’t implemented it already.)

> At this point in my application there is only one thread.

Yes, but the OS runs other threads for tasks like animations, network I/O, etc. 
and those are allocating memory too.

> Also I'm pretty sure the iOS memory allocator is multithreaded, and
> that Apple's code would be good about checking for runtime failures.
> If it does not, then that is a bug in the iOS.

The allocator is multithreaded; it’s your approach to backing out that’s not 
thread-safe. If you accidentally eat up all available memory, you can’t assume 
you have time to back out by freeing everything before anything else 
tries/fails to allocate memory. There are other threads that could be calling 
malloc at arbitrary times relative to your thread.

In general, higher-level code is not very graceful about handling out-of-memory 
situations. That’s because they’re rare nowadays [although less rare on iOS…] 
and because bulletproofing your code against them is excruciatingly difficult. 
There are so very many memory allocations, and once one fails you can’t do 
anything to handle the failure that might allocate more memory (such as 
creating an error object…) I’ve dealt with this in the Bad Old Days of the 
Classic OS, and it’s nearly impossible to get right.

—Jens

smime.p7s
Description: S/MIME cryptographic signature
___

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: Allocating too much memory kills my App rather than returning NULL

[Wade Tregaskis]

> Also I'm pretty sure the iOS memory allocator is multithreaded, and
> that Apple's code would be good about checking for runtime failures.
> If it does not, then that is a bug in the iOS.

That's my opinion too, but there are plenty of people within Apple who are 
vehemently against it.  So while I encourage you to file bugs, for your own 
sanity you shouldn't trust Apple's code in this respect, and should code 
defensively.  Obviously there's only so much you can possibly do in that 
respect, though.
___

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: Printing multiple images each on a separate page using single NSPrintOperation

[Martin Wierschin]

> Now when I have multiple pages to print, I would like to print all of them 
> using a single NSPrintOperation. So basically, I would like to insert 
> NSImage/NSImageView of each page as a separate page into a single NSView and 
> use this NSView to print finally using NSPrintOperation.

That approach will work just fine. Make a NSView subclass that contains all 
your pages/NSImageViews and have that subclass override the necessary custom 
pagination methods (eg: -knowsPageRange:). Then just create a NSPrintOperation 
for that big NSView. See:

http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/Printing/Concepts/pagination.html#//apple_ref/doc/uid/20001051-BBCHHAHI

~Martin


___

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: Allocating too much memory kills my App rather than returning NULL

[Don Quixote de la Mancha]

On Mon, Nov 7, 2011 at 7:59 AM, Greg Parker  wrote:
> This is not a safe pattern in a multi-threaded application. You may be 
> checking for failed allocations and responding correctly, but to a close 
> approximation no code anywhere else does so. For example, objc_msgSend 
> sometimes needs to allocate memory, and has no way to recover if it cannot. 
> If some other thread were working at the same time you caused allocation 
> failures, then that thread is likely to crash.

At this point in my application there is only one thread.

Also I'm pretty sure the iOS memory allocator is multithreaded, and
that Apple's code would be good about checking for runtime failures.
If it does not, then that is a bug in the iOS.



-- 
Don Quixote de la Mancha
Dulcinea Technologies Corporation
Software of Elegance and Beauty
http://www.dulcineatech.com
quix...@dulcineatech.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: Private Method?

[Graham Cox]

Useful to know, thanks.

(Seems a certain amount of updated documentation is passing me by. I like to 
think I'm pretty diligent about keeping up with stuff as it's released, but I 
hadn't spotted this one. I'm not sure if it's something I'm doing wrong, or if 
there could be a better way to flag up new stuff to ensure that developers see 
it. )

--Graham


On 07/11/2011, at 6:45 PM, Joar Wingfors wrote:

> 
> On 6 nov 2011, at 23:39, Graham Cox wrote:
> 
>>> If the former, how does this technique compare with the trick of putting an…
>>> 
>>> @interface someClass ()
>>> - (type) somePrivateMethod;
>>> @end
>>> 
>>> …in the implementation?
>> 
>> I could be wrong, but I'm not sure that syntax is legal. The round brackets 
>> should include something in between to define a Category. For private 
>> methods, 'Private' is typical.
> 
> 
> That's a class extension:
> 
>   
> 
> 
> j o a r
> 
> 

___

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: Allocating too much memory kills my App rather than returning NULL

[Wade Tregaskis]

>> If calloc() ever returns NULL while attempting to allocate the new
>> grid, I back out all of the successful allocations by passing each
>> array pointer to free().  Then I display an alert to the user to
>> advise them that there is not enough memory for their desired grid
>> size, and suggest trying a smaller one.
> 
> This is not a safe pattern in a multi-threaded application. You may be 
> checking for failed allocations and responding correctly, but to a close 
> approximation no code anywhere else does so. For example, objc_msgSend 
> sometimes needs to allocate memory, and has no way to recover if it cannot. 
> If some other thread were working at the same time you caused allocation 
> failures, then that thread is likely to crash.

'course, that's just one defeatist's opinion.  As a counter-opinion, I think 
that handling runtime errors is wise, and I've seen many crashes averted in 
practice (in multi-threaded code) in cases just like this.
___

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: Custom About Box with background shape

[Lee Ann Rucker]

Sounds like your window is initially visible before it's had its alpha set; try 
turning off "visible at launch" in the nib.

On Nov 7, 2011, at 12:04 PM, Chris Paveglio wrote:

> I have a custom about box, and it's sort of like Adobe apps, where it's not a 
> traditional window but a graphic/image I made that is a shape like a hexagon 
> with a drop shadow.
> It works fine and I can call it and I disable the window background by 
> setting the window alpha to 0.999.
> One little tiny issue is that when I invoke the about box, for just a 
> millisecond I sort of see the window bounds and background, and then it goes 
> away. The second time I show the about box the blink of background window is 
> not present.
> Is there some way to not have that flash happen the first time? I'm not doing 
> anything in init or awakeFromNib, only this:
> 
> -(IBAction)showAboutWindow:(id)sender
> {
> if(!aboutWindow)
> [NSBundleloadNibNamed:@"AboutWindow"owner:self];
> [aboutWindowsetBackgroundColor:[NSColorclearColor]];
> [aboutWindowsetAlphaValue:0.999]; //will only show transparent 
> backgrounds if set to something less than 1.0
> [aboutWindowcenter];
> [aboutWindowsetStyleMask:NSBorderlessWindowMask];
> [aboutWindowmakeKeyAndOrderFront:nil];
> }
> 
> I tried setting some of the settings in awakeFromNib but they didn't seem to 
> apply properly.
> 
> Thanks, 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/lrucker%40vmware.com
> 
> This email sent to lruc...@vmware.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

Custom About Box with background shape

[Chris Paveglio]

I have a custom about box, and it's sort of like Adobe apps, where it's not a 
traditional window but a graphic/image I made that is a shape like a hexagon 
with a drop shadow.
It works fine and I can call it and I disable the window background by setting 
the window alpha to 0.999.
One little tiny issue is that when I invoke the about box, for just a 
millisecond I sort of see the window bounds and background, and then it goes 
away. The second time I show the about box the blink of background window is 
not present.
Is there some way to not have that flash happen the first time? I'm not doing 
anything in init or awakeFromNib, only this:

-(IBAction)showAboutWindow:(id)sender
{
if(!aboutWindow)
[NSBundleloadNibNamed:@"AboutWindow"owner:self];
[aboutWindowsetBackgroundColor:[NSColorclearColor]];
[aboutWindowsetAlphaValue:0.999]; //will only show transparent backgrounds 
if set to something less than 1.0
[aboutWindowcenter];
[aboutWindowsetStyleMask:NSBorderlessWindowMask];
[aboutWindowmakeKeyAndOrderFront:nil];
}

I tried setting some of the settings in awakeFromNib but they didn't seem to 
apply properly.

Thanks, 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: ObjectController preventing WindowController from releasing

[Ken Thomases]

On Nov 7, 2011, at 11:16 AM, Jonathan Taylor wrote:

> Thanks very much for your reply!

You're welcome.

>> What would you sensibly bind to the File's Owner itself, rather than one of 
>> its properties?  In other words, what is bound to or through the object 
>> controller?
> 
> OK, I am not absolutely sure I've understood what you're getting at here, but 
> I will try and answer in two parts - firstly what I originally did, and still 
> do for a number of other windows, followed by the exact situation for this 
> window. It may be that I am doing something wrong in either or both of these, 
> but it may help explain how I've ended up where I have.
> 
> == What I originally did ==
> 
> The "Content Object" of the ObjectController is bound to "File's Owner.self" 
> and various GUI text boxes are bound to variables within the file's owner 
> e.g. a text box bound to Object Controller.selection.speed. Rightly or 
> wrongly, the data model is contained within the window controller - it really 
> didn't seem worth the effort of separating them out.
> 
> Assuming I have set everything up correctly, this was originally suggested to 
> me by a poster on here in order that I could make calls to 
> [myObjectController commitEditing] when I needed to.
> 
> == The actual situation for this window ==
> 
> I'm not sure if this is what you are getting at here, but actually in this 
> specific case there IS a separation between window controller and data model. 
> The window controller is a very lightweight class which keeps a pointer to 
> the object "camera" that actually contains the data model. So the text boxes 
> are actually bound to things like Object 
> Controller.selection.camera.framerate. Are you suggesting that this could be 
> the problem and I should be binding the Object Controller to File's 
> Owner.camera instead of to File's Owner.self, and that this might help break 
> retain cycles?

Well, in this case I certainly think it would be better to bind the object 
controller to File's Owner.camera.  Really, I wasn't so much getting at 
anything in particular, I just find it odd for an object controller to have a 
window controller as its content.  I also find it odd to bind to File's 
Owner.self.  I can't say for sure that either is the source of the problem, but 
they strike me as suspicious.

If your data model is within the window controller and you want a means to use 
-commitEditing, then you should probably make the window controller conform to 
NSEditor and NSEditorRegistration, just as NSController (and thus 
NSObjectController) does.

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

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

Re: Private Method?

[Wim Lewis]

On 6 Nov 2011, at 2:10 PM, Bryan Harrison wrote:

> I'm a total tyro and hope nobody minds if I fire off the occasional 
> incredibly elementary question.  
> 
> I'm reviewing some sample code and am looking at a class with a method 
> declared in @implementation which isn't mentioned in any @interface.
> 
> Is this a private method, something else entirely, or merely sloppy coding?

It's analogous to having a C function that isn't 'static' but also isn't 
declared in a header. Other files don't know it exists, but they can still 
invoke it.

It could be an override of a superclass's method, a private method--- ObjC 
doesn't have 'static' or other access qualifiers for methods, so this is as 
private as it gets--- or sloppy/old code, or it could be a method that callers 
know about through some other route. Perhaps it's declared in a (formal or 
informal) protocol the class conforms to, dynamically looked up (via 
NSSelectorFromString() or key-value-coding), invoked by means of a SEL passed 
to another piece of code (less common now that we have blocks, but a common 
technique for Cocoa callbacks), etc.

> If the former, how does this technique compare with the trick of putting an…
> 
> @interface someClass ()
> - (type) somePrivateMethod;
> @end

As Brad Cox and Joar Wingfors said, that allows you to forward-declare the 
methods that are only used within your implementation (and it's generally good 
practice, IMHO), but unless I'm forgetting something it doesn't change the 
behavior/semantics/accessibility of the method it declares.

(Footnote: Come to think of it, methods that take or return anything other than 
objects *really* should be declared, much like C functions that take or return 
anything other than ints: you can often get away without the declaration, but 
your code will break someday when you least expect it.)


___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

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

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

Re: Private Method?

[Jean-Daniel Dupas]

Le 7 nov. 2011 à 16:19, Kyle Sluder a écrit :

> On Nov 7, 2011, at 4:10 AM, Jean-Daniel Dupas  wrote:
> 
>> 
>> Le 7 nov. 2011 à 08:49, Joar Wingfors a écrit :
>> 
>>> 
>>> In OjbC you don't need to provide declarations for a method "foo" if all 
>>> callers of foo can "see" the definition of foo (ie. if they are themselves 
>>> defined *after* foo). The definition also serves as a declaration in such a 
>>> case.
>> 
>> Note that the 'defined after' constraint is merely a compiler limitation. 
>> Recent clang builds don't require this anymore. You can defined your private 
>> methods anywhere in the implementation.
> 
> Well this is certainly a welcome development. Is this documented or announced 
> anywhere? I don't (currently) subscribe to any clang mailing lists.
> 
> --Kyle Sluder


I don't remember of any announce, but you read see the svn log:

http://llvm.org/viewvc/llvm-project?view=rev&revision=138865


-- Jean-Daniel




___

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: ObjectController preventing WindowController from releasing

[Jonathan Taylor]

Hi Ken,

Thanks very much for your reply!

>> I have a window and window controller which in the absence of an object 
>> controller work fine, and both are deallocated when the window is closed. If 
>> I add an ObjectController to the NIB and bind its "Content Object" to 
>> "File's Owner.self" then the window no longer closes properly.
> 
> What is the File's Owner?  Is the window controller the file's owner?

Yes, the window controller is the file's owner, bound to the window, and with 
the window controller set up to be the delegate for the window. 

>  Is the window controller the one loading the NIB (rather than, say, using 
> NSBundle or NSNib directly)?  NSWindowController has some built-in 
> functionality to break retain cycles for binding through File's Owner when 
> and only when it is the File's Owner and loads the NIB.

Yes it loads the nib from its own init routine, via initWithWindowNibName

> What would you sensibly bind to the File's Owner itself, rather than one of 
> its properties?  In other words, what is bound to or through the object 
> controller?

OK, I am not absolutely sure I've understood what you're getting at here, but I 
will try and answer in two parts - firstly what I originally did, and still do 
for a number of other windows, followed by the exact situation for this window. 
It may be that I am doing something wrong in either or both of these, but it 
may help explain how I've ended up where I have.

== What I originally did ==

The "Content Object" of the ObjectController is bound to "File's Owner.self" 
and various GUI text boxes are bound to variables within the file's owner e.g. 
a text box bound to Object Controller.selection.speed. Rightly or wrongly, the 
data model is contained within the window controller - it really didn't seem 
worth the effort of separating them out.

Assuming I have set everything up correctly, this was originally suggested to 
me by a poster on here in order that I could make calls to [myObjectController 
commitEditing] when I needed to.

== The actual situation for this window ==

I'm not sure if this is what you are getting at here, but actually in this 
specific case there IS a separation between window controller and data model. 
The window controller is a very lightweight class which keeps a pointer to the 
object "camera" that actually contains the data model. So the text boxes are 
actually bound to things like Object Controller.selection.camera.framerate. Are 
you suggesting that this could be the problem and I should be binding the 
Object Controller to File's Owner.camera instead of to File's Owner.self, and 
that this might help break retain 
cycles?___

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: ObjectController preventing WindowController from releasing

[Ken Thomases]

On Nov 7, 2011, at 10:09 AM, Jonathan Taylor wrote:

> I have a window and window controller which in the absence of an object 
> controller work fine, and both are deallocated when the window is closed. If 
> I add an ObjectController to the NIB and bind its "Content Object" to "File's 
> Owner.self" then the window no longer closes properly.

What is the File's Owner?  Is the window controller the file's owner?  Is the 
window controller the one loading the NIB (rather than, say, using NSBundle or 
NSNib directly)?  NSWindowController has some built-in functionality to break 
retain cycles for binding through File's Owner when and only when it is the 
File's Owner and loads the NIB.

What would you sensibly bind to the File's Owner itself, rather than one of its 
properties?  In other words, what is bound to or through the object controller?

> Is there something important that I should be doing here? Should I somehow be 
> releasing the object controller, or indicating to it that it is no longer 
> required?

It shouldn't be required, but, as a last resort, you can set the object 
controller's content to nil in -windowWillClose:.

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

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

UITextField and UIGestureRecognizers

[Olivier Palliere]

Hi Guys,

Working on an iPad app, I'm running into an annoying issue you may have seen 
already.

I have a UITextField on a view. I want the user to be able to edit it by single 
tapping on it, but I want to display a popover to chose from a list when the 
user does a long press on the UITextfield.

To do this, I added a LongPressGestureRecognizer on it and implemented the 
delegate in my controller. 

Now it works fine when I start my app, and I do a long press on the UITextfield 
until I edit it once. When I have edited my field using a single tap, if I try 
to do again a long press gesture, then my recognizer is ignored, the 
UITextField enters edit mode and the magnifying glass is shown.

Is there a way to do what I want to achieve?

I might just not properly end the editing session, but I can't understand why 
it stops working only after I have edited the field once.

Many thanks for your help,
Olivier./.

___

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

ObjectController preventing WindowController from releasing

[Jonathan Taylor]

Sorry. Re-sending under what I think is a more correct title. I only realised 
after I hit send!

Begin forwarded message:

> From: Jonathan Taylor 
> Date: 7 November 2011 16:08:13 GMT
> To: cocoa-dev 
> Subject: ObjectController preventing window from closing
> 
> Hi all,
> 
> This is probably a very basic question, but I am out of ideas and hoping 
> someone can offer some help. I should say that I'm afraid I'm somewhat out of 
> my depth with ObjectControllers: I added some seemingly simple bindings at 
> the recommendation of a poster on here, and I thought I understood what it 
> was doing, but the fact that I am now having retain issues suggests otherwise!
> 
> I have a window and window controller which in the absence of an object 
> controller work fine, and both are deallocated when the window is closed. If 
> I add an ObjectController to the NIB and bind its "Content Object" to "File's 
> Owner.self" then the window no longer closes properly. The window disappears 
> from the screen but the controller is not released as it should be. I get a 
> windowWillClose notification, but the one [self autorelease] that I do from 
> there is not enough to release the window. The controller appears to be still 
> retained by the ObjectController. In the actual NIB there are various GUI 
> elements bound to the object controller, but I have removed all those 
> bindings, just leaving the single binding from the OC to "File's Owner.self" 
> and I still have this problem of non-deallocation. If I remove that final 
> binding, so the object controller is completely isolated, the window 
> controller releases as one would expect (though I suspect the object 
> controller may be leaked).
> 
> Is there something important that I should be doing here? Should I somehow be 
> releasing the object controller, or indicating to it that it is no longer 
> required? I realise that the information I've given here may be incomplete, 
> because I don't even know what factors may be important in understanding the 
> problem! Any advice would be very welcome though, as I am completely out of 
> ideas...
> 
> Regards,
> 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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

ObjectController preventing window from closing

[Jonathan Taylor]

Hi all,

This is probably a very basic question, but I am out of ideas and hoping 
someone can offer some help. I should say that I'm afraid I'm somewhat out of 
my depth with ObjectControllers: I added some seemingly simple bindings at the 
recommendation of a poster on here, and I thought I understood what it was 
doing, but the fact that I am now having retain issues suggests otherwise!

I have a window and window controller which in the absence of an object 
controller work fine, and both are deallocated when the window is closed. If I 
add an ObjectController to the NIB and bind its "Content Object" to "File's 
Owner.self" then the window no longer closes properly. The window disappears 
from the screen but the controller is not released as it should be. I get a 
windowWillClose notification, but the one [self autorelease] that I do from 
there is not enough to release the window. The controller appears to be still 
retained by the ObjectController. In the actual NIB there are various GUI 
elements bound to the object controller, but I have removed all those bindings, 
just leaving the single binding from the OC to "File's Owner.self" and I still 
have this problem of non-deallocation. If I remove that final binding, so the 
object controller is completely isolated, the window controller releases as one 
would expect (though I suspect the object controller may be leaked).

Is there something important that I should be doing here? Should I somehow be 
releasing the object controller, or indicating to it that it is no longer 
required? I realise that the information I've given here may be incomplete, 
because I don't even know what factors may be important in understanding the 
problem! Any advice would be very welcome though, as I am completely out of 
ideas...

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

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

Re: Allocating too much memory kills my App rather than returning NULL

[Greg Parker]

On Nov 4, 2011, at 6:40 PM, Don Quixote de la Mancha wrote:
> My code checks that calloc() returns valid pointers for each
> allocation attempted when creating a new grid.  If all the allocations
> succeed, I copy the data in the old grid into the center of the new
> one, then free() each array in the old grid.
> 
> If calloc() ever returns NULL while attempting to allocate the new
> grid, I back out all of the successful allocations by passing each
> array pointer to free().  Then I display an alert to the user to
> advise them that there is not enough memory for their desired grid
> size, and suggest trying a smaller one.

This is not a safe pattern in a multi-threaded application. You may be checking 
for failed allocations and responding correctly, but to a close approximation 
no code anywhere else does so. For example, objc_msgSend sometimes needs to 
allocate memory, and has no way to recover if it cannot. If some other thread 
were working at the same time you caused allocation failures, then that thread 
is likely to crash.


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

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

Re: How to highlight the current line in NSTextView?

[Ross Carter]

On Nov 6, 2011, at 12:46 PM, Keary Suska wrote:

>  you should then be able to use 
> lineFragmentUsedRectForGlyphAtIndex:effectiveRange: and passing its return 
> value to -setSelectedRange:. 

I don't think you want to change the selected range. You just want to draw a 
background color.
___

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: Private Method?

[Kyle Sluder]

On Nov 7, 2011, at 4:10 AM, Jean-Daniel Dupas  wrote:

> 
> Le 7 nov. 2011 à 08:49, Joar Wingfors a écrit :
> 
>> 
>> In OjbC you don't need to provide declarations for a method "foo" if all 
>> callers of foo can "see" the definition of foo (ie. if they are themselves 
>> defined *after* foo). The definition also serves as a declaration in such a 
>> case.
> 
> Note that the 'defined after' constraint is merely a compiler limitation. 
> Recent clang builds don't require this anymore. You can defined your private 
> methods anywhere in the implementation.

Well this is certainly a welcome development. Is this documented or announced 
anywhere? I don't (currently) subscribe to any clang mailing lists.

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

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

Re: Any success with SMLoginItemSetEnabled?

[Kyle Sluder]

On Nov 5, 2011, at 3:19 PM, Manfred Schwind  wrote:

> Hi,
> 
> has anybody successfully used SMLoginItemSetEnabled?
> It always returns false for me, whatever I try.

>From the rest of your message it sounds like you're trying to use this 
>function from within a sandbox. It is a known bug (by developers, anyway) that 
>this function does not work from within a sandbox. You should file a bug 
>report at http://bugreport.apple.com to increase this bug's visibility to the 
>relevant engineering team.

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

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

Re: Private Method?

[Jean-Daniel Dupas]

Le 7 nov. 2011 à 08:49, Joar Wingfors a écrit :

> 
> On 6 nov 2011, at 14:10, Bryan Harrison wrote:
> 
>> I'm a total tyro and hope nobody minds if I fire off the occasional 
>> incredibly elementary question.  
>> 
>> I'm reviewing some sample code and am looking at a class with a method 
>> declared in @implementation which isn't mentioned in any @interface.
>> 
>> Is this a private method, something else entirely, or merely sloppy coding?  
>> 
>> If the former, how does this technique compare with the trick of putting an…
>> 
>> @interface someClass ()
>> - (type) somePrivateMethod;
>> @end
>> 
>> …in the implementation?
> 
> 
> Hello Bryan,
> 
> That would be a private method, or - like Graham pointed out - an override of 
> a method from a superclass. I guess it could also be "dead" code (not called 
> from anywhere), but that's typically not very likely.
> 
> In OjbC you don't need to provide declarations for a method "foo" if all 
> callers of foo can "see" the definition of foo (ie. if they are themselves 
> defined *after* foo). The definition also serves as a declaration in such a 
> case.

Note that the 'defined after' constraint is merely a compiler limitation. 
Recent clang builds don't require this anymore. You can defined your private 
methods anywhere in the implementation.

> Sure you can provide private declarations in a class extension, but why would 
> you? To avoid repetition is a virtue, and one of the more important ones at 
> that. 

It may be useful to workaround the afore-mentioned limitation. 

> 
> j o a r

-- Jean-Daniel




___

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

What is the right way to move a UIDocument to a new URL?

[Roland King]

I'm a little lost in all the UIDocument and NSFileCoordinator code .. 

I have some UIDocuments and they are named, as is the default 
/Documents/.. I understand why that's the 
recommendation as you can get the name of a document without having to download 
or open it. 

Now I'm implementing renaming, so I need to change the URL for a document to 
the new one, I don't really want to just copy the contents to a new URL and 
then delete the old one (or do I?).

I think just calling NSFileManager moveItemAtURL:toURL:error won't play nicely 
with the file presenter stuff, nor will it cause the UIDocument fileURL to be 
updated, which is what's used for fileName. 

Would it be correct to just instantiate an NSFileCoordinator, then call 
coordinateWritingItemAtURL:options:error:byAccessor on a background thread, 
then call itemAtURL:didMoveToURL: or is there another way you're supposed to do 
this properly with UIDocument (like write a new one and delete the old one or 
something else I'm missing). 

Similarly if this were iCloud, same applies? Can I just move to a new URL in 
the ubiquity container or I have to do more to make the URL 'official' before 
moving to it? ___

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

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

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