Re: NSString looses Umlaute

[Alexander Reichstadt]

Yes, you are right, but it does not make a difference, I tried all encodings. 
This is a DBF file. From the DBF file format description the header is binary 
and the rest is ASCII.

I found an older post from someone with French special chars that went lost:
http://stackoverflow.com/questions/4913499/utf8-character-decoding-in-objective-c

But the solution suggested there doesn't work:
NSString *correctString = [NSString stringWithCString:[utf8String 
cStringUsingEncoding:NSISOLatin1StringEncoding] encoding:NSUTF8StringEncoding];
I know the content of the DBF file. I don't want to write a DBF parser, I only 
want to read this specific file and it does correctly read all fields and 
lines, but the Umlaute are still lost. It does work correctly on the Windows 
side using the browser app for that particular database.

The reason I used the percent-lines was to see what happens to the Umlaute, and 
inspecting them inbetween changing to and from percent escaped strings they 
seem to be handled correctly.

Alex

Am 22.12.2011 um 02:18 schrieb Ben Kennedy:

> On 21 Dec 2011, at 4:45 pm, Alexander Reichstadt wrote:
> 
>>  NSString *theContent = [[NSString alloc] initWithData:theData 
>> encoding:NSASCIIStringEncoding];
>>   theContent = [[theContent componentsSeparatedByString:@"\r"] 
>> objectAtIndex:1]; 
>>   theContent = [theContent 
>> stringByAddingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
>>   theContent = [theContent 
>> stringByReplacingPercentEscapesUsingEncoding:NSUTF8StringEncoding];
> 
> Is this really your code?  What is the purpose of the latter two lines?  They 
> are completely reciprocal (i.e. redundant).
> 
>> I can even see it handles everything correctly in NSLog, first I see the 
>> unicode for an Umlaut, then it converts it to the correct percent value, 
>> like like ö to 94, but when the final NSString is printed to an NSControl, 
>> the Umlaute are missing or garbled.
>> 
>> The original file is ascii-encoded.
> 
> Impossible.  ASCII does not represent any characters with diacritical marks.  
> Perhaps the original file is ISO-Latin-1 encoded.  You could try using 
> NSISOLatin1StringEncoding.
> 
> b
> 
> --
> Ben Kennedy, chief magician
> Zygoat Creative Technical Services
> http://www.zygoat.ca
> 

___

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

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

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

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

Re: NSString looses Umlaute

[vincent habchi]

Le 22 déc. 2011 à 09:13, Alexander Reichstadt  a écrit :

> Yes, you are right, but it does not make a difference, I tried all encodings.

Did you try UTF-8 encoding?

Besides, if you open your file with an external application, e.g. OpenOffice or 
TextWrangler, what happens?

Vincent

___

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: NSString looses Umlaute

[Alexander Reichstadt]

Yes, tried NSUTF8StringEncoding, I really tried all the ones I found in the 
NSString encoding documentation.

When I import this file as DBF into FileMaker Pro it looks just as bad. But 
when I import it into a MySql it works fine.

Here an example of what NSLog says:

"R\U0094h.",
"R\U0094hrchen"

It should instead say Röhrchen.

Is the escape sequence even correct or shouldn't it have two slashes instead?

Alex



Am 22.12.2011 um 09:49 schrieb vincent habchi:

> Le 22 déc. 2011 à 09:13, Alexander Reichstadt  a écrit :
> 
>> Yes, you are right, but it does not make a difference, I tried all encodings.
> 
> Did you try UTF-8 encoding?
> 
> Besides, if you open your file with an external application, e.g. OpenOffice 
> or TextWrangler, what happens?
> 
> Vincent
> 

___

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: NSString looses Umlaute

[Vincent Habchi]

> Yes, tried NSUTF8StringEncoding, I really tried all the ones I found in the 
> NSString encoding documentation.
> 
> When I import this file as DBF into FileMaker Pro it looks just as bad. But 
> when I import it into a MySql it works fine.
> 
> Here an example of what NSLog says:
> 
> "R\U0094h.",
> "R\U0094hrchen"
> 
> It should instead say Röhrchen.

It looks like you string is UTF-16 based (\U0094 looks like UTF-16).
But ö should be \U00F6, not \U0094 or 0xC3 0xB6 in UTF-8.

Something is rotten in your tubes! ;)

Cheers,
Vincent___

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: NSString looses Umlaute

[Joar Wingfors]

On 21 dec 2011, at 16:45, Alexander Reichstadt wrote:

> NSString eats the Umlaute. How do I tell NSString to not do that?


If you provide the correct encoding when creating a NSString from an external 
representation, all will be well. If you don't, then you'll end up with the 
type of issues that you've been reporting here. This is all very simple and 
straight forward. The only way that you really can screw up is by providing an 
encoding that doesn't match with the string data that you're trying to 
interpret. That and, I guess, not providing "valid" string data - Which leads 
me to:


On 22 dec 2011, at 00:13, Alexander Reichstadt wrote:

> This is a DBF file. From the DBF file format description the header is binary 
> and the rest is ASCII.


Are you stripping out the header before trying to interpret the data as a 
string?


> I don't want to write a DBF parser, I only want to read this specific file 
> and it does correctly read all fields and lines, but the Umlaute are still 
> lost. It does work correctly on the Windows side using the browser app for 
> that particular database.



The other tools that you've mentioned, maybe they're actually parsing the file 
- And not simply trying to load the whole thing as text?


Joar


___

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

How to get the phone number use ios sdk in iphone.

[吴明]

How to get the phone number use ios sdk in iphone.?
___

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: NSString looses Umlaute

[Alexander Reichstadt]

OK, I found a way to import it into FileMaker. It looks good when I use DOS 
Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF 
and NSString is toll free bridged, but does this apply to the encodings as 
well? There is some post from 2000 by Ali Ozer that would suggest it's not the 
case.




Am 22.12.2011 um 10:24 schrieb Vincent Habchi:

>> Yes, tried NSUTF8StringEncoding, I really tried all the ones I found in the 
>> NSString encoding documentation.
>> 
>> When I import this file as DBF into FileMaker Pro it looks just as bad. But 
>> when I import it into a MySql it works fine.
>> 
>> Here an example of what NSLog says:
>> 
>>"R\U0094h.",
>>"R\U0094hrchen"
>> 
>> It should instead say Röhrchen.
> 
> It looks like you string is UTF-16 based (\U0094 looks like UTF-16).
> But ö should be \U00F6, not \U0094 or 0xC3 0xB6 in UTF-8.
> 
> Something is rotten in your tubes! ;)
> 
> Cheers,
> Vincent

___

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 get the phone number use ios sdk in iphone.

[Kyle Sluder]

2011/12/22 吴明 :
> How to get the phone number use ios sdk in iPhone.?

Not gonna happen. iOS does not allow you to access this information.

--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: NSString looses Umlaute

[Vincent Habchi]

> OK, I found a way to import it into FileMaker. It looks good when I use DOS 
> Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF 
> and NSString is toll free bridged, but does this apply to the encodings as 
> well? There is some post from 2000 by Ali Ozer that would suggest it's not 
> the case.

Can you post your file, if it not too big?

V.


___

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: NSString looses Umlaute

[Kyle Sluder]

On Thu, Dec 22, 2011 at 1:42 AM, Alexander Reichstadt  wrote:
> OK, I found a way to import it into FileMaker. It looks good when I use DOS 
> Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF 
> and NSString is toll free bridged, but does this apply to the encodings as 
> well? There is some post from 2000 by Ali Ozer that would suggest it's not 
> the case.

>From Aki Inoue:

"You can convert CFStringEncoding to NSStringEncoding using
CFStringConvertEncodingToNSStringEncoding()."

http://www.cocoabuilder.com/archive/cocoa/89000-extending-nsstring-nsdata-datausingencoding-nsstringencoding-encoding.html

Sounds like you want to use this function to convert
kCFStringEncodingDOSLatinUS to an NSString encoding.

--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: NSString looses Umlaute

[Jean-Daniel Dupas]

Le 22 déc. 2011 à 10:42, Alexander Reichstadt a écrit :

> OK, I found a way to import it into FileMaker. It looks good when I use DOS 
> Encoding. But when I use kCFStringEncoding derivates I had no luck. I know CF 
> and NSString is toll free bridged, but does this apply to the encodings as 
> well? There is some post from 2000 by Ali Ozer that would suggest it's not 
> the case

No. NS and CF encoding don't have the same value.

You can use CFStringConvertEncodingToNSStringEncoding() and 
CFStringConvertNSStringEncodingToEncoding() to convert encoding.


