Mailing lists / fpc-devel / 2007-06
TComponent.Name can not be set to ''
13 messages · 5 people ·
- Michael Van Canneyt 6
- Marc Weustink 4
- Graeme Geldenhuys 1
- Martin Schreiber 1
- Micha Nelissen 1
Reply by email Subscribe to this list Your subscription
Read-only archive. Use j and k to move between messages.
The other thing I noticed as well is that you can't use the hash (#) character in the component name anymore.
I used to name all internal components in fpGUI as '#button' or '#edit'. I had to change all of them to '_button' or '_edit'. Not a show stopper though.
Graeme.
Martin Schreiber wrote 6 lines
Hi,
A possible show stopper for FPC 2.2:
http://www.freepascal.org/mantis/view.php?id=9115
Martin
A possible show stopper for FPC 2.2: http://www.freepascal.org/mantis/view.php?id=9115…
Martin Schreiber wroteHi, A possible show stopper for FPC 2.2: http://www.freepascal.org/mantis/view.php?id=9115
Fixed and merged.
Michael.
The other thing I noticed as well is that you can't use the hash (#) character in the…
Graeme Geldenhuys wrote 6 lines
The other thing I noticed as well is that you can't use the hash (#)
character in the component name anymore.
I used to name all internal components in fpGUI as '#button' or
'#edit'. I had to change all of them to '_button' or '_edit'. Not a
show stopper though.
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, and that must be a valid pascal identifier...
Michael.
Show quoted text 16 lines
Graeme.
On 20/06/07, Martin Schreiber wrote:
> Hi,
> A possible show stopper for FPC 2.2:
>
> http://www.freepascal.org/mantis/view.php?id=9115
>
> Martin
_______________________________________________
fpc-devel maillist -
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Michael Van Canneyt wroteThis 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 ?
Micha
Micha Nelissen wrote 5 lines
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.
Michael.
Michael Van Canneyt wrote 13 lines
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 ?
Marc
Marc Weustink wrote 17 lines
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.
Michael.
Michael Van Canneyt wrote 22 lines
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 ?
Marc
Marc Weustink wrote 30 lines
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'
endend
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...
Michael.
Michael Van Canneyt wrote 53 lines
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.
Marc
Marc Weustink wrote 65 lines
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.
Michael.
Michael Van Canneyt wrote 73 lines
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