Re: IB_DESIGNABLE - anyone got it to work?
Re: IB_DESIGNABLE - anyone got it to work?
- Subject: Re: IB_DESIGNABLE - anyone got it to work?
- From: Kyle Sluder <email@hidden>
- Date: Tue, 12 May 2015 18:19:41 -0700
> On May 12, 2015, at 5:49 PM, Graham Cox <email@hidden> wrote:
>
>
>> On 13 May 2015, at 10:06 am, Kyle Sluder <email@hidden> 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 (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