Name of component instance

[Harlan Messinger]

When I create a custom control, within its defining code I have access
to the eventual name of the actual control instantiated from it via
this.Name. This allows me, for example, to print out an error message
from within one of the control's properties that identifies the
offending control by the name the user assigned to it:

if (dataName == null || dataName.Equals(""))
throw new InvalidOperationException("Property \"DataName\" not set for
PersistingTextBox control \"" + this.Name + "\".");

The client app would return "persistentTextBox1" for this.Name if the
developer left the default name for the first PersistentTextBox object
on the form.

However, a Component doesn't seem to have the same feature. It has no
Name property, or anything else that I can find that would return the
name of the instantiated component. Is there some way to do this?

 

[Peter Duniho]

When I create a custom control, within its defining code I have access
to the eventual name of the actual control instantiated from it via
this.Name. This allows me, for example, to print out an error message
from within one of the control's properties that identifies the
offending control by the name the user assigned to it:

if (dataName == null || dataName.Equals(""))
throw new InvalidOperationException("Property \"DataName\" not set for
PersistingTextBox control \"" + this.Name + "\".");

The client app would return "persistentTextBox1" for this.Name if the
developer left the default name for the first PersistentTextBox object
on the form.

However, a Component doesn't seem to have the same feature. It has no
Name property, or anything else that I can find that would return the
name of the instantiated component. Is there some way to do this?

As you've already noted, the Name property is declared in the Control
class, not the Component class, and is simply an arbitrarily chosen string
anyway. An instantiated Component doesn't have a name to return, so
no...there's no way to do this.

