• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Assuring KVO compliance.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Assuring KVO compliance.


  • Subject: Re: Assuring KVO compliance.
  • From: Roland King <email@hidden>
  • Date: Tue, 07 Apr 2015 23:32:25 +0800

> On 7 Apr 2015, at 23:12, Alex Zavatone <email@hidden> wrote:
>
> To answer my own question, changing the enum to an NSInteger backed NS_Enum resulted in no more bad access exceptions from other chunks of code attempting to change the APP_State property.
>
> typedef NS_ENUM(NSInteger, APP_State) {
>    APP_State_Normal = 0,
>    APP_State_Expired = 1,
>    APP_State_Waiting = 2
> };
>
> Changing the atomicity of the exposed property had no effect on whether the exception was issued or not.
>
> Hope this helps someone.
>
> Alex Zavatone
>

I was just looking at some of my own code because I’m pretty sure I use enums all the time in properties which are KVO and observe them and update them, and I’ve never once had to mess around with NS_ENUM to make them work.

And indeed I found 4 examples quite quickly, all of which look very much like your original code, a typedef’ed enum used as a property.

So I really don’t know where your bad accesses were coming from.

This was all ObjC right ?

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden


  • Follow-Ups:
    • Re: Assuring KVO compliance.
      • From: Alex Zavatone <email@hidden>
References: 
 >Assuring KVO compliance. (From: Alex Zavatone <email@hidden>)
 >Re: Assuring KVO compliance. (From: Alex Zavatone <email@hidden>)

  • Prev by Date: Re: Assuring KVO compliance.
  • Next by Date: Re: Assuring KVO compliance.
  • Previous by thread: Re: Assuring KVO compliance.
  • Next by thread: Re: Assuring KVO compliance.
  • Index(es):
    • Date
    • Thread