[fpc-devel] TComponent.Name can not be set to ''

[Marc Weustink]

Michael Van Canneyt wrote:
> 
> On Wed, 20 Jun 2007, Marc Weustink wrote:
> 
>> Michael Van Canneyt wrote:
>>> On Wed, 20 Jun 2007, Marc Weustink wrote:
>>>
>>>> Michael Van Canneyt wrote:
>>>>> On Wed, 20 Jun 2007, Marc Weustink wrote:
>>>>>
>>>>>> Michael Van Canneyt wrote:
>>>>>>> On Wed, 20 Jun 2007, Micha Nelissen wrote:
>>>>>>>
>>>>>>>> Michael Van Canneyt wrote:
>>>>>>>>> This is due to a Delphi compatibility fix. Component names must
>>>>>>>>> be
>>>>>>>>> valid
>>>>>>>>> identifiers. Logical, since the name must match the field name
>>>>>>>>> in
>>>>>>>>> the
>>>>>>>>> form,
>>>>>>>> Why *must* it match a field name in the form ?
>>>>>>> Because the streaming depends on it.
>>>>>>>
>>>>>>> The stream contains the component name. The streaming mechanism
>>>>>>> creates
>>>>>>> a
>>>>>>> component, sets it's name and then matches this name with the list
>>>>>>> of
>>>>>>> published fields of TForm, and then fills in the pointer.
>>>>>> And what if a published field isn't found ?
>>>>> Nothing. Since there is no pointer to fill in, nothing happens.
>>>>>
>>>>> And this is right, because if you were to create everything run-time,
>>>>> and
>>>>> stream
>>>>> that, there are no pointers to fill in when the stream is being read
>>>>> again.
>>>> :)
>>>> then back to Michas question: why must ?
>>> Because in the form declaration, the fieldname must match the name.
>>>
>>> Given
>>>
>>>   TMyForm = Class(TForm)
>>>     MyButton : TButton;
>>>   end;
>>>
>>> and a form file
>>>
>>> Object TmYForm
>>>   Object MyButton : TButton
>>>     Caption = 'Click here'
>>>   end
>>> end
>>>     The MyButton (=component name) in the form file is used to look up the
>>> MyButton field in TMyForm. If it doesn't find that, then things in code like
>>>
>>> MyButton.Enabled:=False;
>>>
>>> Would lead to a nice access violation, if the instance pointer is Nil...
>> Yes, I do understand this. An ide (or someone doing this manually) should
>> handle this. And for components which are streamed this way its a requirement.
>> However, it is IMO a bit strange that there are limitations on some property,
>> only because some usage indirectly requires a valid identifier. IMO, the
>> creator of this usage is responsible for that, not the component itself.
> 
> Maybe, but the current behaviour is Delphi compatible, and so it stays.
> 
> The streaming and thus TComponent was designed for form handling, so the 
> implementation is entirely in function of the usage.
> 
> If you don't want this behaviour, you can start at TPersistent, which
> can also be streamed, but does not have the restriction.

I've no problems with the current implementation. I only wondered why.

Marc