Gilbert said:
Armin,
Thank you for your comments.
1. I am interested in the way how to retrieve a property name,
whatever application one can do with that.
If you look at your source code you also know the property name. It does not
change while the application runs.
(yes, know that's not the point)
2. The example is just a piece of code to show how to use
MethodBase.GetCurrentMethod.Name. It does not have the pretention to
be a perfect program.
We would have been able to tell you how to get the name of the _current_
method by creating a Stackframe/trace, but your questions sounded as if you
wanted to refer to the property _outside_ the property.
3. "What do yo do if you haven't accessed the property before?". Good
remark. That's why the property is accessed by the Sub New, so it
does not matter.
Oh, well, then it's a good solution - not.
4. "What if you change the Function name?" Which Function name? There
is no Function in my example.
Public Function GetDisplayName() As String
5. "What if there are more properties and consequently property
names?" If you need so you just create as many methods as you need.
My example uses two methods for two properties.
6. "How do you distinguish between them?" By the method name.
7. "What if the property names and (consequently) their corresponding
GetXYDisplayName change?" If you correctly rename the property by
rigth click / rename then you do not get any problem, the program
still works as before. I do not agree on "and (consequently) their
corresponding GetXYDisplayName", it does not change. But it would be
nice to change it also to keep a better meaning in the name, that's
true.
I asked the questions to lead you to the fact that multiple properties
require multiple, differently named functions that should have appropriate
names to indicate which property they are related to. The consequence is
that, if you you rename a property, you have to rename the function
returning the names of their corresponding properties.
8. Anyway, what if you work "normally", and you write like this ?
MaListBox.DisplayMember = "CustomerName"
MaListBox.ValueMember = "CustomerID"
MaListBox.DataSource = LstClient
Then you can be sure that if you rename a property, you get no
compile flag but your program works differently !
Yes, much better than calling each property inside the constructor just to
be able to get the stackframe in order to get the name of a property. This
is one of the most bizarre scenarios of abuse of reflection I've ever seen.
IMHO, this is unacceptable because a property is called because you want to
get/set it. What if you don't want to make the property really work but just
want to initialize the field holding the property name?
What you are doing reminds me of a "programming technique" I came across
several years ago (in VB6): A method had static local variables. The method
had an additional Boolean argument. If the argument was True, the only thing
the method did was setting the static variables to Nothing (because there
was no other way to do this from outside). You may call it a solution but I
call it a hack. The problem was that the approach was wrong. However, I'm
not able to explain what's wrong or right.
Armin