> On May 12, 2015, at 5:49 PM, Graham Cox <graham....@bigpond.com> wrote: > > >> On 13 May 2015, at 10:06 am, Kyle Sluder <k...@ksluder.com> wrote: >> >> On Tue, May 12, 2015, at 06:38 PM, Graham Cox wrote: >>> >>> So it looks as if a property that is IBInspectable may be getting >>> incorrectly set to 0 by IB AFTER -initWithFrame: is called, maybe because >>> the user interacts with the inspectable properties but doesn’t set a >>> value - rather than leaving it alone it forces it to 0. That’s definitely >>> a bug. It could also be caused by the stale values I mentioned before, >>> where removing IBInspectable attribute from a property doesn’t remove the >>> property setting in the nib. >> >> IBInspectable properties are just a convenience for setting User-Defined >> Runtime Attributes on the Identity inspector. Since the original purpose >> of User-Defined Runtime Attributes is to set values that IB doesn't know >> about, IB can't forget settings for which the IBInspectable property has >> been removed. >> >> Likewise, there is no such thing as a "valueless" User-Defined Runtime >> Attribute. Conceptually, we could add one, since UDRAs are just a way to >> say "call -setValue:forKey: after decoding", and nil values are >> acceptable here (as opposed to, say, dictionaries). > > > When you say ‘we’, does that mean this is something you are working on?
I don’t work on Interface Builder. > > If there’s no such thing as a ‘valueless’ inspectable property, why does the > UI seem to indicate that there is - for example a BOOL property has on, off > and ‘default’, and a numeric property shows ‘- -‘ instead of its initial > value? This is confusing because it appears to imply that if you don’t enter > a value, the property will not be touched and whatever the code initialises > it to will be used. Instead, what actually happens is that it’s set to 0, NO, > nil, etc depending on type. I was speaking from the perspective of UDRAs: you can't set a nil Number or String, for example. If you have "default" properties, those definitely should not be touched, and you should file a bug. > > Because IB is always invoking -initWithCoder: even though I was expecting > -initWithFrame: (I’ve fixed that by calling some common initialisation), it > means that the coder method has to be liberally sprinkled with if([coder > containsValueForKey:…]) tests so that properties don’t get wiped out by 0, > NO, nil when they’re not present. Ah, I see what you mean now. I actually think that whether IB calls -initWithCoder: or -initWithFrame: is technically undocumented. You should file a bug about that, too. > Obviously, after this, properties that are UDRAs are set anyway. The problem > is that if a property was IBInspectable for a while, and then not made > IBInspectable, a stale value of 0 for that property remains in the nib, even > though there’s no interface to it at all - neither a UDRA or IBInspectable. OK, that surprises me. If you peek at the XIB contents, do you see the dummy values for the IBInspectable properties there? --Kyle Sluder _______________________________________________ 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
