Some background:
I wrote a UIScrollView derived class with an outlet named contentView, similar to the following:
@interface MyScrollView : UIScrollView {
IBOutlet UIView * contentView;
}
...
@end
My outlet, in this case is an iVar, not a property. I made use of my class in Interface builder and connected a view to the contentView outlet. At runtime, however, I discovered that my iVar was still nil and was not set to the desired view object.
Some experimentation revealed that if I renamed the outlet or made my outlet a property instead of an iVar, all would work fine. Further research showed that with my outlet as an iVar named contentView, loading the nib would actually connect my desired view object to a private iVar in UIScrollView named _contentView.
I know that nib loading uses KVC to set values and that the KVC setValue:forKey: method will set a value using any of the following:
set{Key}:method{key}iVar_{key}iVar
I suspect, but cannot prove, that an attempt to find the set{Key}: method occurs first, and if that fails, an enumeration of iVars is undertaken to find the {key} or _{key} iVar next. This enumeration probably occurs in an order that processes iVars from superclasses before subclasses.
Is there a documented order in which the above candidates are attempted? In what order are members of superclasses attempted in relation to subclasses?
The specific search algorithm is documented in the Key-Value Coding Programming Guide.