Re: What is overwriting 'isa' with 0xbaddc0dedeadbead ?
> On May 22, 2015, at 8:42 PM, Jens Alfke wrote: > > 0xbaddc0dedeadbead Check Google, or duckduckgo? It seems to come up in a variety of crashes. I’m not sure that I could pick Swift out of them, but they pretty exclusively seem to be Yosemite. > This is obviously a magic value that someone put there to indicate the > pointer isn’t valid, but I’ve never seen that particular value before. I’m > guessing that it’s something to do with the Swift runtime. It does seem to sort of have the old Apple thing of using hex to make words that are used as magic. But not completely consistently. You would think you could be even more creative these days with 64 bit addresses to work with. I tried to narrow my search to Apple sites to see if I could find it mentioned in doc somewhere but came up empty. Michael Hall ___ 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: Disabling auto-synthesis of property accessors.
On 22 May 2015, at 14:49, Alex Zavatone wrote: > Thanks for the wake up call, UIi! I’m sorry. I’d much rather get you the news that you can sleep in :-) Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
What is overwriting 'isa' with 0xbaddc0dedeadbead ?
I’m trying to debug a mysterious crash in a Swift init method. At the end of the method there are some calls to objc_release generated by the compiler, and it’s the first of these that crashes: the object being released has has its ‘isa’ pointer replaced by the value 0xbaddc0dedeadbead. This is obviously a magic value that someone put there to indicate the pointer isn’t valid, but I’ve never seen that particular value before. I’m guessing that it’s something to do with the Swift runtime. I’ve turned on NSZombieEnabled but it doesn’t make a difference. And the object address doesn’t correspond to any parameter of the init method, nor is it the receiver (the class inherits from NSObject.) The crash is also not consistent; sometimes it doesn’t happen. I’m drawing a blank. Does anyone know what this means? (Oh, and this is in a 64-bit Mac OS X process. It’s a small all-Swift app I just started writing this week, which used to work until an hour ago, so I don’t think there’s any mysterious memory corruption involved.) —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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> On 22 May 2015, at 9:51 pm, Jonathan Taylor > wrote: > > I’m trying to think if there is an elegant way of handling the situation I > find in some of my display code. I have a class which inherits from NSView > and which overrides drawRect. The class has a number of properties, and if > they change then the view needs redrawing. At present I have custom setters > that call through to setNeedsDisplay:YES. This results in quite a lot of code > bloat (since I would otherwise just @synthesize the properties and be done > with it). My advice is: forget it. What you’re doing is fine, and it’s the normal way to make views repaint when a property changes. It’s not code ‘bloat’ either - @synthesize produces code just as if you’d written it yourself. Any other way than simply adding a call to -setNeedsDisplay: is MORE code than that. View properties can’t be usefully atomic either, so that isn’t going to matter. Really, you are trying to save yourself a tiny bit of extra work by making things far more complicated than necessary. Remember, it wasn’t very long ago that all properties had to be implemented by hand. How we used to spend many a happy hour writing endless getters and setters! What would be quite nice (though maybe too much of a special case and very unlikely to happen) is a qualifier for properties that would add the -setNeedsDisplay: automatically as part of the @synthesize, but I doubt that will ever happen because it a) only pertains to views b) might not be optimal for some situations, where only part of the view needs updating, and c) made somewhat redundant by layers, which have a flag that causes a redisplay on a property change. —Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> On 22 May 2015, at 15:03, Jonathan Taylor > wrote: > > Thanks for your reply Mike: > >> Well you could have a single key which you observe internally, and which all >> the other keys feed into. Whenever it “changes”, treat that as time to mark >> as needing display. That way you’re asking AppKit to do the work of creating >> all the other observations for you. > > I think this is what I was describing here, isn’t it (or am I > misunderstanding you?): >>> I could create a single “dummy” property of my own, say that changes to all >>> these other properties affect that key, and then monitor that single key >>> using KVO (and call setNeedsDisplay whenever it gets “tickled” by some >>> other property change). That would do what I want, but feels a little bit >>> hacky. Yeah, same thing I think. Was just talking it through more for my own benefit really :-) > > >> It all seems rather wasteful though. You’ve added a couple of layers of >> indirection into the system to save a handful of lines of code. Is it really >> that big a deal to write some custom setters? They’re only four lines long >> each. > > I agree that it’s extra indirection, but since performance is never going to > be an issue, I feel it’s a slight gain on tidiness and maintainability. I > agree that it’s not a big deal for one property, but when there are lots it > starts to add up. And it’s not just the setters - what finally spurred me > into action was the decision that I wanted all my properties to be atomic > (which may or may not be related to an occasional crash I have been seeing). > That means writing a correct threadsafe getter for each one as well… That’s a good point about how atomic accessors make the story a lot more complicated. BUT, why would atomic accessors help your crash? Views are pretty fundamentally tied to the main thread for the most part. Atomic accessors won’t help there. ___ 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: Custom NSView subclass - expressing the fact that a property affects the displayed image
On 22 May 2015, at 6:03 am, Jonathan Taylor
wrote:
> I agree that it’s extra indirection, but since performance is never going to
> be an issue, I feel it’s a slight gain on tidiness and maintainability. I
> agree that it’s not a big deal for one property, but when there are lots it
> starts to add up.
How about cooking up a macro for defining the accessors?
#define DECLARE_PROPERTY(PROPERTY,TYPE) \
@property (nonatomic, copy) TYPE PROPERTY;
#define DEFINE_PROPERTY(PROPERTY,TYPE) \
- (TYPE)PROPERTY \
{ \
return _##PROPERTY; \
} \
\
- (void)set##PROPERTY:(TYPE)x \
{ \
_##PROPERTY = x; \
[self setNeedsDisplay]; \
} \
...
@interface Foo
DECLARE_PROPERTY(widgetName, NSString *);
@end
...
@implmenetation Foo
DEFINE_PROPERTY(widgetName, NSString *);
@end
> And it’s not just the setters - what finally spurred me into action was the
> decision that I wanted all my properties to be atomic (which may or may not
> be related to an occasional crash I have been seeing). That means writing a
> correct threadsafe getter for each one as well...
Since you're talking about properties on an NSView subclass, and NSView is
documented as being not thread-safe, the atomicity thing sounds like a big red
herring (or red flag, depending on your preference for fish or cloth).
b
___
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: NSFontPanel swamping the responder chain (and crashing)
On 21 May 2015, at 1:33 am, Graham Cox wrote: > I can’t do a ‘po self’, even just typing it in, at this point, no matter how > cunning I am at breaking at the right time. It seems as if there really isn’t > enough info to resolve ‘self’ (the message is "error: use of undeclared > identifier ‘self’") > As you suggest, it’s probably a register, but don’t know which. I get the > same error if I try any of them - undeclared identifier ‘r15’ for example. In lldb you can name a register by slapping a dollar sign before its name, e.g.: (lldb) po $edx (This is retrieving 'self' when running in the iOS Simulator; I don't have a Mac OS X project at hand as I type this so the register use is probably different but presumably the same technique should apply.) b ___ 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
Contact - Selection on UiTableView Does Works Only in The First Row
Hi, I am developing manually a list. After add the view at the main view, only the first item of the tableView is enabling the selection. Do someone know about it? My code: BoxListaGruposController *boxListaGruposController = [ [ BoxListaGruposController alloc ] init ]; [ boxListaGruposController.tableView setDataSource:self ]; [ boxListaGruposController.tableView setDelegate:self ]; [ boxListaGruposController.tableView setTableFooterView:nil ]; boxListaGruposController.tableView.tableFooterView = [[UIView alloc] initWithFrame:CGRectZero]; UIView *boxLista = [ [ UIView alloc ] initWithFrame: [ ObjectSize boxToList ] ]; [ boxLista addSubview: boxListaGruposController.view ]; [ boxLista setBackgroundColor: [Colors white]]; [[boxListaGruposController.tableView layer] setMasksToBounds: YES]; [boxListaGruposController.tableView setShowsVerticalScrollIndicator: YES ]; [self.view addSubview: boxLista ]; Thank you! -- Atenciosamente, Wesley C. Dias de Oliveira Desenvolvimento +55 (31) 3324-5710 Avenida Luiz Paulo Franco, 603 – 3º andar – Belvedere – BH – MG – CEP: 30320-570 Transformando localização em soluções inteligentes ___ 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: Custom NSView subclass - expressing the fact that a property affects the displayed image
Thanks for your reply Mike: > Well you could have a single key which you observe internally, and which all > the other keys feed into. Whenever it “changes”, treat that as time to mark > as needing display. That way you’re asking AppKit to do the work of creating > all the other observations for you. I think this is what I was describing here, isn’t it (or am I misunderstanding you?): >> I could create a single “dummy” property of my own, say that changes to all >> these other properties affect that key, and then monitor that single key >> using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other >> property change). That would do what I want, but feels a little bit hacky. > It all seems rather wasteful though. You’ve added a couple of layers of > indirection into the system to save a handful of lines of code. Is it really > that big a deal to write some custom setters? They’re only four lines long > each. I agree that it’s extra indirection, but since performance is never going to be an issue, I feel it’s a slight gain on tidiness and maintainability. I agree that it’s not a big deal for one property, but when there are lots it starts to add up. And it’s not just the setters - what finally spurred me into action was the decision that I wanted all my properties to be atomic (which may or may not be related to an occasional crash I have been seeing). That means writing a correct threadsafe getter for each one as well... ___ 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: Disabling auto-synthesis of property accessors.
AHA. I am incorrect. Now in the office, when reviewing my code in the test, I wasn't testing auto-synthesis of the properties. Now that I am, I can see that auto-synthesized properties DO create the ivar with the leading underscore. Stepping back to my original question, the code that I am refactoring has cases of manual synthesis of properties, some automatically synthesized and some instance variables declared in the .h or .m interfaces - sometimes. With regards to understanding what is going on in the 4000 line view controllers, the areas that were problematic for me were where the instance variables were declared in the interface as someProperty (or as Someproperty, ugh) and then the property was declared and manually synthesized with the same name. So, then trying to wade through the code with identical names for properties and instance variables and with cases where the variable sometimes starts with a capital letter, knowing exactly what I was looking at was not exactly straightforward. With regards to Uli's comment, I just checked in my test code and if I create a property in the .h file like so: @property (nonatomic, strong) NSString *thing; Don't try to manually synthesize it and then in the .m file, in a method typed: _thi Xcode attempts to auto-complete this to _thing. Great. Completing the code below, and running the test clearly shows that auto-synthesis of properties does what Uli mentioned. _thing = @"$"; NSLog(@"self.thing: %@", self.thing); Console ] self.thing: $ The ivar is preceded with the underscore with auto-synthesis. What I believe the easiest thing to do in my case is to go through all the interface declarations of iVars, fix the case and precede them with underscores, then the property declarations & auto-synthesis of properties. If I try to rename an ivar declared in the @interface using Refactor, Xcode also renames the property itself and since I'm looking for a visual difference between the properties and the ivars, it's just easier this way. Keeping the declared ivars in the @interfaces keeps a nice visual table of contents of the ivars the original authors intended. While removing the ivars and letting Xcode auto-synthesize would be less code, it's also less descriptive and for this project, I want as much explanation of that's going on as possible. Parts of it are excellent but other parts, other parts, well…. Now, back to the joys of ad-hoc deployment. Thanks for the wake up call, UIi! Cheers, Alex Zavatone On May 22, 2015, at 7:05 AM, Alex Zavatone wrote: > > On May 22, 2015, at 3:43 AM, Uli Kusterer wrote: > >> On 21 May 2015, at 19:55, Quincey Morris >> wrote: >>> On May 21, 2015, at 10:40 , Fritz Anderson wrote: I must have misinterpreted the question. I had understood Alex wanted a build option to turn off the auto-synthesis of properties, so the compiler could complain at every conflation of ivars with @propertys. >>> >>> You didn’t misinterpret the question, but there’s no such build setting, so >>> you have to solve the problem indirectly. >>> >>> — You turn on the @synthesize warning. >>> >>> — The warning message tells you when you’ve omitted a @synthesize. >>> >>> — You add the “new-style” @synthesize: >>> >>> @synthesize myProperty = _myProperty; >>> >>> — Then all of your old naked ‘myProperty’ ivar references produce compile >>> errors. QED. >>> >>> Changing an old-style ‘@synthesize myProperty;’ to the new style leads to a >>> similar result, but there’s no initial warning message to lead you there by >>> the hand. >> >> That seems pointless, as auto-synthesis already names the backing ivar it >> creates _myProperty. Looking at the original thread "Stupid Cocoa question. >> How can you tell if the object you are looking at is a property or an ivar?” >> that spawned this, just deleting all the ivar declarations and @synthesize >> directives might be a better idea, then direct ivar accesses don’t find >> anything named myProperty and will error out directly. Or synthesize all >> properties with a name nobody is using yet for the backing ivar, if you have >> some that use _foo, or mFoo and others that just use foo. > > Yeah, but I just tested it this yesterday and it doesn't appear to do that. > > It creates an underlying myProperty ivar for a myProperty property, not an > underlying _myProperty ivar. > > I'll send the source when in get in the office in an hour, so you can test > for yourself if you want to. > > 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 __
Re: Custom NSView subclass - expressing the fact that a property affects the displayed image
> On 22 May 2015, at 13:51, Jonathan Taylor > wrote: > > I’m trying to think if there is an elegant way of handling the situation I > find in some of my display code. I have a class which inherits from NSView > and which overrides drawRect. The class has a number of properties, and if > they change then the view needs redrawing. At present I have custom setters > that call through to setNeedsDisplay:YES. This results in quite a lot of code > bloat (since I would otherwise just @synthesize the properties and be done > with it). > > I could set an observer on each property, but that would be a bit tedious > (especially since, as I understand it, I have to remove EACH of the observers > individually as well on dealloc). > > I am trying to think if there is a way I can leverage > keyPathsForValuesAffectingValueForKey to make things a bit simpler. I’m quite > a fan of using that where I can. It would be great if I could say that all my > properties affect some particular property of NSView that would trigger a > redraw. I can’t think of one that would do the trick, though. [If you think > about it, the property needsDisplay is NOT the one I want to say is affected > by my keys…] > > I could create a single “dummy” property of my own, say that changes to all > these other properties affect that key, and then monitor that single key > using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other > property change). That would do what I want, but feels a little bit hacky. > > Does anybody have any thoughts about what I might do? I feel this is probably > a relatively common problem that people must have a way of dealing with… Well you could have a single key which you observe internally, and which all the other keys feed into. Whenever it “changes”, treat that as time to mark as needing display. That way you’re asking AppKit to do the work of creating all the other observations for you. It all seems rather wasteful though. You’ve added a couple of layers of indirection into the system to save a handful of lines of code. Is it really that big a deal to write some custom setters? They’re only four lines long each. ___ 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
Custom NSView subclass - expressing the fact that a property affects the displayed image
I’m trying to think if there is an elegant way of handling the situation I find in some of my display code. I have a class which inherits from NSView and which overrides drawRect. The class has a number of properties, and if they change then the view needs redrawing. At present I have custom setters that call through to setNeedsDisplay:YES. This results in quite a lot of code bloat (since I would otherwise just @synthesize the properties and be done with it). I could set an observer on each property, but that would be a bit tedious (especially since, as I understand it, I have to remove EACH of the observers individually as well on dealloc). I am trying to think if there is a way I can leverage keyPathsForValuesAffectingValueForKey to make things a bit simpler. I’m quite a fan of using that where I can. It would be great if I could say that all my properties affect some particular property of NSView that would trigger a redraw. I can’t think of one that would do the trick, though. [If you think about it, the property needsDisplay is NOT the one I want to say is affected by my keys…] I could create a single “dummy” property of my own, say that changes to all these other properties affect that key, and then monitor that single key using KVO (and call setNeedsDisplay whenever it gets “tickled” by some other property change). That would do what I want, but feels a little bit hacky. Does anybody have any thoughts about what I might do? I feel this is probably a relatively common problem that people must have a way of dealing with… Cheers Jonny ___ 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
Invalid amor - what does this mean?
Using the STKaiti-SC-Black font (display name: Kaiti SC Black) (in TextEdit,
Font Book, or whatever) I get lines like this:
[some app] CoreText: Invalid ‘amor’ Subtable In name = STKaiti-SC-Black, size =
36.00, matrix = 0x0, descriptor = {attributes = {type
= mutable dict, count = 1,
entries =>
2 : {contents =
"NSFontNameAttribute"} = {contents =
"STKaiti-SC-Black"}
}
>}
Does this mean that the font is corrupted? Font Book → File → Validate Font
reports no problems.
This font may be part of the “additional asian fonts” which are only installed
on demand.
Gerriet.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Disabling auto-synthesis of property accessors.
On May 22, 2015, at 3:43 AM, Uli Kusterer wrote: > On 21 May 2015, at 19:55, Quincey Morris > wrote: >> On May 21, 2015, at 10:40 , Fritz Anderson wrote: >>> >>> I must have misinterpreted the question. I had understood Alex wanted a >>> build option to turn off the auto-synthesis of properties, so the compiler >>> could complain at every conflation of ivars with @propertys. >> >> You didn’t misinterpret the question, but there’s no such build setting, so >> you have to solve the problem indirectly. >> >> — You turn on the @synthesize warning. >> >> — The warning message tells you when you’ve omitted a @synthesize. >> >> — You add the “new-style” @synthesize: >> >> @synthesize myProperty = _myProperty; >> >> — Then all of your old naked ‘myProperty’ ivar references produce compile >> errors. QED. >> >> Changing an old-style ‘@synthesize myProperty;’ to the new style leads to a >> similar result, but there’s no initial warning message to lead you there by >> the hand. > > That seems pointless, as auto-synthesis already names the backing ivar it > creates _myProperty. Looking at the original thread "Stupid Cocoa question. > How can you tell if the object you are looking at is a property or an ivar?” > that spawned this, just deleting all the ivar declarations and @synthesize > directives might be a better idea, then direct ivar accesses don’t find > anything named myProperty and will error out directly. Or synthesize all > properties with a name nobody is using yet for the backing ivar, if you have > some that use _foo, or mFoo and others that just use foo. Yeah, but I just tested it this yesterday and it doesn't appear to do that. It creates an underlying myProperty ivar for a myProperty property, not an underlying _myProperty ivar. I'll send the source when in get in the office in an hour, so you can test for yourself if you want to. 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
Re: Disabling auto-synthesis of property accessors.
On 21 May 2015, at 19:55, Quincey Morris wrote: > On May 21, 2015, at 10:40 , Fritz Anderson wrote: >> >> I must have misinterpreted the question. I had understood Alex wanted a >> build option to turn off the auto-synthesis of properties, so the compiler >> could complain at every conflation of ivars with @propertys. > > You didn’t misinterpret the question, but there’s no such build setting, so > you have to solve the problem indirectly. > > — You turn on the @synthesize warning. > > — The warning message tells you when you’ve omitted a @synthesize. > > — You add the “new-style” @synthesize: > > @synthesize myProperty = _myProperty; > > — Then all of your old naked ‘myProperty’ ivar references produce compile > errors. QED. > > Changing an old-style ‘@synthesize myProperty;’ to the new style leads to a > similar result, but there’s no initial warning message to lead you there by > the hand. That seems pointless, as auto-synthesis already names the backing ivar it creates _myProperty. Looking at the original thread "Stupid Cocoa question. How can you tell if the object you are looking at is a property or an ivar?” that spawned this, just deleting all the ivar declarations and @synthesize directives might be a better idea, then direct ivar accesses don’t find anything named myProperty and will error out directly. Or synthesize all properties with a name nobody is using yet for the backing ivar, if you have some that use _foo, or mFoo and others that just use foo. Cheers, -- Uli Kusterer “The Witnesses of TeachText are everywhere...” http://zathras.de ___ 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
