Changing control name property during runtime -- Why doesn't anything break and why shouldn't I do it?

Question

To make a long story short, I needed a property of a button to act as a "secondary text property" and retain the original .Text value of a button, and the only String property that wasn't ReadOnly was the .Name property.

I was sure it was going to break on runtime (as tons of code references the name of the control) but just for kicks, I wanted to run it and see what it would do.

I my shock and surprise, IT DIDN'T BREAK! And it actually served my purpose of temporarily holding the original text of the button, in time for me to retrieve it again.

Thus my two questions

(like the surprised kid after he pushed a glass plate on the floor):

1. Why didn't it break?
2. And why shouldn't I do it again?

I have a few guesses, but I wouldn't know how to confirm them, so this is my first venture for answers:

1. I was thinking one possibility is that the .Name property "already served its purpose" by runtime as the code is already compiled, and all references are already made to the instance, and therefore, altering the .Name property does nothing in runtime. But that almost seems too simple an answer.

2. Maybe I was not actually changing the property, but that seems a silly thing to consider since I was able to retrieve the value.

3. I finally considered that I've entered the twilight zone and I'll be hunted down and imprisoned by Microsoft for not learning the moral lesson of following proper coding conventions. (Sarcasm; no need to edit my post for this)

I'm inclined to think #1 is the answer, but it seems too simple, and I can't help but think that I'm going to get scolded for messing with it.

Any insight or notes about conventions (even a slap on the wrist) would be appreciated.

Added code example:

(NOTE: I now understand .Tag is a better to use than .Name for this purpose, but this is still a good example for my question.)

Private Sub btn_Paint(sender As Object, e As System.Windows.Forms.PaintEventArgs)
    Dim btn As Button = DirectCast(sender, Button)

    'Make sure to only pull the text when it actually has text.
    If btn.Text > " " Then
        btn.Name = btn.Text
    End If

    btn.Text = String.Empty

    'Set flags to center text on button
    Dim flags As TextFormatFlags = TextFormatFlags.HorizontalCenter Or TextFormatFlags.VerticalCenter Or TextFormatFlags.WordBreak   'center the text

    'Render the text onto the button
    TextRenderer.DrawText(e.Graphics, btn.Name, btn.Font, e.ClipRectangle, btn.ForeColor, flags)
End Sub

Answer 1

Name is used by the designer.

Usually you do not have the need to find a control by name, or identify a control by name, in runtime. If that is the case, then, arguably Name already served its purpose (being used by the designer).

A reason to not mess with it? How about showing intent. It might not be clear to the reader of your code that Name may hold the text of the control temporarily. In fact, what if you need to store something else temporarily and go for Name again? Since there is nothing saying that you are using Name this way, and given enough time for you to forget, or if the code is being maintained by another person, that might introduce some bugs.

Of course, you may use Name in runtime in other ways, without losing the idea that it identifies the control. For example, if you have a single event handler for multiple controls (which might be the case if you added such controls in runtime, or even in the designer, if it makes sense to reuse the same code for all of them), you may use name to identify them. Another thing you can do is use the name as key in a dictionary.

If you need to temporarily hold the text, you could use a local variable or a field… if this needs to be attached to the control (aside from the dictionary idea, which seems like too much overhead for this), then the usual course of action is create a custom control that either sub-classes or wraps the text box (in this case).

I believe you want a text box with some custom rendering. In that case, a custom control seems like a good idea. Let the control handle its own rendering. Alternatively, if the intention was to allow the user to write in the text box and then hide it… well, hide it (Control.Visible = false). You may consider disabling it too. And yes, having a custom control that can show a text box or some pretty rendered text and switches between on demand is good idea too.

Answer 2

*#1 for sure. If it wasn't for Reflection it would have been discarded at the link phase (or equivalent). You'll probably find this kind of thing breaks down when you use stuff that's dynamic like the .NET API and such like.

Seems like a bad idea in principle, if only because you're a) using something for a purpose it wasn't intended for and b) doesn't have a name that reflects the use. Neither of which are crimes, just bad ideas worthy of tdwtf.com

Answer 3

Why didn't it break?

Either because it’s not used or because your test didn’t exercise the code that uses it.

And why shouldn't I do it again?

Because this is semantically evil. If it’s called Name it should have something to do with a name.