Re: making a pronunciation dictionary for Voiceover on the iphone

[Alex Hall]

You might consider displaying things "normally" on the screen, but adjusting an 
accessibility property like Description. In there, replace the odd strings with 
text that VO will read normally. Visually, it'll look normal, and audibly/in 
braille, it'll read normally. That's all I can think of.
> On Jan 4, 2016, at 16:20, Scott Berry  wrote:
> 
> Hello there,
> 
> I have certain identifiers which must be read correctly in my program.  In 
> Voiceover, they don’t read correctly so I’d like to make a dictionary which 
> Voiceover actually uses during the run of my program.  Is this something that 
> is supported or is this something I’ll need to make a enhancement request for?
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/mehgcap%40icloud.com
> 
> This email sent to mehg...@icloud.com


--
Have a great day,
Alex Hall
mehg...@icloud.com


___

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

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

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

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

Re: Only assign value to variable if not nil.

[Alex Zavatone]

Bingo.  Ternary operators.

Thanks all.  

On Jan 6, 2016, at 5:45 PM, Alex Zavatone wrote:

> Hi all.  I was just extending some of my configuration file support on iOS to 
> add move from one config file to one master and then a product specific one.
> 
> So, in the master, i'll have the full set of changeable properties defined in 
> a pList and after reading this into a dictionary, I'll assign them to the 
> various properties one at a time.
> 
> Of course, the product specific config file will supply any values we'd wish 
> to overwrite, but not the whole set of options that are in the master.
> 
> In this, I'm currently assigning the property value based on the result 
> returned from calling objectForKey: on the config dictionary.
> 
> Without resorting to if/then/elsing the code to death, is there a way to 
> accomplish assigning a value to a variable only if the value is not nil?
> 
> Or am I thinking about this issue all bass ackwards.
> 
> Yeah, I could use placeholders before assigning, but I'm figuring there's 
> something I could learn here and one of you just might know what that is.
> 
> Cheers,
> Alex Zavatone
> 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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

Re: More Xcode 7 inconsistency?

[Shane Stanley]

On 14 Oct 2015, at 2:27 PM, Shane Stanley  wrote:

> On 14 Oct 2015, at 1:33 PM, Graham Cox  wrote:
>> 
>> I’ve been passing nil forever, only now does Xcode 7 complain, presumably 
>> because only now is the _Nonnull attribute added. But either the 
>> documentation or the addition of _Nonnull is wrong.
> 
> FWIW, I've had an open bug on this since July (#21667200). You might also 
> notice the docs say "dict can be nil", and there isn't a "dict" to be seen 
> (presumably it means docAttributes).

Coming back to this, my bug has just been closed, with a pointer to:



And sure enough, where it once said:

- (NSData * nullable)RTFFromRange:(NSRange)aRange
  documentAttributes:(NSDictionary * nonnull)docAttributes

it now says:

- (NSData *)RTFFromRange:(NSRange)aRange
  documentAttributes:(NSDictionary *)docAttributes


The description is unchanged:

> If there are no document-level attributes, dict can be nil.

Great.

However, when I look at the .h file, it's all wrapped in 
NS_ASSUME_NONNULL_BEGIN, and using the method with nil prompts exactly the same 
warning. So the contradiction between the documentation and actual behavior 
still stands, just not so obviously.

All of which led me to also look at this in the same document:

- (instancetype)initWithRTFD:(NSData *)rtfdData
  documentAttributes:(NSDictionary * _Nullable *)docAttributes


for which the .h file (Xcode 7.2) actually says:

- (nullable instancetype)initWithRTF:(NSData *)data 
documentAttributes:(NSDictionary * __nullable * __nullable)dict;

Am I just being a pedant or is this all a bit hopeless?


-- 
Shane Stanley 



___

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

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

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

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

Re: More Xcode 7 inconsistency?

[dangerwillrobinsondanger]

At runtime all bets are off anyway. 
Nullability is a compile time constraint for Objective-C and a helper for Swift 
overlays. 
You can still pass an object in runtime in Objective-C. 
It's up to the receiver to handle it. 



Sent from my iPhone

> On Jan 7, 2016, at 1:32 PM, Shane Stanley  wrote:
> 
>> On 14 Oct 2015, at 2:27 PM, Shane Stanley  wrote:
>> 
>>> On 14 Oct 2015, at 1:33 PM, Graham Cox  wrote:
>>> 
>>> I’ve been passing nil forever, only now does Xcode 7 complain, presumably 
>>> because only now is the _Nonnull attribute added. But either the 
>>> documentation or the addition of _Nonnull is wrong.
>> 
>> FWIW, I've had an open bug on this since July (#21667200). You might also 
>> notice the docs say "dict can be nil", and there isn't a "dict" to be seen 
>> (presumably it means docAttributes).
> 
> Coming back to this, my bug has just been closed, with a pointer to:
> 
> 
> 
> And sure enough, where it once said:
> 
> - (NSData * nullable)RTFFromRange:(NSRange)aRange
>  documentAttributes:(NSDictionary  id> * nonnull)docAttributes
> 
> it now says:
> 
> - (NSData *)RTFFromRange:(NSRange)aRange
>  documentAttributes:(NSDictionary  id> *)docAttributes
> 
> 
> The description is unchanged:
> 
>> If there are no document-level attributes, dict can be nil.
> 
> Great.
> 
> However, when I look at the .h file, it's all wrapped in 
> NS_ASSUME_NONNULL_BEGIN, and using the method with nil prompts exactly the 
> same warning. So the contradiction between the documentation and actual 
> behavior still stands, just not so obviously.
> 
> All of which led me to also look at this in the same document:
> 
> - (instancetype)initWithRTFD:(NSData *)rtfdData
>  documentAttributes:(NSDictionary  id> * _Nullable *)docAttributes
> 
> 
> for which the .h file (Xcode 7.2) actually says:
> 
> - (nullable instancetype)initWithRTF:(NSData *)data 
> documentAttributes:(NSDictionary * __nullable * 
> __nullable)dict;
> 
> Am I just being a pedant or is this all a bit hopeless?
> 
> 
> -- 
> Shane Stanley 
> 
> 
> 
> ___
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.com

___

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

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

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

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

Only assign value to variable if not nil.

[Alex Zavatone]

Hi all.  I was just extending some of my configuration file support on iOS to 
add move from one config file to one master and then a product specific one.

So, in the master, i'll have the full set of changeable properties defined in a 
pList and after reading this into a dictionary, I'll assign them to the various 
properties one at a time.

Of course, the product specific config file will supply any values we'd wish to 
overwrite, but not the whole set of options that are in the master.

In this, I'm currently assigning the property value based on the result 
returned from calling objectForKey: on the config dictionary.

Without resorting to if/then/elsing the code to death, is there a way to 
accomplish assigning a value to a variable only if the value is not nil?

Or am I thinking about this issue all bass ackwards.

Yeah, I could use placeholders before assigning, but I'm figuring there's 
something I could learn here and one of you just might know what that is.

Cheers,
Alex Zavatone




___

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

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

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

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