> 
> 
> Am 22.12.2011 um 10:24 schrieb Vincent Habchi:
> 
>>> Yes, tried NSUTF8StringEncoding, I really tried all the ones I found in the 
>>> NSString encoding documentation.
>>> 
>>> When I import this file as DBF into FileMaker Pro it looks just as bad. But 
>>> when I import it into a MySql it works fine.
>>> 
>>> Here an example of what NSLog says:
>>> 
>>>   "R\U0094h.",
>>>   "R\U0094hrchen"
>>> 
>>> It should instead say Röhrchen.
>> 
>> It looks like you string is UTF-16 based (\U0094 looks like UTF-16).
>> But ö should be \U00F6, not \U0094 or 0xC3 0xB6 in UTF-8.
>> 
>> Something is rotten in your tubes! ;)
>> 
>> Cheers,
>> Vincent
> 
> ___
> 
> 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/devlists%40shadowlab.org
> 
> This email sent to devli...@shadowlab.org

-- 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: NSString looses Umlaute

[Alexander Reichstadt]

Thanks, it works. The following solved the problem, where theChoice is a URL to 
a local file from an NSOpenPanel:

NSData *theData = [NSData dataWithContentsOfURL:theChoice];
NSString *theContent = [[NSString alloc] initWithData:theData encoding:

CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingDOSLatin1)
];



Am 22.12.2011 um 10:50 schrieb Jean-Daniel Dupas:

> 
> Le 22 déc. 2011 à 10:42, Alexander Reichstadt a écrit :
> 
>> OK, I found a way to import it into FileMaker. It looks good when I use DOS 
>> Encoding. But when I use kCFStringEncoding derivates I had no luck. I know 
>> CF and NSString is toll free bridged, but does this apply to the encodings 
>> as well? There is some post from 2000 by Ali Ozer that would suggest it's 
>> not the case
> 
> No. NS and CF encoding don't have the same value.
> 
> You can use CFStringConvertEncodingToNSStringEncoding() and 
> CFStringConvertNSStringEncodingToEncoding() to convert encoding.
> 
> 
>> 
>> 
>> Am 22.12.2011 um 10:24 schrieb Vincent Habchi:
>> 
 Yes, tried NSUTF8StringEncoding, I really tried all the ones I found in 
 the NSString encoding documentation.
 
 When I import this file as DBF into FileMaker Pro it looks just as bad. 
 But when I import it into a MySql it works fine.
 
 Here an example of what NSLog says:
 
  "R\U0094h.",
  "R\U0094hrchen"
 
 It should instead say Röhrchen.
>>> 
>>> It looks like you string is UTF-16 based (\U0094 looks like UTF-16).
>>> But ö should be \U00F6, not \U0094 or 0xC3 0xB6 in UTF-8.
>>> 
>>> Something is rotten in your tubes! ;)
>>> 
>>> Cheers,
>>> Vincent
>> 
>> ___
>> 
>> 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/devlists%40shadowlab.org
>> 
>> This email sent to devli...@shadowlab.org
> 
> -- 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

Debugging hints

[Martin Hewitson]

Dear list,

I have a very complex document based app. If I run the app compiled with 
garbage collection support, then I can open and close document windows without 
problems. With garbage collected disabled, opening and closing the document 
windows results in crashes. Clearly I have a memory management issue. My 
problem is that the crash report doesn't help me. Running in Xcode, the 
debugger drops out in NSApplicationMain with the following back trace:

#0  0x7fff91380398 in objc_msgSend_vtable14 ()
No symbol table info available.
#1  0x7fff8ce33110 in CFRelease ()
No symbol table info available.
#2  0x7fff8ce5b5f0 in -[__NSArrayM dealloc] ()
No symbol table info available.
#3  0x7fff8bb06dd2 in -[NSObjectController _dealloc] ()
No symbol table info available.
#4  0x7fff8b8fb6a4 in -[NSArrayController _dealloc] ()
No symbol table info available.
#5  0x7fff8b9aa1bc in -[NSController dealloc] ()
No symbol table info available.
#6  0x7fff8b8a34d5 in -[_NSBindingInfo dealloc] ()
No symbol table info available.
#7  0x7fff8ce33110 in CFRelease ()
No symbol table info available.
#8  0x7fff8ce5b5f0 in -[__NSArrayM dealloc] ()
No symbol table info available.
#9  0x7fff8b838e7d in -[NSBinder _dealloc] ()
No symbol table info available.
#10 0x7fff8b838e1e in -[NSBinder dealloc] ()
No symbol table info available.
#11 0x7fff9138403c in (anonymous namespace)::AutoreleasePoolPage::pop ()
No symbol table info available.
#12 0x7fff8ce5bf75 in _CFAutoreleasePoolPop ()
No symbol table info available.
#13 0x7fff8ce634e4 in __CFRunLoopRun ()
No symbol table info available.
#14 0x7fff8ce62ae6 in CFRunLoopRunSpecific ()
No symbol table info available.
#15 0x7fff88bcd3d3 in RunCurrentEventLoopInMode ()
No symbol table info available.
#16 0x7fff88bd463d in ReceiveNextEventCommon ()
No symbol table info available.
#17 0x7fff88bd44ca in BlockUntilNextEventMatchingListInMode ()
No symbol table info available.
#18 0x7fff8b6363f1 in _DPSNextEvent ()
No symbol table info available.
#19 0x7fff8b635cf5 in -[NSApplication 
nextEventMatchingMask:untilDate:inMode:dequeue:] ()
No symbol table info available.
#20 0x7fff8b63262d in -[NSApplication run] ()
No symbol table info available.
#21 0x7fff8b8b180c in NSApplicationMain ()


Can anyone offer any hints or suggestions as to how I can better go about 
finding this memory problem?

(By the way, the reason I want to switch off the garbage collector is that I 
get intermittent crashes to do with the garbage collector queue; googling 
revealed that others have seen these crashes and the consensus seemed to be, 
switch off garbage collection. In any case, I don't like the fact that I can't 
switch off garbage collection due to what must be a bug somewhere.)


Best wishes,

Martin




Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer 
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: martin.hewit...@aei.mpg.de
WWW: http://www.aei.mpg.de/~hewitson






___

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

No more warning about registered observers on dealloc with ARC?

[Roland King]

I've managed to commit the same error twice in 3 weeks, just long enough apart 
for me to forget what I did the last time and spend an age debugging again. 

Basically in one of my property setters on an object I set up KVO on the object 
set into the property (and of course tear down KVO on the previous object if 
there was one). Much later on I find myself crashing in obj_msgSend() trying to 
send a retain to a piece of garbage. In each case the problem is that I was not 
setting the property nil in the dealloc method (which would tear down the KVO) 
so a spurious KVO hung around and was eventually triggered leading to a crash 
down the road. This is ARC on iOS by the way. 

You used to get a handy message logged to the console when an object with KVO 
registered on it was deallocated, but not in either of these two cases (and I 
can quite clearly demonstrate that the object was dealloc'ed with dangling 
KVO). Has that message been removed, or is something internal in ARC causing 
the runtime not to notice? I'm quite sure that fairly recently some code I 
still have which doesn't use ARC was emitting this message using the same 
compiler and version of Xcode. 

One learned lesson here is that I have too-quickly become used to what ARC does 
and have become a little sloppy with dealloc(), not having to release things in 
it has meant I'm not forced to think about the other things I might need to do 
there, a habit I need to get back into. 

Also, I found zombies didn't help me here, I did eventually track it down by 
working through a whole mess of malloc_debug (and looking at the then-obvious 
stack trace). 




___

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: Debugging hints

[Mike Abdullah]

Did you actually write this app to be dual-mode, or are you under the 
impression that turning off garbage collection will magically fix things?

Going by the stack trace, this is a classic zombie. Use Instruments to find the 
bug.

On 22 Dec 2011, at 10:48, Martin Hewitson wrote:

