P
proxyuser
I was referring to the "ToString" imlemementation, not extensions.
I was referring to the "ToString" imlemementation, not extensions.
P
proxyuser
Peter Duniho said:
Because in that case, it would at least fail at run time when the call was
made. Then someone would know something is wrong and be forced to change
it. If they simply hard coded the output string, nothing would ever fail.
The output would be wrong though.
Think of this example. I'm not giving a reason why you'd want to write this
code, I'm just saying if you did, the second example is better. The reason
is that if the control name ever changes, the code will still work. I want
to do this, but with method names.
TextBox b1 = new TextBox();
b1.Name = "b1";
TextBox b2 = new TextBox();
b2.Name = "b2";
// bad
void f(Control c)
{
if (c.Name.Equals("b1"))
{
// output trace message that "function f is operating on control b1"
}
}
// better
void f(Control c)
{
if (c.Name.Equals(b1.Name))
{
// output trace message that String.Format("function f is operating on
control {0}", b1.Name)
}
}
P
proxyuser
Peter Duniho said:
Because in that case, it would at least fail at run time when the call was
made. Then someone would know something is wrong and be forced to change
it. If they simply hard coded the output string, nothing would ever fail.
The output would be wrong though.
Think of this example. I'm not giving a reason why you'd want to write this
code, I'm just saying if you did, the second example is better. The reason
is that if the control name ever changes, the code will still work. I want
to do this, but with method names.
TextBox b1 = new TextBox();
b1.Name = "b1";
TextBox b2 = new TextBox();
b2.Name = "b2";
// bad
void f(Control c)
{
if (c.Name.Equals("b1"))
{
// output trace message that "function f is operating on control b1"
}
}
// better
void f(Control c)
{
if (c.Name.Equals(b1.Name))
{
// output trace message that String.Format("function f is operating on
control {0}", b1.Name)
}
}
P
proxyuser
That's not necessarily true with regard to all objects (see my recent post
in this thread related to Windows control names.) Hence, I want to know if
there is a way to get it to work here.
You can safely assume that if I want to do it, it's of value - otherwise I
wouldn't have wasted my time on it.
P
proxyuser
That's not necessarily true with regard to all objects (see my recent post
in this thread related to Windows control names.) Hence, I want to know if
there is a way to get it to work here.
You can safely assume that if I want to do it, it's of value - otherwise I
wouldn't have wasted my time on it.
P
proxyuser
Registered User said:
The point is, I do know the name of the method, but I want to specify the
name in a form known to the compiler so changes can automatically be
handled. If I specify it in the form of a quoted string, the compiler can't
deal with it.
P
proxyuser
Registered User said:
The point is, I do know the name of the method, but I want to specify the
name in a form known to the compiler so changes can automatically be
handled. If I specify it in the form of a quoted string, the compiler can't
deal with it.
P
proxyuser
Well, it's proof that I want to do it, but frankly I'm a veteran of multiple
fora, and while I appreciate the volunteer nature of the answers, I do lose
patience with people who want to convince me I don't want to do something or
I shouldn't be asking the question. If they don't want to answer, they
don't have to, but please don't tell me I shouldn't be asking the question.
If someone can't conceive of any reason I might want to do something, then
they can simply consider it a theoretical exercise. If they don't want to
participate in a theoretical exercise, then don't.
Even if you don't accept my scenario, I'm sure you could come up with one
where this is valid. A tester is tasked with testing an API, and turns on
an application flag that gives trace output to the user. They click on a
menu option to determine what function is called when that event occurs.
They determine that the wrong function is being called and a bug is opened.
It turns out that the correct function is actually being called, but the
trace output was wrong. The trace output was wrong because the API changed
and the developer changed the function call, but did not change the trace
output. A bug is submitted, requiring a fix and a new build. Or there is
simply some back and forth to determine if there is actually any problem,
wasting time in the process. A compile error would have short circuited
this process from the start.
I'm sure you can think of other scenarios.
The name property is set by Windows designer, not the developer. But that
point is moot, because the point is *how* the error is caught, not *if*
something breaks. A compile error is preferrable to manual detection by a
person.
People also waste time on forums telling other people what they should be
spending their time on (I'm not referring to you.)
My ultimate goal is to get the name of a function programmatically. You say
it can't be done, so that's that.
P
proxyuser
Well, it's proof that I want to do it, but frankly I'm a veteran of multiple
fora, and while I appreciate the volunteer nature of the answers, I do lose
patience with people who want to convince me I don't want to do something or
I shouldn't be asking the question. If they don't want to answer, they
don't have to, but please don't tell me I shouldn't be asking the question.
If someone can't conceive of any reason I might want to do something, then
they can simply consider it a theoretical exercise. If they don't want to
participate in a theoretical exercise, then don't.
Even if you don't accept my scenario, I'm sure you could come up with one
where this is valid. A tester is tasked with testing an API, and turns on
an application flag that gives trace output to the user. They click on a
menu option to determine what function is called when that event occurs.
They determine that the wrong function is being called and a bug is opened.
It turns out that the correct function is actually being called, but the
trace output was wrong. The trace output was wrong because the API changed
and the developer changed the function call, but did not change the trace
output. A bug is submitted, requiring a fix and a new build. Or there is
simply some back and forth to determine if there is actually any problem,
wasting time in the process. A compile error would have short circuited
this process from the start.
I'm sure you can think of other scenarios.
The name property is set by Windows designer, not the developer. But that
point is moot, because the point is *how* the error is caught, not *if*
something breaks. A compile error is preferrable to manual detection by a
person.
People also waste time on forums telling other people what they should be
spending their time on (I'm not referring to you.)
My ultimate goal is to get the name of a function programmatically. You say
it can't be done, so that's that.
R
Registered User
A quick review revealed no reference in the thread to Windows control
names. It could be this client didn't retrieve that particular post.
In any case I don't see the connection between a Window control's Name
property and the topic addressed by this thread. Even an ASP.NET
control's ControlId property isn't relevant although that value is
automagically populated. The original question was about identifying
object methods by name without knowing their names. Different objects
of the same type all have the same method names regardless of the
objects' Name or, if supported, ControlId property.
Ah yes the old because I said so requirement. I'll let you do whatever
you wish with your time. Selah
regards
A.G.
R
Registered User
A quick review revealed no reference in the thread to Windows control
names. It could be this client didn't retrieve that particular post.
In any case I don't see the connection between a Window control's Name
property and the topic addressed by this thread. Even an ASP.NET
control's ControlId property isn't relevant although that value is
automagically populated. The original question was about identifying
object methods by name without knowing their names. Different objects
of the same type all have the same method names regardless of the
objects' Name or, if supported, ControlId property.
Ah yes the old because I said so requirement. I'll let you do whatever
you wish with your time. Selah
regards
A.G.
P
proxyuser
Registered User said:
See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.
Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.
P
proxyuser
Registered User said:
See the Name property of a Windows control and you'll see what I mean. This
is the variable name that the developer assigns to the instance of the
control.
Sorry, I just get tired of the "I don't understand the need for it therefore
you don't need to do it" type of responses.
R
Registered User
But we're not discussing all objects. The comment was specific to
using
MethodInfo mi = x.GetType().GetMethod("method")
to get the MethodInfo.Name property. The argument is the method name
which is the supposed to be the unknown. If the method name is already
known why bother? If the method name isn't known what argument can be
passed to the GetMethod method? As I said it's not a solution.
the name of a specific method of the type. A method is not an object
and does not have a Name property.
possible how-to's. If the desired functionality doesn't impact the
application and is of no value to the user, one can only question the
need for that functionality. Unnecessary complications should be
avoided.
Quite frankly displaying the name of a method which is about to be
invoked to the user does appear to be an unneccessary complication.
This becomes especially true if overloaded methods and anonymous
delegates are involved.
Don't take this personally but the "I thought of it" doesn't provide
the 'it' with any real value.
regards
A.G.
using
MethodInfo mi = x.GetType().GetMethod("method")
to get the MethodInfo.Name property. The argument is the method name
which is the supposed to be the unknown. If the method name is already
known why bother? If the method name isn't known what argument can be
passed to the GetMethod method? As I said it's not a solution.
I fail to see how an object's Name property can be used to identify
the name of a specific method of the type. A method is not an object
and does not have a Name property.
Being able to understand the why plays a big part in determining
possible how-to's. If the desired functionality doesn't impact the
application and is of no value to the user, one can only question the
need for that functionality. Unnecessary complications should be
avoided.
Quite frankly displaying the name of a method which is about to be
invoked to the user does appear to be an unneccessary complication.
This becomes especially true if overloaded methods and anonymous
delegates are involved.
Don't take this personally but the "I thought of it" doesn't provide
the 'it' with any real value.
regards
A.G.
R
Registered User
But we're not discussing all objects. The comment was specific to
using
MethodInfo mi = x.GetType().GetMethod("method")
to get the MethodInfo.Name property. The argument is the method name
which is the supposed to be the unknown. If the method name is already
known why bother? If the method name isn't known what argument can be
passed to the GetMethod method? As I said it's not a solution.
the name of a specific method of the type. A method is not an object
and does not have a Name property.
possible how-to's. If the desired functionality doesn't impact the
application and is of no value to the user, one can only question the
need for that functionality. Unnecessary complications should be
avoided.
Quite frankly displaying the name of a method which is about to be
invoked to the user does appear to be an unneccessary complication.
This becomes especially true if overloaded methods and anonymous
delegates are involved.
Don't take this personally but the "I thought of it" doesn't provide
the 'it' with any real value.
regards
A.G.
using
MethodInfo mi = x.GetType().GetMethod("method")
to get the MethodInfo.Name property. The argument is the method name
which is the supposed to be the unknown. If the method name is already
known why bother? If the method name isn't known what argument can be
passed to the GetMethod method? As I said it's not a solution.
I fail to see how an object's Name property can be used to identify
the name of a specific method of the type. A method is not an object
and does not have a Name property.
Being able to understand the why plays a big part in determining
possible how-to's. If the desired functionality doesn't impact the
application and is of no value to the user, one can only question the
need for that functionality. Unnecessary complications should be
avoided.
Quite frankly displaying the name of a method which is about to be
invoked to the user does appear to be an unneccessary complication.
This becomes especially true if overloaded methods and anonymous
delegates are involved.
Don't take this personally but the "I thought of it" doesn't provide
the 'it' with any real value.
regards
A.G.
J
J.B. Moreno
proxyuser said:
The name property can be changed at run time -- it can even be changed
outside of the designer before compiling. Never rely upon the name
property being the same as the variable name.
Such responses indicate one of three things:
1) You have either failed to adequately explain what the real
problem you are trying to solve is (and not just the method you've
chosen to solve the problem).
2) You don't need to do that.
3) Your reader is unable to understand how to apply what you want to
do to solve your problem (this is just a variation on 1 but putting the
onus on the reader).
Now, on to your actual question. I haven't done it in practice, but I
believe that theoretically this is at least a *partly solvable problem.
1. Do not call the method directly, instead create a delegate and
call it using the delegate.
2. Use instance.GetType.GetMethods() to create a collection of
MethodInfo's
3. Use Delegate.CreateDelegate to create a delegate for each of the
methodsinfo's created inst step 2.
4. Use Delegate.Equals to compare the delegate created in step 1, to
the ones created in step 3. Then use the associated MethodInfo.Name.
5. Bob's your uncle.
*I said partly solvable because I for see problems with methods that
have more than one parameter.
J
J.B. Moreno
proxyuser said:
The name property can be changed at run time -- it can even be changed
outside of the designer before compiling. Never rely upon the name
property being the same as the variable name.
Such responses indicate one of three things:
1) You have either failed to adequately explain what the real
problem you are trying to solve is (and not just the method you've
chosen to solve the problem).
2) You don't need to do that.
3) Your reader is unable to understand how to apply what you want to
do to solve your problem (this is just a variation on 1 but putting the
onus on the reader).
Now, on to your actual question. I haven't done it in practice, but I
believe that theoretically this is at least a *partly solvable problem.
1. Do not call the method directly, instead create a delegate and
call it using the delegate.
2. Use instance.GetType.GetMethods() to create a collection of
MethodInfo's
3. Use Delegate.CreateDelegate to create a delegate for each of the
methodsinfo's created inst step 2.
4. Use Delegate.Equals to compare the delegate created in step 1, to
the ones created in step 3. Then use the associated MethodInfo.Name.
5. Bob's your uncle.
*I said partly solvable because I for see problems with methods that
have more than one parameter.
P
proxyuser
Registered User said:
Why does it need to have any value? Just look at it as a theoretical
question so I can understand the language better. If you prefer not to
answer any questions for which you don't see any value, then just exercise
that prerogative.
P
proxyuser
J.B. Moreno said:
I really don't see why it matters. Just assume the real problem I'm trying
to solve is getting a method name from a method programmatically and go from
there. I know people are trying to help when they ask "why do you need
that", but as you can imagine it can get rather tedious over the years on
forums where you have to waste time arguing about something that just gets
in the way. You and I both know there are people who would rather spend
energy telling someone what they should or shouldn't do rather than spending
the energy on an answer, or even just not cluttering up the thread to begin
with.
Off the top of my head I don't see what the problems would be with more than
one parameter - it seems like that would work. That's an idea that
definitely did not occur to me - see, that's why these newsgroups are so
good
J
J.B. Moreno
-snip need to explain real problem-
It matters for several reasons, possibly the least important is
motivation for people to put effort into solving your problem even if
they don't know the answer right off hand.
Another point. By definition, since you're asking the question, the
people that can best answer it know more about that particular area of
programming than you do, if they think that they need additional
information...
As for getting tired of it, just include it as a matter of course if
the question seems weird. Which this one certainly is, as the normal
method would be to do whatever you ned to do inside the method itself.
The problem with more than one parameter is that the delegates are
unlikely to evaluate to equal with a different parameter list.
OTOH, I'm not sure what the output of Delegate.ToString is, and on
second thought that seems much more straightforward and reliable if it
does the obvious (output the method name/signature).
It matters for several reasons, possibly the least important is
motivation for people to put effort into solving your problem even if
they don't know the answer right off hand.
Another point. By definition, since you're asking the question, the
people that can best answer it know more about that particular area of
programming than you do, if they think that they need additional
information...
As for getting tired of it, just include it as a matter of course if
the question seems weird. Which this one certainly is, as the normal
method would be to do whatever you ned to do inside the method itself.
Off the top of my head I don't see what the problems would be with more than
one parameter - it seems like that would work. That's an idea that
definitely did not occur to me - see, that's why these newsgroups are so
good
The problem with more than one parameter is that the delegates are
unlikely to evaluate to equal with a different parameter list.
OTOH, I'm not sure what the output of Delegate.ToString is, and on
second thought that seems much more straightforward and reliable if it
does the obvious (output the method name/signature).