Remember, just because the Designer has included a member field named
"persistentTextBox1" in which to store a reference to your Control object
instance, that doesn't actually mean that the Control object instance's
natural name is in fact "persistentTextBox1". The name is simply whatever
you decided to give it, irrespective of the whatever name(s) may be given
to variables referencing that object (assuming there are even any such
variables...a Designer object need not even generate a member field,
depending on what the user's chosen).

It's not clear to me why you need this for Components generally, but you
can always create and maintain a dictionary that maps Component instances
to strings.

Pete

 

[Harlan Messinger]

As you've already noted, the Name property is declared in the Control
class, not the Component class, and is simply an arbitrarily chosen
string anyway. An instantiated Component doesn't have a name to return,
so no...there's no way to do this.

Remember, just because the Designer has included a member field named
"persistentTextBox1" in which to store a reference to your Control
object instance, that doesn't actually mean that the Control object
instance's natural name is in fact "persistentTextBox1".

I didn't mean to imply that I thought it was a natural name. I was just
clarifying what I intended my code to do: tell the developer which
control is causing the problem, *whatever* it's called.

The name is

simply whatever you decided to give it, irrespective of the whatever
name(s) may be given to variables referencing that object (assuming
there are even any such variables...a Designer object need not even
generate a member field, depending on what the user's chosen).

It's not clear to me why you need this for Components generally, but you
can always create and maintain a dictionary that maps Component
instances to strings.

Components that have been added to a form have names (the first
Persister component I add to a form is by default given the name
persister1, though of course I can change this, just as the first Timer
component on a form is named timer1 unless I change it), and if one of
them is causing a problem, it's desirable to tell the developer which
one it is, no?

 

[Peter Duniho]

[...]

It's not clear to me why you need this for Components generally, but
you can always create and maintain a dictionary that maps Component
instances to strings.

Components that have been added to a form have names

Not if they don't have names, they don't. If they do have names, it's
because they are in fact of a type that inherits Component and which
_adds_ a name property. For example, a Control, with its Name property.

(the first Persister component I add to a form is by default given the
name persister1, though of course I can change this, just as the first
Timer component on a form is named timer1 unless I change it),

I don't know what you mean. The only thing you can change about a
System.Windows.Forms.Timer you add to a Form is the name of the member
field that stores the reference to the object. The object itself has no
name, never mind one that can be changed. You're not specific about what
you mean by "Persister component", but the same thing would apply. If it
simply inherits Component, and does not add its own property for a name,
then the object itself has no name.

and if one of them is causing a problem, it's desirable to tell the
developer which one it is, no?

If the object has a name, then sure...I can see the value in using that
name in an error message. But you have to start with an object that has a
name. As I said before, just because there may be a named member field
referencing an object, that doesn't mean the object necessarily has a name.

Pete

 

[Harlan Messinger]

[...]

It's not clear to me why you need this for Components generally, but
you can always create and maintain a dictionary that maps Component
instances to strings.

Components that have been added to a form have names

Not if they don't have names, they don't. If they do have names, it's
because they are in fact of a type that inherits Component and which
_adds_ a name property. For example, a Control, with its Name property.

When I created my Persister component, and dragged the first one onto a
form, it showed up under the form with "persister1" next to the little
gear icon, and the first setting in the Properties pane reads "(Name)
persister1". I can change "persister1" to anything else I want. I did
not create this Name property.

I don't know what you mean.

When I drag a Timer component onto the form, a clock icon shows up under
the form with the word "timer1" next to it, and the first setting in the
Properties pane reads "(Name) timer1". I can change "timer1" to anything
else I want.

The only thing you can change about a
System.Windows.Forms.Timer you add to a Form is the name of the member
field that stores the reference to the object. The object itself has no
name, never mind one that can be changed.

I'm sitting here, changing the value of the GenerateMember to False, and
still I see "(Name) persister1", and still I can change it to something
else, like "xyz", and then the label next to the gear icon also changes
to "xyz". In fact, I also have an instance of my PersistingTextBox
custom control on the form, called "persistingTextBox1".
PersistingTextBox has a property called Persister, which references an
object of class Persister, and in the Properties pane I had originally
set the Persister property of persistingTextBox1 to persister1. Now that
I've changed the name of persister1 to "xyz", I see that the Persister
property of persistingTextBox1.Persister has also been changed to "xyz".

You're not specific about
what you mean by "Persister component", but the same thing would apply.
If it simply inherits Component, and does not add its own property for a
name, then the object itself has no name.

All the evidence in front of me tells me otherwise, for both Persisters
and Timers.

If the object has a name, then sure...I can see the value in using that
name in an error message. But you have to start with an object that has
a name. As I said before, just because there may be a named member
field referencing an object, that doesn't mean the object necessarily
has a name.

I'm not talking about a named member field.

 

[Jeff Johnson]

I don't know what you mean. The only thing you can change about a
System.Windows.Forms.Timer you add to a Form is the name of the member
field that stores the reference to the object. The object itself has no
name, never mind one that can be changed. You're not specific about what
you mean by "Persister component", but the same thing would apply. If it
simply inherits Component, and does not add its own property for a name,
then the object itself has no name.

I think what's confusing him is that in Visual Studio, every object you add
to a form has an entry in the Properties windows called "(Name)". This, as
you point out (and as the help text for the property sort of points out) is
really the name of the variable (i.e., field) that is created in code to
hold a reference to this control. Those controls that do implement a real
Name property seem to hide it in the Properties window and synchronize it
with the (Name) pseudo-property, so I can forgive people for confusing the
two and thinking that anything that can be added to a designer window has a
name.

 

[Harlan Messinger]

On Mon, 31 Aug 2009 12:49:16 -0700, Harlan Messinger

[...]
It's not clear to me why you need this for Components generally,
but you can always create and maintain a dictionary that maps
Component instances to strings.

Components that have been added to a form have names
Not if they don't have names, they don't. If they do have names,
it's because they are in fact of a type that inherits Component and
which _adds_ a name property. For example, a Control, with its Name
property.

When I created my Persister component, and dragged the first one onto
a form, it showed up under the form with "persister1" next to the
little gear icon, and the first setting in the Properties pane reads
"(Name) persister1". I can change "persister1" to anything else I
want. I did not create this Name property.

Look more closely. That's not a property of the object. As I've
written twice already, it simply names the member field storing a
reference to the object (or the local variable in the
InitializeComponent() if you have set the "GenerateMember" value to
"false").

I don't see where you've written that once, let alone twice, but so be
it. I understand now what you mean about the name existing only within
the scope of InitializeComponent.

Do not confuse Designer "properties" with C#/.NET "properties". There
can be a correlation, but they are not necessarily the same.


See above.


That doesn't mean that the object has a name property. It just means
that the Designer has provided you with a label for it.

I didn't say it had a Name property. On the contrary, that was the whole
problem. Not finding a Name *property*, I was trying to find out how to
get a hold of the component's *name*.

If you look at
the code initializing the object, you'll find that the label in the
Designer is never used as part of the object's initialization. The
_object_ itself (which does not exist until you run the program) has no
name.
OK.


Again, the fact that the Design has provided a label with which you can
manipulate the objects _in the Designer_ in no way means that the object
itself has a name.

You can examine the code that the Designer generates by looking at the
*.Designer.cs file(s) in your project. There, you can see better how
the Designer label is and is not used.

Ah, OK.

You are misinterpreting the "evidence" to suit your desires.

No, I am not, it is simply that I wasn't abiding by, or even aware of,
your personal strict division of the world into that-which-is-a-"name"
and that-which-is-not-a-"name". You're being kind of a Rene Magritte
("Ceci n'est pas une pipe"): I'm showing you a pipe and saying, "Here's
a pipe", and you're responding not only that it isn't a pipe, but that
I'm misinterpreting the evidence to suit my desires.

Don't get me wrong: I don't think you're intentionally giving me a hard
time. But you're being a lot clearer in this last post of yours than you
were before: you were supposing that I was following the implicit
distinction you were making between the designer and the runtime
objects, when that was the whole crux of the problem.

 

[Harlan Messinger]

I think what's confusing him is that in Visual Studio, every object you add
to a form has an entry in the Properties windows called "(Name)". This, as
you point out (and as the help text for the property sort of points out) is
really the name of the variable (i.e., field) that is created in code to
hold a reference to this control. Those controls that do implement a real
Name property seem to hide it in the Properties window and synchronize it
with the (Name) pseudo-property, so I can forgive people for confusing the
two and thinking that anything that can be added to a designer window has a
name.

Thank you.