> Dear list,
> 
> I have a very complex document based app. If I run the app compiled with 
> garbage collection support, then I can open and close document windows 
> without problems. With garbage collected disabled, opening and closing the 
> document windows results in crashes. Clearly I have a memory management 
> issue. My problem is that the crash report doesn't help me. Running in Xcode, 
> the debugger drops out in NSApplicationMain with the following back trace:
> 
> #0  0x7fff91380398 in objc_msgSend_vtable14 ()
> No symbol table info available.
> #1  0x7fff8ce33110 in CFRelease ()
> No symbol table info available.
> #2  0x7fff8ce5b5f0 in -[__NSArrayM dealloc] ()
> No symbol table info available.
> #3  0x7fff8bb06dd2 in -[NSObjectController _dealloc] ()
> No symbol table info available.
> #4  0x7fff8b8fb6a4 in -[NSArrayController _dealloc] ()
> No symbol table info available.
> #5  0x7fff8b9aa1bc in -[NSController dealloc] ()
> No symbol table info available.
> #6  0x7fff8b8a34d5 in -[_NSBindingInfo dealloc] ()
> No symbol table info available.
> #7  0x7fff8ce33110 in CFRelease ()
> No symbol table info available.
> #8  0x7fff8ce5b5f0 in -[__NSArrayM dealloc] ()
> No symbol table info available.
> #9  0x7fff8b838e7d in -[NSBinder _dealloc] ()
> No symbol table info available.
> #10 0x7fff8b838e1e in -[NSBinder dealloc] ()
> No symbol table info available.
> #11 0x7fff9138403c in (anonymous namespace)::AutoreleasePoolPage::pop ()
> No symbol table info available.
> #12 0x7fff8ce5bf75 in _CFAutoreleasePoolPop ()
> No symbol table info available.
> #13 0x7fff8ce634e4 in __CFRunLoopRun ()
> No symbol table info available.
> #14 0x7fff8ce62ae6 in CFRunLoopRunSpecific ()
> No symbol table info available.
> #15 0x7fff88bcd3d3 in RunCurrentEventLoopInMode ()
> No symbol table info available.
> #16 0x7fff88bd463d in ReceiveNextEventCommon ()
> No symbol table info available.
> #17 0x7fff88bd44ca in BlockUntilNextEventMatchingListInMode ()
> No symbol table info available.
> #18 0x7fff8b6363f1 in _DPSNextEvent ()
> No symbol table info available.
> #19 0x7fff8b635cf5 in -[NSApplication 
> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
> No symbol table info available.
> #20 0x7fff8b63262d in -[NSApplication run] ()
> No symbol table info available.
> #21 0x7fff8b8b180c in NSApplicationMain ()
> 
> 
> Can anyone offer any hints or suggestions as to how I can better go about 
> finding this memory problem?
> 
> (By the way, the reason I want to switch off the garbage collector is that I 
> get intermittent crashes to do with the garbage collector queue; googling 
> revealed that others have seen these crashes and the consensus seemed to be, 
> switch off garbage collection. In any case, I don't like the fact that I 
> can't switch off garbage collection due to what must be a bug somewhere.)
> 
> 
> Best wishes,
> 
> Martin
> 
> 
> 
> 
> Martin Hewitson
> Albert-Einstein-Institut
> Max-Planck-Institut fuer 
>Gravitationsphysik und Universitaet Hannover
> Callinstr. 38, 30167 Hannover, Germany
> Tel: +49-511-762-17121, Fax: +49-511-762-5861
> E-Mail: martin.hewit...@aei.mpg.de
> WWW: http://www.aei.mpg.de/~hewitson
> 
> 
> 
> 
> 
> 
> ___
> 
> 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/cocoadev%40mikeabdullah.net
> 
> This email sent to cocoa...@mikeabdullah.net

___

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

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

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

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

Re: NSString looses Umlaute

[Mike Abdullah]

On 22 Dec 2011, at 09:59, Alexander Reichstadt wrote:

> Thanks, it works. The following solved the problem, where theChoice is a URL 
> to a local file from an NSOpenPanel:
> 
>NSData *theData = [NSData dataWithContentsOfURL:theChoice];
>NSString *theContent = [[NSString alloc] initWithData:theData encoding:
>
> CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingDOSLatin1)
>];

You can initialise a string directly from the contents of a URL you realise, 
right? Or are you saying that doesn't work, but this technique somehow does?

___

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: Debugging hints

[Martin Hewitson]

On 22, Dec, 2011, at 02:39 PM, Mike Abdullah wrote:

> Did you actually write this app to be dual-mode, or are you under the 
> impression that turning off garbage collection will magically fix things?

To be honest, I wrote the app assuming garbage collection was off. I think it 
must have got turned on by mistake, perhaps during the move to Xcode 4. Not 
sure.

I am under the impression (according to what others have written) that turning 
off garbage collection will stop the crashes in the garbage collection queue. I 
think this is a reported bug, but I didn't follow that thread very long. I just 
was surprised to find garbage collection on in the app, so I switched it off. 
This revealed the bug, which I'd like now to fix, of course.

> 
> Going by the stack trace, this is a classic zombie. Use Instruments to find 
> the bug.

OK, I'll try that. Thanks.

Martin


