Re: Weird NSTextField behavior on MBA.

2011-11-22 Thread Gustavo Pizano 
Hello Richard thanks for the reply.


I will make some debugging on my friend MBA and see if something's wrong in the 
code, if not, then I guess I will be filling up a Bug report, because this 
issue makes no sense to me.



Gustavo

On Nov 22, 2011, at 7:18 AM, Richard Somers wrote:

> On Nov 21, 2011, at 3:08 PM, Gustavo Pizano wrote:
> 
>> So im wondering what its going on because I have tried the behavior on 2 
>> iMacs, 2 MPB and 2 MBA, on the latest one is the only one that doesn't 
>> behave as expected.  What can it be?
> 
> Perhaps it is a graphics card issue. One way to check out the hardware 
> differences between various Macs is with Mactracker.
> 
> http://mactracker.ca/
> 
> --Richard
> 

___

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: Weird NSTextField behavior on MBA.

2011-11-22 Thread Richard Somers 
On Nov 22, 2011, at 1:59 AM, Gustavo Pizano wrote:

> I will make some debugging on my friend MBA and see if something's wrong in 
> the code, if not, then I guess I will be filling up a Bug report, because 
> this issue makes no sense to me.

Is this done completely in Interface Builder or in code. If in code perhaps you 
should post your code.

--Richard

___

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: Weird NSTextField behavior on MBA.

2011-11-22 Thread James Walker 

On 11/21/2011 2:08 PM, Gustavo Pizano wrote:


So im wondering what its going on because I have tried the behavior on 2 iMacs, 
2 MPB and 2 MBA, on the latest one is the only one that doesn't behave as 
expected.  What can it be?


Did you compare the OS versions?


--
  James W. Walker, Innoventive Software LLC
  
___

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

NSSliderCell hiding bar.

2011-11-22 Thread Mr. Gecko 
Hello. I am needing to write a custom NSSlider and apparently, overriding 
drawBarInside:flipped: does not prevent NSSliderCell from drawing the bar. Is 
there a way to hide the bar? Would I have to write a custom 
NSSlider?___

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: NSDateFormatter not working on iOS 5.

2011-11-22 Thread Matt Neuburg 
On Sun, 20 Nov 2011 23:54:45 -0800, Peter Edberg  said:
>
>On Nov 17, 2011, at 10:14 AM, Matt Neuburg wrote:
>
>> On Wed, 16 Nov 2011 14:43:55 -0800, Peter Edberg  said:
>>> ...
>>> 
>>> The issue is this: With the *short* timezone formats as specified by z 
>>> (=zzz) or v (=vvv), there can be a lot of ambiguity. For example, "ET" for 
>>> Eastern Time" could apply to different time zones in many different 
>>> regions. To improve formatting and parsing reliability, the short forms are 
>>> only used in a locale if the "cu" (commonly used) flag is set for the 
>>> locale. Otherwise, only the long forms are used (for both formatting and 
>>> parsing).
>>> 
>>> For the "en" locale (= "en_US"), the cu flag is set for metazones such as 
>>> Alaska, America_Central, America_Eastern, America_Mountain, 
>>> America_Pacific, Atlantic, Hawaii_Aleutian, and GMT. It is *not* set for 
>>> Europe_Central.
>>> 
>>> However, for the "en_GB" locale, the cu flag *is* set for Europe_Central.
>>> 
>>> So a formatter set for short timezone style "z" or "zzz" and locale "en" or 
>>> "en_US" will not parse "CEST" or "CET", but if the locale is instead set to 
>>> "en_GB" it *will* parse those. The "GMT" style will be parsed by all.
>>> 
>>> ...
>> 
>> Thanks; I suspected that something like this might be the case. But the 
>> result, as I pointed out in my bug report (10447767), is that you can't 
>> round-trip the abbreviations that the system itself gives you:
>> 
>>NSDictionary* d = (NSDictionary*)CFTimeZoneCopyAbbreviationDictionary();
>>for (NSString* aZone in d.keyEnumerator)
>>NSLog(@"%@ %@", aZone, [dateFormatter dateFromString:
>>   [NSString stringWithFormat:@"2011-11-15 06:50:59.735 %@", aZone]]);
>> 
>> These are *your* abbreviations (by "you" I mean the system) that aren't 
>> working. If they aren't going to work why are you giving them to me? Surely 
>> there should be some call that provides me with a list of *legal* 
>> abbreviations. m.
>
>
>
>Yes, there is a disconnect here. The dictionary returned by 
>CFTimeZoneCopyAbbreviationDictionary (and by +[NSTImeZone 
>abbreviationDictionary]) is a standard internal mapping that does not depend 
>on locale and is not built from the abbreviations used by ICU, and always maps 
>ambiguous zone abbreviations to a particular zone name (as noted in the 
>documentation) regardless of locale. This is not particularly useful for your 
>purposes.
>
>What would be more useful in this case is function that takes a locale 
>parameter, and returns a dictionary of the abbreviation mappings that are 
>meaningful in that locale. This would be built from the locale-specific 
>abbreviations used by ICU. If you agree, please file an enhancement request.

Thanks, Peter - I've added that suggestion to my original bug report (problem 
ID 10447767). I used your name too. :) 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