> 
> On 22 Dec 2011, at 10:48, Martin Hewitson wrote:
> 
>> Dear list,
>> 
>> I have a very complex document based app. If I run the app compiled with 
>> garbage collection support, then I can open and close document windows 
>> without problems. With garbage collected disabled, opening and closing the 
>> document windows results in crashes. Clearly I have a memory management 
>> issue. My problem is that the crash report doesn't help me. Running in 
>> Xcode, the debugger drops out in NSApplicationMain with the following back 
>> trace:
>> 
>> #0  0x7fff91380398 in objc_msgSend_vtable14 ()
>> No symbol table info available.
>> #1  0x7fff8ce33110 in CFRelease ()
>> No symbol table info available.
>> #2  0x7fff8ce5b5f0 in -[__NSArrayM dealloc] ()
>> No symbol table info available.
>> #3  0x7fff8bb06dd2 in -[NSObjectController _dealloc] ()
>> No symbol table info available.
>> #4  0x7fff8b8fb6a4 in -[NSArrayController _dealloc] ()
>> No symbol table info available.
>> #5  0x7fff8b9aa1bc in -[NSController dealloc] ()
>> No symbol table info available.
>> #6  0x7fff8b8a34d5 in -[_NSBindingInfo dealloc] ()
>> No symbol table info available.
>> #7  0x7fff8ce33110 in CFRelease ()
>> No symbol table info available.
>> #8  0x7fff8ce5b5f0 in -[__NSArrayM dealloc] ()
>> No symbol table info available.
>> #9  0x7fff8b838e7d in -[NSBinder _dealloc] ()
>> No symbol table info available.
>> #10 0x7fff8b838e1e in -[NSBinder dealloc] ()
>> No symbol table info available.
>> #11 0x7fff9138403c in (anonymous namespace)::AutoreleasePoolPage::pop ()
>> No symbol table info available.
>> #12 0x7fff8ce5bf75 in _CFAutoreleasePoolPop ()
>> No symbol table info available.
>> #13 0x7fff8ce634e4 in __CFRunLoopRun ()
>> No symbol table info available.
>> #14 0x7fff8ce62ae6 in CFRunLoopRunSpecific ()
>> No symbol table info available.
>> #15 0x7fff88bcd3d3 in RunCurrentEventLoopInMode ()
>> No symbol table info available.
>> #16 0x7fff88bd463d in ReceiveNextEventCommon ()
>> No symbol table info available.
>> #17 0x7fff88bd44ca in BlockUntilNextEventMatchingListInMode ()
>> No symbol table info available.
>> #18 0x7fff8b6363f1 in _DPSNextEvent ()
>> No symbol table info available.
>> #19 0x7fff8b635cf5 in -[NSApplication 
>> nextEventMatchingMask:untilDate:inMode:dequeue:] ()
>> No symbol table info available.
>> #20 0x7fff8b63262d in -[NSApplication run] ()
>> No symbol table info available.
>> #21 0x7fff8b8b180c in NSApplicationMain ()
>> 
>> 
>> Can anyone offer any hints or suggestions as to how I can better go about 
>> finding this memory problem?
>> 
>> (By the way, the reason I want to switch off the garbage collector is that I 
>> get intermittent crashes to do with the garbage collector queue; googling 
>> revealed that others have seen these crashes and the consensus seemed to be, 
>> switch off garbage collection. In any case, I don't like the fact that I 
>> can't switch off garbage collection due to what must be a bug somewhere.)
>> 
>> 
>> Best wishes,
>> 
>> Martin
>> 
>> 
>> 
>> 
>> Martin Hewitson
>> Albert-Einstein-Institut
>> Max-Planck-Institut fuer 
>>   Gravitationsphysik und Universitaet Hannover
>> Callinstr. 38, 30167 Hannover, Germany
>> Tel: +49-511-762-17121, Fax: +49-511-762-5861
>> E-Mail: martin.hewit...@aei.mpg.de
>> WWW: http://www.aei.mpg.de/~hewitson
>> 
>> 
>> 
>> 
>> 
>> 
>> ___
>> 
>> 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/cocoadev%40mikeabdullah.net
>> 
>> This email sent to cocoa...@mikeabdullah.net
> 


Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer 
Gravitationsphysik und 

Re: Debugging hints

[Mike Abdullah]

On 22 Dec 2011, at 14:03, Martin Hewitson wrote:

> 
> On 22, Dec, 2011, at 02:39 PM, Mike Abdullah wrote:
> 
>> Did you actually write this app to be dual-mode, or are you under the 
>> impression that turning off garbage collection will magically fix things?
> 
> To be honest, I wrote the app assuming garbage collection was off. I think it 
> must have got turned on by mistake, perhaps during the move to Xcode 4. Not 
> sure.
> 
> I am under the impression (according to what others have written) that 
> turning off garbage collection will stop the crashes in the garbage 
> collection queue. I think this is a reported bug, but I didn't follow that 
> thread very long. I just was surprised to find garbage collection on in the 
> app, so I switched it off. This revealed the bug, which I'd like now to fix, 
> of course.

I see. Well, turning it off will certainly fix that particular crash. But it 
doesn't surprise me at all that an app which has had the safety net of GC for a 
while will have picked up some memory management errors. The static analyzer 
may well find a lot of them.

___

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:Re: How to get the phone number use ios sdk in iphone.

[吴明]

Thanks
I got some of the way by Google.
1.
[[NSUserDefaults standardUserDefaults] stringForKey:@"SBFormattedPhoneNumber"];


2.
Use CTSettingCopyMyPhoneNumber();
This function is included in Coretelephony framework.


3.
Get all contacts phone number by addressbook framework. Then get the phone 
number. 


I don't know whether these  ways are feasible.

在 2011-12-22 17:42:44，"Kyle Sluder"  写道：
>2011/12/22 吴明 :
>> How to get the phone number use ios sdk in iPhone.?
>
>Not gonna happen. iOS does not allow you to access this information.
>
>--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: NSString looses Umlaute

[Alexander Reichstadt]

Thanks, but I  have not tried. My thinking went along the lines of if I read 
the string directly from the URL I have no control over what encoding is being 
used for reading or it defaults to something. If I first read as data, I can do 
with those bytes as I please. The DBF file is not in one consistent encoding 
from start to finish. The DBF file format documentation says the header is in 
binary, then there is a linefeed (\r), then there is the body. Each field has a 
fixed length, wether used or not doesn't matter, the unused rest is filled with 
spaces.

So, I read the file as data, stringily it as DOSLatin1, split it at the 
linefeed and read the body according to the field definitions I am given. They 
are guaranteed, so maybe some day I get around to writing a nice DBF parser, 
but until then I go by the guaranteed field lengths.

I tested it now on a couple of files and it works without a hitch.


Am 22.12.2011 um 14:40 schrieb Mike Abdullah:

> 
> On 22 Dec 2011, at 09:59, Alexander Reichstadt wrote:
> 
>> Thanks, it works. The following solved the problem, where theChoice is a URL 
>> to a local file from an NSOpenPanel:
>> 
>>   NSData *theData = [NSData dataWithContentsOfURL:theChoice];
>>   NSString *theContent = [[NSString alloc] initWithData:theData encoding:
>>   
>> CFStringConvertEncodingToNSStringEncoding(kCFStringEncodingDOSLatin1)
>>   ];
> 
> You can initialise a string directly from the contents of a URL you realise, 
> right? Or are you saying that doesn't work, but this technique somehow does?
> 

___

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: NSString looses Umlaute

[Ken Thomases]

On Dec 22, 2011, at 9:54 AM, Alexander Reichstadt wrote:

> The DBF file format documentation says the header is in binary, then there is 
> a linefeed (\r), then there is the body. Each field has a fixed length, 
> wether used or not doesn't matter, the unused rest is filled with spaces.
> 
> So, I read the file as data, stringily it as DOSLatin1, split it at the 
> linefeed and read the body according to the field definitions I am given. 
> They are guaranteed, so maybe some day I get around to writing a nice DBF 
> parser, but until then I go by the guaranteed field lengths.
> 
> I tested it now on a couple of files and it works without a hitch.

If the header is binary, then any of its bytes might be 0x0D, which is the same 
as \r (or did you actually mean it when you said "linefeed" which is 0x0A or 
\n?), so your approach will fail.  In all probability, the header is a fixed 
length and you can just skip that part of the data.  Either way, if this is 
meant for more than a casual, one-off, in-house app, you'll have to find a more 
reliable technique.

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: How to get the phone number use ios sdk in iphone.

[Keary Suska]

On Dec 22, 2011, at 8:37 AM, 吴明 wrote:

> 1. [[NSUserDefaults standardUserDefaults] 
> stringForKey:@"SBFormattedPhoneNumber"];
> 
> 2. Use CTSettingCopyMyPhoneNumber();
> This function is included in Coretelephony framework.
> 
> 3. Get all contacts phone number by addressbook framework. Then get the phone 
> number. 


How you should get the number is by asking the user for it. Items #1 and #2 may 
get your app rejected. In fact, #1 is known to cause almost definite app 
rejection. #3 is error prone but if you ask the user to confirm that may be 
acceptable. Also make sure you scour the developer agreement about how you need 
to ask for this kind of information and how you use it. Misuse could get you 
permanently banned.

HTH,

Keary Suska
Esoteritech, Inc.
"Demystifying technology for your home or business"

___

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: presentingViewController docs patently false

[Matt Neuburg]

On Mon, 19 Dec 2011 15:55:49 -0800, Matt Neuburg  said:
>The docs say:
>
>> @property(nonatomic, readonly) UIViewController *presentingViewController
>> Discussion
>> The default implementation of this property walks up the view hierarchy, 
>> starting from this view controller. The first view controller it finds that 
>> received the presentViewController:animated:completion: method, or that has 
>> its definesPresentationContext property set to YES is returned as the value 
>> of the property. It keeps walking up the hierarchy until it finds a value to 
>> return or it gets to the root view controller.
>
>Oh, yeah? Watch this:
>
>self.definesPresentationContext = YES;
>self.parentViewController.definesPresentationContext = YES;
>NSLog(@"%i %i", self.definesPresentationContext, 
>self.parentViewController.definesPresentationContext);
>// 1 1
>NSLog(@"%@", self.presentingViewController);
>// null
>
>So both self and its parent do in fact have their definesPresentationContext 
>property set to YES, and yet neither is being returned as the value of the 
>property. I rest my case. Maybe the docs are talking here about some very 
>specific situation where what's claimed is correct, but then they should say 
>what that situation is. I've been looking for it all day and haven't found 
>it... 

Okay, I did eventually find the situation in which the docs are correct. It 
only took me two days to figure it out.

But it is up to the docs to state that situation! This really does carry the 
notion of coy and allusive (and wrong) to its limit. This is not at all the way 
docs should be.

However, at least my book will be more correct and helpful than the docs, so I 
suppose I shouldn't complain. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: NSString looses Umlaute

[Mike Abdullah]

On 22 Dec 2011, at 15:54, Alexander Reichstadt wrote:

> Thanks, but I  have not tried. My thinking went along the lines of if I read 
> the string directly from the URL I have no control over what encoding is 
> being used for reading or it defaults to something. If I first read as data, 
> I can do with those bytes as I please. The DBF file is not in one consistent 
> encoding from start to finish. The DBF file format documentation says the 
> header is in binary, then there is a linefeed (\r), then there is the body. 
> Each field has a fixed length, wether used or not doesn't matter, the unused 
> rest is filled with spaces.
> 
> So, I read the file as data, stringily it as DOSLatin1, split it at the 
> linefeed and read the body according to the field definitions I am given. 
> They are guaranteed, so maybe some day I get around to writing a nice DBF 
> parser, but until then I go by the guaranteed field lengths.

If your first step after reading the data is create a string from it, then you 
might as well use NSString directly. -[NSString 
initWithContentsOfURL:encoding:error:] does exactly what you are doing right 
now, and potentially more memory-efficiently.

That said, either of these may not be great since it's possible something in 
the binary header might cause NSString to fail. Instead you should really do:

1. Read the data into memory
2. Locate where the text begins
3. Split out a new data object containing just the text data
4. Create a string from that data___

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: Debugging hints

[Martin Hewitson]

On 22, Dec, 2011, at 03:32 PM, Mike Abdullah wrote:

> 
> On 22 Dec 2011, at 14:03, Martin Hewitson wrote:
> 
>> 
>> On 22, Dec, 2011, at 02:39 PM, Mike Abdullah wrote:
>> 
>>> Did you actually write this app to be dual-mode, or are you under the 
>>> impression that turning off garbage collection will magically fix things?
>> 
>> To be honest, I wrote the app assuming garbage collection was off. I think 
>> it must have got turned on by mistake, perhaps during the move to Xcode 4. 
>> Not sure.
>> 
>> I am under the impression (according to what others have written) that 
>> turning off garbage collection will stop the crashes in the garbage 
>> collection queue. I think this is a reported bug, but I didn't follow that 
>> thread very long. I just was surprised to find garbage collection on in the 
>> app, so I switched it off. This revealed the bug, which I'd like now to fix, 
>> of course.
> 
> I see. Well, turning it off will certainly fix that particular crash. But it 
> doesn't surprise me at all that an app which has had the safety net of GC for 
> a while will have picked up some memory management errors. The static 
> analyzer may well find a lot of them.
> 

Thanks for all your advice. A combination of the zombies instrument and the 
static analyzer helped me track down all the bugs that had crept in while 
operating with the safety net of garbage collection.

Martin


Martin Hewitson
Albert-Einstein-Institut
Max-Planck-Institut fuer 
Gravitationsphysik und Universitaet Hannover
Callinstr. 38, 30167 Hannover, Germany
Tel: +49-511-762-17121, Fax: +49-511-762-5861
E-Mail: martin.hewit...@aei.mpg.de
WWW: http://www.aei.mpg.de/~hewitson






___

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: No more warning about registered observers on dealloc with ARC?

[Matt Neuburg]

On Thu, 22 Dec 2011 21:13:07 +0800, Roland King  said:
>You used to get a handy message logged to the console when an object with KVO 
>registered on it was deallocated, but not in either of these two cases (and I 
>can quite clearly demonstrate that the object was dealloc'ed with dangling 
>KVO). Has that message been removed

No, I can easily generate it - all you have to do is register for KVO and let 
the object vanish at the end of the scope (which, under ARC, it will if it 
wasn't assigned to an ivar):

"An instance 0x6805020 of class MyClass1 was deallocated while key value 
observers were still registered with it. Observation info was leaked, and may 
even become mistakenly attached to some other object. Set a breakpoint on 
NSKVODeallocateBreak to stop here in the debugger. Here's the current 
observation info:"

So presumably something else is going on here; perhaps you haven't quite gotten 
to the root of your problem yet. m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: providesPresentationContextTransitionStyle busted?

[Matt Neuburg]

On Mon, 19 Dec 2011 10:39:26 -0800, Matt Neuburg  said:
>According to the docs:
>
>> @property(nonatomic, assign) BOOL providesPresentationContextTransitionStyle
>> Discussion
>> If the value of this property is YES and the value of the 
>> definesPresentationContext property is YES, then the modal transition style 
>> of the presenting view controller is used. Otherwise, the modal transition 
>> style of the presented view controller’s modal transition style is used.
>
>So I tried it and it doesn't work. I simply used Xcode's built-in Utility 
>Application template, which presents and dismisses a modal view right out of 
>the box:
>
>- (IBAction)showInfo:(id)sender
>{
>FlipsideViewController *controller = [[FlipsideViewController alloc] 
> initWithNibName:@"FlipsideViewController" bundle:nil];
>controller.delegate = self;
>controller.modalTransitionStyle = UIModalTransitionStyleFlipHorizontal;
>// here are my additions
>self.modalTransitionStyle = UIModalTransitionStyleCrossDissolve; // *
>self.providesPresentationContextTransitionStyle = YES; // *
>self.definesPresentationContext = YES; // *
>[self presentModalViewController:controller animated:YES];
>}
>
>The three marked lines are my only change to the template. I am doing exactly 
>what the docs say to do. But it isn't working, or rather it's working in a 
>very lame and partial way

I did eventually figure this out. The docs are wrong (because they don't tell 
the full story) plus there's a bug (the "lame and partial way" should be "does 
not work at all" but isn't). m.

--
matt neuburg, phd = m...@tidbits.com, 
A fool + a tool + an autorelease pool = cool!
Programming iOS 4!
http://www.apeth.net/matt/default.html#iosbook___

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: NSString looses Umlaute

[Alexander Reichstadt]

The header cannot be of a fixed length, as it contains the fields, their length 
and their types, which can vary. What it says there is:

n above is the last byte in the field descriptor array. The size of the array 
depends on the number of fields in the table file.

More on this here:




Am 22.12.2011 um 17:29 schrieb Ken Thomases:

> On Dec 22, 2011, at 9:54 AM, Alexander Reichstadt wrote:
> 
>> The DBF file format documentation says the header is in binary, then there 
>> is a linefeed (\r), then there is the body. Each field has a fixed length, 
>> wether used or not doesn't matter, the unused rest is filled with spaces.
>> 
>> So, I read the file as data, stringily it as DOSLatin1, split it at the 
>> linefeed and read the body according to the field definitions I am given. 
>> They are guaranteed, so maybe some day I get around to writing a nice DBF 
>> parser, but until then I go by the guaranteed field lengths.
>> 
>> I tested it now on a couple of files and it works without a hitch.
> 
> If the header is binary, then any of its bytes might be 0x0D, which is the 
> same as \r (or did you actually mean it when you said "linefeed" which is 
> 0x0A or \n?), so your approach will fail.  In all probability, the header is 
> a fixed length and you can just skip that part of the data.  Either way, if 
> this is meant for more than a casual, one-off, in-house app, you'll have to 
> find a more reliable technique.
> 
> 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: NSString looses Umlaute

[Alexander Reichstadt]

I should add, you are right in that it also says:

n+1, 1 byte, 0x0D stored as the Field Descriptor terminator.

Everything from byte 68 on is then a multiple of 48 bytes, so I can simply 
check on each 67+(n*48)+1 to see if that byte is 0x0D, which is the marker 
position of which to follow Mike's advise on getting the subdata.

Alex


Am 22.12.2011 um 17:29 schrieb Ken Thomases:

> On Dec 22, 2011, at 9:54 AM, Alexander Reichstadt wrote:
> 
>> The DBF file format documentation says the header is in binary, then there 
>> is a linefeed (\r), then there is the body. Each field has a fixed length, 
>> wether used or not doesn't matter, the unused rest is filled with spaces.
>> 
>> So, I read the file as data, stringily it as DOSLatin1, split it at the 
>> linefeed and read the body according to the field definitions I am given. 
>> They are guaranteed, so maybe some day I get around to writing a nice DBF 
>> parser, but until then I go by the guaranteed field lengths.
>> 
>> I tested it now on a couple of files and it works without a hitch.
> 
> If the header is binary, then any of its bytes might be 0x0D, which is the 
> same as \r (or did you actually mean it when you said "linefeed" which is 
> 0x0A or \n?), so your approach will fail.  In all probability, the header is 
> a fixed length and you can just skip that part of the data.  Either way, if 
> this is meant for more than a casual, one-off, in-house app, you'll have to 
> find a more reliable technique.
> 
> 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: presentingViewController docs patently false

[Kyle Sluder]

On Dec 22, 2011, at 8:59 AM, Matt Neuburg  wrote:

> Okay, I did eventually find the situation in which the docs are correct. It 
> only took me two days to figure it out.
> 
> But it is up to the docs to state that situation! This really does carry the 
> notion of coy and allusive (and wrong) to its limit. This is not at all the 
> way docs should be.

Then please file a bug! The documentation authors can't know about and document 
every bug in the implementation. Often times I believe they work from the 
specification in order to have the docs ready for release.

> However, at least my book will be more correct and helpful than the docs, so 
> I suppose I shouldn't complain. m.

While I wouldn't expect you to go into as much detail as you would in your 
book, would you mind elaborating a bit more on your findings? Many people are 
attempting to adopt UIStoryboard around now, and this is pertinent information.

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

NSDocument leak with top-of-NIB object controllers (10.6 ARC)

[Fritz Anderson]

Xcode 4.2, 10.7 SDK, target 10.6, ARC ("weak" pointers must be 
unsafe_unretained).

I had the following problem, which I solved, but I don't trust the solution:

When I used heapshotting to see what happened when I repeatedly opened and 
closed my document, I was accumulating a lot of memory as the document and its 
data were never released. All the retains and releases with my code in the 
stack trace were balanced.

The document's NIB (no, I don't put the document in the NIB, and I'm using the 
window controller that comes with the document) contains an NSObjectController 
and an NSArrayController at the top level. Per "Patterns for Managing Outlets 
Become Consistent Across Platforms" in the "Transitioning to ARC Release 
Notes," the IBOutlet properties for those controllers were declared strong.

But my residual retain count was 2, and a couple of the retains were in the 
NIB-loading mechanism, so I tried setting the outlets for those controllers to 
nil at -windowWillClose: time. 

This cured the leak. So did making the outlets unsafe_unretained (though that 
leaked slightly more).

I don't see that there should be _harm_ in this, but I worry, because it goes 
against the documentation (at least the documentation I could find). I've 
developed a theory, and I'd like to know if it's superstitious:

• For projects targeting 10.7 or later, and using ARC, the references should be 
strong, as documented. (But how does the OS know whether that class in 
particular is using ARC? Products can be mixed.)

• If the target is 10.6, even if running on 10.7, regardless of whether ARC is 
used, the references should be unsafe_unretained/assign, to match the behavior 
of the target operating system.

Do I have this right?

— 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: NSDocument leak with top-of-NIB object controllers (10.6 ARC)

[Kyle Sluder]

On Thu, Dec 22, 2011 at 11:29 AM, Fritz Anderson
 wrote:
> The document's NIB (no, I don't put the document in the NIB, and I'm using 
> the window controller that comes with the document) contains an 
> NSObjectController and an NSArrayController at the top level. Per "Patterns 
> for Managing Outlets Become Consistent Across Platforms" in the 
> "Transitioning to ARC Release Notes," the IBOutlet properties for those 
> controllers were declared strong.

This seems to conflict with the Resource Programming Guide, which
recommends that your IBOutlets be declared weak (aka 'assign') on Mac
OS X: 
http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW26

--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: Account validation in CocoaTouch for the purchased app

[John Joyce]

> 
>> given an app is sold on iTunes, is there a way for that app to find out 
>> which email address was used for the iTunes account when it was purchased?
> 
> I don't believe so. As far as I know, the only way to find that out is to ask 
> the user.
> 
Keep in mind that although an AppleID is required to be formatted like an email 
address, the actual email address associated could be very different.
The details of an AppleID account are probably not available to you, and 
certainly shouldn't be.
Also, you probably should not be trying to gather the user's AppleID 
information.
Every purchased app knows which AppleID it belongs to, but that is private to 
Apple and you cannot access that.


___

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: NSString looses Umlaute

[Steve Christensen]

And just to add in one more bit about why it's important to separate the text 
from the binary header, -initWithData:encoding: "[r]eturns nil if the 
initialization fails for some reason (for example if data does not represent 
valid data for encoding)." (That is from the NSString docs.)


On Dec 22, 2011, at 9:30 AM, Alexander Reichstadt wrote:

> I should add, you are right in that it also says:
> 
> n+1, 1 byte, 0x0D stored as the Field Descriptor terminator.
> 
> Everything from byte 68 on is then a multiple of 48 bytes, so I can simply 
> check on each 67+(n*48)+1 to see if that byte is 0x0D, which is the marker 
> position of which to follow Mike's advise on getting the subdata.
> 
> Alex
> 
> 
> Am 22.12.2011 um 17:29 schrieb Ken Thomases:
> 
>> On Dec 22, 2011, at 9:54 AM, Alexander Reichstadt wrote:
>> 
>>> The DBF file format documentation says the header is in binary, then there 
>>> is a linefeed (\r), then there is the body. Each field has a fixed length, 
>>> wether used or not doesn't matter, the unused rest is filled with spaces.
>>> 
>>> So, I read the file as data, stringily it as DOSLatin1, split it at the 
>>> linefeed and read the body according to the field definitions I am given. 
>>> They are guaranteed, so maybe some day I get around to writing a nice DBF 
>>> parser, but until then I go by the guaranteed field lengths.
>>> 
>>> I tested it now on a couple of files and it works without a hitch.
>> 
>> If the header is binary, then any of its bytes might be 0x0D, which is the 
>> same as \r (or did you actually mean it when you said "linefeed" which is 
>> 0x0A or \n?), so your approach will fail.  In all probability, the header is 
>> a fixed length and you can just skip that part of the data.  Either way, if 
>> this is meant for more than a casual, one-off, in-house app, you'll have to 
>> find a more reliable technique.
>> 
>> 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: NSString looses Umlaute

[zav]

I think we mean "loses".

"Loose" means not tight.

Sent from my Verizon Wireless BlackBerry

-Original Message-
From: Steve Christensen 
Sender: cocoa-dev-bounces+zav=mac@lists.apple.com
Date: Thu, 22 Dec 2011 13:06:32 
To: Alexander Reichstadt
Cc: Cocoa-Dev List
Subject: Re: NSString looses Umlaute

And just to add in one more bit about why it's important to separate the text 
from the binary header, -initWithData:encoding: "[r]eturns nil if the 
initialization fails for some reason (for example if data does not represent 
valid data for encoding)." (That is from the NSString docs.)


On Dec 22, 2011, at 9:30 AM, Alexander Reichstadt wrote:

> I should add, you are right in that it also says:
> 
> n+1, 1 byte, 0x0D stored as the Field Descriptor terminator.
> 
> Everything from byte 68 on is then a multiple of 48 bytes, so I can simply 
> check on each 67+(n*48)+1 to see if that byte is 0x0D, which is the marker 
> position of which to follow Mike's advise on getting the subdata.
> 
> Alex
> 
> 
> Am 22.12.2011 um 17:29 schrieb Ken Thomases:
> 
>> On Dec 22, 2011, at 9:54 AM, Alexander Reichstadt wrote:
>> 
>>> The DBF file format documentation says the header is in binary, then there 
>>> is a linefeed (\r), then there is the body. Each field has a fixed length, 
>>> wether used or not doesn't matter, the unused rest is filled with spaces.
>>> 
>>> So, I read the file as data, stringily it as DOSLatin1, split it at the 
>>> linefeed and read the body according to the field definitions I am given. 
>>> They are guaranteed, so maybe some day I get around to writing a nice DBF 
>>> parser, but until then I go by the guaranteed field lengths.
>>> 
>>> I tested it now on a couple of files and it works without a hitch.
>> 
>> If the header is binary, then any of its bytes might be 0x0D, which is the 
>> same as \r (or did you actually mean it when you said "linefeed" which is 
>> 0x0A or \n?), so your approach will fail.  In all probability, the header is 
>> a fixed length and you can just skip that part of the data.  Either way, if 
>> this is meant for more than a casual, one-off, in-house app, you'll have to 
>> find a more reliable technique.
>> 
>> 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/zav%40mac.com

This email sent to z...@mac.com
___

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

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

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

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

Re: NSDocument leak with top-of-NIB object controllers (10.6 ARC)

[Fritz Anderson]

On 22 Dec 2011, at 2:05 PM, Kyle Sluder wrote:

> On Thu, Dec 22, 2011 at 11:29 AM, Fritz Anderson
>  wrote:
>> The document's NIB (no, I don't put the document in the NIB, and I'm using 
>> the window controller that comes with the document) contains an 
>> NSObjectController and an NSArrayController at the top level. Per "Patterns 
>> for Managing Outlets Become Consistent Across Platforms" in the 
>> "Transitioning to ARC Release Notes," the IBOutlet properties for those 
>> controllers were declared strong.
> 
> This seems to conflict with the Resource Programming Guide, which
> recommends that your IBOutlets be declared weak (aka 'assign') on Mac
> OS X: 
> http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW26

I don't take your point. The "_become_ consistent" part of the title implies 
that the new recommendation, that outlets to top-level objects be strong, is 
_new_. 

On the page you refer to, I see:

"You typically need strong references to top-level objects to ensure that they 
are not deallocated…. From a practical perspective, in iOS and OS X outlets 
should be defined as declared properties. Outlets should generally be weak, 
_except for those from File’s Owner to top-level objects in a nib file … which 
should be strong_."

Emphasis added. The example given (twice) is:

@property (strong) IBOutlet MyOtherClass *topLevelObject;

"Outlets should be changed to strong when the outlet should be considered to 
own the referenced object:

• As indicated previously, this often the case with File’s Owner—top 
level objects in a nib file are frequently considered to be owned by the File’s 
Owner."

However, I do see the section on "_Legacy_ Patterns," which does recommend 
assign on Mac OS X, "_prior to ARC_." I am using ARC. On the other hand, I'm 
using it on a 10.6 target. 

ON STILL THE OTHER HAND, there is the section "Top-level Objects in OS X May 
Need Special Handling," which prescribes a horrific little ARC dance (HLAD, I'm 
trying to popularize it) you have to do in order to CFRelease top-level 
objects, because top-level objects come in with ownership +1. (But, but, but… I 
thought Mac OS NIB loading had been made consistent with iOS, like the ARC 
release note said?)

The more I go through of this, the more confused I become — and a year ago, I 
was pretty confident I knew this stuff.

None of this answers my question, which apparently I should have made clearer:


In a 10.6-targeted application (possibly running on 10.7), using ARC, do 
top-level objects follow the "ARC rule" (as in the release notes), or the 
"prior to ARC" rule (even though the code uses ARC)?


Maybe I have to have another look at that horrific little ARC dance. If that's 
necessary, then I was wrong to declare the object-controller outlets u_u, they 
should be strong, and I should then do the HLAD.

— 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: Account validation in CocoaTouch for the purchased app

[Gary L. Wade]

On Dec 22, 2011, at 12:46 PM, John Joyce  
wrote:

> ...an AppleID is required to be formatted like an email address...

No, it doesn't. I have an Apple ID with a space in it and no @ or host name 
portion. This may be a requirement for new Apple IDs, but it wasn't always that 
way nor is there any requirement that they be changed.
--
Gary L. Wade (Sent from my iPad)
http://www.garywade.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: Account validation in CocoaTouch for the purchased app

[John Joyce]

> 
>> ...an AppleID is required to be formatted like an email address...
> 
> No, it doesn't. I have an Apple ID with a space in it and no @ or host name 
> portion. This may be a requirement for new Apple IDs, but it wasn't always 
> that way nor is there any requirement that they be changed.
> --
> Gary L. Wade (Sent from my iPad)
> http://www.garywade.com/
You are correct, it used to be possible to create them that way, but all new 
ones require the email address format, hence the present tense used.

___

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: NSDocument leak with top-of-NIB object controllers (10.6 ARC)

[Fritz Anderson]

On 22 Dec 2011, at 4:02 PM, Fritz Anderson wrote:

> Maybe I have to have another look at that horrific little ARC dance. If 
> that's necessary, then I was wrong to declare the object-controller outlets 
> u_u, they should be strong, and I should then do the HLAD.

HLAD was harmful — passing the top-level objects to CFRelease() to relieve the 
"extra" retention resulted in an overrelease. So now what I'm doing is:

- Declare the property holding the top-level object strong.

- Manually nil-out the property at windowWillClose: time. If I don't do this, 
the objects' references back to the NSDocument (they are NSControllers bound to 
model objects through the document) will produce a retain loop so the document 
will never be dealloced.

This leads me to believe that a 10.6-targeted ARC application, running on 10.7, 
will _not_ see +1 retained top-level objects.

Which leads me once again to wonder what happens on 10.6. Do the NSControllers 
get overretained? If so, is there a way to detect the different loading 
behavior and do an extra release accordingly?

I'm beginning to sense ARC + Mac + NIBs + 10.6 is a corner case that wasn't 
fully thought out.

— 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: No more warning about registered observers on dealloc with ARC?

[Roland King]

On Dec 23, 2011, at 1:19 AM, Matt Neuburg wrote:

> On Thu, 22 Dec 2011 21:13:07 +0800, Roland King  said:
>> You used to get a handy message logged to the console when an object with 
>> KVO registered on it was deallocated, but not in either of these two cases 
>> (and I can quite clearly demonstrate that the object was dealloc'ed with 
>> dangling KVO). Has that message been removed
> 
> No, I can easily generate it - all you have to do is register for KVO and let 
> the object vanish at the end of the scope (which, under ARC, it will if it 
> wasn't assigned to an ivar):
> 
> "An instance 0x6805020 of class MyClass1 was deallocated while key value 
> observers were still registered with it. Observation info was leaked, and may 
> even become mistakenly attached to some other object. Set a breakpoint on 
> NSKVODeallocateBreak to stop here in the debugger. Here's the current 
> observation info:"
> 
> So presumably something else is going on here; perhaps you haven't quite 
> gotten to the root of your problem yet. m.
> 

I had, but my memory of the message was flawed. If you have objects A and B, 
and A observes a property of B and you dealloc B, you get the message, as you 
showed. In my case A was observing B and A was dealloc()ed without me removing 
the observation first. Eventually the observed property on B changed and it 
tried to send a KVO notification to a dead object. Once you posted the text of 
the message again it was obvious I had the reverse situation. 

___

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: No more warning about registered observers on dealloc with ARC?

[Matt Neuburg]

On Dec 22, 2011, at 3:58 PM, Roland King wrote:

> 
> On Dec 23, 2011, at 1:19 AM, Matt Neuburg wrote:
> 
>> On Thu, 22 Dec 2011 21:13:07 +0800, Roland King  said:
>>> You used to get a handy message logged to the console when an object with 
>>> KVO registered on it was deallocated, but not in either of these two cases 
>>> (and I can quite clearly demonstrate that the object was dealloc'ed with 
>>> dangling KVO). Has that message been removed
>> 
>> No, I can easily generate it - all you have to do is register for KVO and 
>> let the object vanish at the end of the scope (which, under ARC, it will if 
>> it wasn't assigned to an ivar):
>> 
>> "An instance 0x6805020 of class MyClass1 was deallocated while key value 
>> observers were still registered with it. Observation info was leaked, and 
>> may even become mistakenly attached to some other object. Set a breakpoint 
>> on NSKVODeallocateBreak to stop here in the debugger. Here's the current 
>> observation info:"
>> 
>> So presumably something else is going on here; perhaps you haven't quite 
>> gotten to the root of your problem yet. m.
>> 
> 
> I had, but my memory of the message was flawed. If you have objects A and B, 
> and A observes a property of B and you dealloc B, you get the message, as you 
> showed. In my case A was observing B and A was dealloc()ed without me 
> removing the observation first. Eventually the observed property on B changed 
> and it tried to send a KVO notification to a dead object. Once you posted the 
> text of the message again it was obvious I had the reverse situation. 

Excellent - thanks for drawing that distinction. m.

--
matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/
pantes anthropoi tou eidenai oregontai phusei
Among the 2007 MacTech Top 25, http://tinyurl.com/2rh4pf
Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook
RubyFrontier! http://www.apeth.com/RubyFrontierDocs/default.html
TidBITS, Mac news and reviews since 1990, http://www.tidbits.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: How to get the phone number use ios sdk in iphone.

[吴明]

Thanks
I will use the UUID or DeviceID instead of the phone number.
___

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

iOS on-disk file encryption questions

[Jens Alfke]

There’s a brief description in the iOS docs of "Protecting Data Using On-Disk 
Encryption”. Unfortunately there’s no description of how the file encryption 
actually happens, so I’m unsure whether it’s suitable for use with database 
files that can grow large, are updated incrementally, and are accessed using 
low-level read/write calls instead of Cocoa APIs.

Basically there are two ways I can think of this being implemented:
(1) Encrypt individual blocks of the file as they’re written/read, and do the 
encryption at the filesystem level, beneath the read/write system calls.
or
(2) Decrypt the entire file into RAM when it’s opened, and write it back 
encrypted when it’s closed.

Approach (1) will work great with things like sqlite or CouchDB. Approach (2) 
definitely won’t.

Anyone know for sure, or have experience using this feature with structured 
files?

Also, anyone know what the name of the underlying extended attribute is, so I 
can set it from C code?

—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: How to get the phone number use ios sdk in iphone.

[Dave DeLong]

FYI, the DeviceID was deprecated in iOS 5. 

Dave

Sent from Jane

On Dec 22, 2011, at 4:50 PM, 吴明  wrote:

> Thanks
> I will use the UUID or DeviceID instead of the phone number.
> ___
> 
> 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/davedelong%40me.com
> 
> This email sent to davedel...@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: How to get the phone number use ios sdk in iphone.

[Conrad Shultz]

On 12/22/11 4:50 PM, 吴明 wrote:
> Thanks
> I will use the UUID or DeviceID instead of the phone number.

The device ID (UIDevice's -uniqueIdentifier) is deprecated in iOS 5.
Don't use it.  (As you can probably gather, Apple is rightfully keen on
preventing developers from trying to track users in non-anonymized ways.)

CFUUID is fine, but keep in mind that if you are storing it in
NSUserDefaults then this presumably is not actually device-specific but
app-specific, in the sense that a backup-and-restore ought to preserve
the NSUserDefaults database across devices (say, if the user upgrades
from an older iPhone to a newer one).

Now, you haven't said *why* you are doing all this.  I can't think of a
good reason why you would need a true device identifier in your
application, so hopefully the above caveat won't affect you.

If you would like, perhaps you can elaborate on your goal?

-- 
Conrad Shultz

Synthetiq Solutions
www.synthetiqsolutions.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: How to get the phone number use ios sdk in iphone.

[吴明]

I dont found about this in iOS5.0 Api diffs and what's new in ios5.0
>FYI, the DeviceID was deprecated in iOS 5. 
>
>Dave
>

___

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 get the phone number use ios sdk in iphone.

[Dave DeLong]

http://developer.apple.com/library/IOs/documentation/UIKit/Reference/UIDevice_Class/DeprecationAppendix/AppendixADeprecatedAPI.html#//apple_ref/doc/uid/TP40006902-AppendixA-DontLinkElementID_47

Cheers,

Dave

On Dec 22, 2011, at 6:08 PM, 吴明 wrote:

> I dont found about this in iOS5.0 Api diffs and what's new in ios5.0
> >FYI, the DeviceID was deprecated in iOS 5. 
> >
> >Dave
> >
> 
> 
> 

___

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 get the phone number use ios sdk in iphone.

[John Joyce]

>> Thanks
>> I will use the UUID or DeviceID instead of the phone number.
> 
> The device ID (UIDevice's -uniqueIdentifier) is deprecated in iOS 5.
> Don't use it.  (As you can probably gather, Apple is rightfully keen on
> preventing developers from trying to track users in non-anonymized ways.)
> 
> CFUUID is fine, but keep in mind that if you are storing it in
> NSUserDefaults then this presumably is not actually device-specific but
> app-specific, in the sense that a backup-and-restore ought to preserve
> the NSUserDefaults database across devices (say, if the user upgrades
> from an older iPhone to a newer one).
> 
> Now, you haven't said *why* you are doing all this.  I can't think of a
> good reason why you would need a true device identifier in your
> application, so hopefully the above caveat won't affect you.
> 
> If you would like, perhaps you can elaborate on your goal?
> 
We should keep in mind that this could be an enterprise app that would not 
necessarily be for sale on the App Store.
Enterprises can distribute iOS apps (along with a Profile) independently of the 
App Store.
(OS X server is one method.)
So, perhaps, some asset tracking 
system?___

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 get the phone number use ios sdk in iphone.

[Conrad Shultz]

Point well taken. I do often sometimes forget about the enterprise side of 
things. 

(Sent from my iPad.)

--
Conrad Shultz

On Dec 22, 2011, at 19:23, John Joyce  
wrote:

>>> Thanks
>>> I will use the UUID or DeviceID instead of the phone number.
>> 
>> The device ID (UIDevice's -uniqueIdentifier) is deprecated in iOS 5.
>> Don't use it.  (As you can probably gather, Apple is rightfully keen on
>> preventing developers from trying to track users in non-anonymized ways.)
>> 
>> CFUUID is fine, but keep in mind that if you are storing it in
>> NSUserDefaults then this presumably is not actually device-specific but
>> app-specific, in the sense that a backup-and-restore ought to preserve
>> the NSUserDefaults database across devices (say, if the user upgrades
>> from an older iPhone to a newer one).
>> 
>> Now, you haven't said *why* you are doing all this.  I can't think of a
>> good reason why you would need a true device identifier in your
>> application, so hopefully the above caveat won't affect you.
>> 
>> If you would like, perhaps you can elaborate on your goal?
>> 
> We should keep in mind that this could be an enterprise app that would not 
> necessarily be for sale on the App Store.
> Enterprises can distribute iOS apps (along with a Profile) independently of 
> the App Store.
> (OS X server is one method.)
> So, perhaps, some asset tracking system?
___

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: NSString looses Umlaute

[Charles Srstka]

On Dec 22, 2011, at 11:30 AM, Alexander Reichstadt wrote:

> I should add, you are right in that it also says:
> 
> n+1, 1 byte, 0x0D stored as the Field Descriptor terminator.
> 
> Everything from byte 68 on is then a multiple of 48 bytes, so I can simply 
> check on each 67+(n*48)+1 to see if that byte is 0x0D, which is the marker 
> position of which to follow Mike's advise on getting the subdata.

So parse the fields in the header that tell you how long it’s supposed to be, 
and read the data where the actual string is supposed to start. It’ll probably 
actually take less time overall than trying to come up with all these 
workarounds.

If you’re going to do something, might as well do it right.

Charles___

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: NSString looses Umlaute

[Graham Cox]

I second this. I had to write code to parse a DBF file as part of a suite to 
handle "shapefiles" (GIS) and it was really not a huge effort. These formats 
are designed to be pretty straightforward to parse.


--Graham



On 23/12/2011, at 3:04 PM, Charles Srstka wrote:

> On Dec 22, 2011, at 11:30 AM, Alexander Reichstadt wrote:
> 
>> I should add, you are right in that it also says:
>> 
>> n+1, 1 byte, 0x0D stored as the Field Descriptor terminator.
>> 
>> Everything from byte 68 on is then a multiple of 48 bytes, so I can simply 
>> check on each 67+(n*48)+1 to see if that byte is 0x0D, which is the marker 
>> position of which to follow Mike's advise on getting the subdata.
> 
> So parse the fields in the header that tell you how long it’s supposed to be, 
> and read the data where the actual string is supposed to start. It’ll 
> probably actually take less time overall than trying to come up with all 
> these workarounds.
> 
> If you’re going to do something, might as well do it right.

___

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: Lion: Batch close

[Appa Rao Mulpuri]

I tried Instruments and it is showing the following crash log:

1   libobjc.A.dylib 0x7fff952f5d5e objc_exception_throw 
+ 43
2   CoreFoundation  0x7fff9697e4c9 -[NSException raise] 
+ 9
3   ExceptionHandling   0x000100325e0a 
NSExceptionHandlerUncaughtSignalHandler + 37
4   libsystem_c.dylib   0x7fff8ba12cfa _sigtramp + 26
5   ??? 0x 0x0 + 0
6   CoreFoundation  0x7fff968e0f48 
_CF_forwarding_prep_0 + 232
7   AppKit  0x7fff9488dcfe __-[NSWindow 
_close]_block_invoke_1 + 261
8   AppKit  0x7fff9488dbd7 -[NSWindow _close] + 
363
9   AppKit  0x7fff94ca6e5c -[NSWindow __close] 
+ 287
10  AppKit  0x7fff94ca6b6e -[NSWindow 
_batchClose] + 65
11  CoreFoundation  0x7fff968eb2e1 -[NSObject 
performSelector:] + 49
12  AppKit  0x7fff94611ed5 -[NSApplication 
makeWindowsPerform:inOrder:] + 217
13  AppKit  0x7fff948c4edf -[NSApplication 
_makeWindowsPerform:forEvent:inWindow:standardWindowButton:] + 29
14  AppKit  0x7fff94ca6d1b -[NSWindow _close:] 
+ 129
15  CoreFoundation  0x7fff968e3a1d -[NSObject 
performSelector:withObject:] + 61
16  AppKit  0x7fff94719710 -[NSApplication 
sendAction:to:from:] + 139
17  AppKit  0x7fff94719642 -[NSControl 
sendAction:to:] + 88
18  AppKit  0x7fff9471956d -[NSCell 
_sendActionFrom:] + 137
19  AppKit  0x7fff94718a30 -[NSCell 
trackMouse:inRect:ofView:untilMouseUp:] + 2014
20  AppKit  0x7fff947988e0 -[NSButtonCell 
trackMouse:inRect:ofView:untilMouseUp:] + 489
21  AppKit  0x7fff9471763a -[NSControl 
mouseDown:] + 786
22  AppKit  0x7fff94c452ae -[_NSThemeWidget 
mouseDown:] + 265
23  AppKit  0x7fff946e20e0 -[NSWindow 
sendEvent:] + 6306
24  AppKit  0x7fff9467a68f -[NSApplication 
sendEvent:] + 5593
25  MyApp  0x0001744b -[MYApplication 
sendEvent:] + 126
26  AppKit  0x7fff94610682 -[NSApplication run] 
+ 555
27  AppKit  0x7fff9488f80c NSApplicationMain + 
867
28  MyApp  0x00011c9f main + 33
29  MyApp  0x00011c5c start + 52


From: Apparao M mailto:appar...@ivycomptech.com>>
Date: Wed, 21 Dec 2011 11:28:50 +0530
To: "cocoa-dev@lists.apple.com" 
mailto:cocoa-dev@lists.apple.com>>
Subject: Lion: Batch close

Hi,

My application is crashing on Lion if user tries to close all open windows 
using Option key + Mouse click. Same is working in Leopard and Snow leopard. Is 
anything is changed related to Batch Close in Lion? Any work around for  this?

- Apparao
This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. Any views or opinions are solely those of the 
sender. This communication is not intended to form a binding contract unless 
expressly indicated to the contrary and properly authorised. Any actions taken 
on the basis of this email are at the recipient's own risk.


This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy 
Comptech Private Limited is a limited liability company.

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system.
Any views or opinions are solely those of the sender.  This communication is 
not intended to form a binding contract on behalf of Ivy Comptech Private 
Limited unless expressly indicated to the contrary and properly authorised. Any 
actions taken on the basis of this email are at the recipient's own risk.

Registered office:
Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, 
Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered 
in India. A list of members' names is available for inspection at the 
registered office.

___

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

Please do not post ad

Re: Lion: Batch close

[Ken Thomases]

On Dec 22, 2011, at 11:52 PM, Appa Rao Mulpuri wrote:

> I tried Instruments and it is showing the following crash log:
> 
> 1   libobjc.A.dylib 0x7fff952f5d5e 
> objc_exception_throw + 43
> 2   CoreFoundation  0x7fff9697e4c9 -[NSException 
> raise] + 9
> 3   ExceptionHandling   0x000100325e0a 
> NSExceptionHandlerUncaughtSignalHandler + 37
> ...


And what was the exception / signal?  It should have been logged to the console 
for any crashes.  It would also typically be included in crash reports.

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: Lion: Batch close

[Appa Rao Mulpuri]

Name: NSUncaughtSystemExceptionException
Reason: Uncaught system exception: signal 5



On 23/12/11 11:50 AM, "Ken Thomases"  wrote:

>On Dec 22, 2011, at 11:52 PM, Appa Rao Mulpuri wrote:
>
>> I tried Instruments and it is showing the following crash log:
>>
>> 1   libobjc.A.dylib 0x7fff952f5d5e
>>objc_exception_throw + 43
>> 2   CoreFoundation  0x7fff9697e4c9
>>-[NSException raise] + 9
>> 3   ExceptionHandling   0x000100325e0a
>>NSExceptionHandlerUncaughtSignalHandler + 37
>> ...
>
>
>And what was the exception / signal?  It should have been logged to the
>console for any crashes.  It would also typically be included in crash
>reports.
>
>Regards,
>Ken
>

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system. Any views or opinions are solely those of the 
sender. This communication is not intended to form a binding contract unless 
expressly indicated to the contrary and properly authorised. Any actions taken 
on the basis of this email are at the recipient's own risk.


This email is sent for and on behalf of Ivy Comptech Private Limited. Ivy 
Comptech Private Limited is a limited liability company.

This email and any attachments are confidential, and may be legally privileged 
and protected by copyright. If you are not the intended recipient dissemination 
or copying of this email is prohibited. If you have received this in error, 
please notify the sender by replying by email and then delete the email 
completely from your system.
Any views or opinions are solely those of the sender.  This communication is 
not intended to form a binding contract on behalf of Ivy Comptech Private 
Limited unless expressly indicated to the contrary and properly authorised. Any 
actions taken on the basis of this email are at the recipient's own risk.

Registered office:
Ivy Comptech Private Limited, Cyber Spazio, Road No. 2, Banjara Hills, 
Hyderabad 500 033, Andhra Pradesh, India. Registered number: 37994. Registered 
in India. A list of members' names is available for inspection at the 
registered office.

___

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