invoking methods

  • Thread starter Thread starter JB
  • Start date Start date
J

JB

In general, when writing vb code a method is called by adding the name of the
method at the relevant point in the code

Private Sub Sub1()
...
...
Sub2()
...

End Sub

Private Sub Sub2
....
End Sub

My question is whether or not there is a way of doing the same thing except
that the name of the sub is a string or put another way, the method to be
called is not know until runtime. Somthing like

Private Sub Sub3
...
Exec( "Sub2")
...
End Sub

I use reflection to create classes at runtime based on a string name using
GetType and Activator.CreateInstance. It there something equivalent for
invoking a method when the name isn't know until runtime?
 
JB said:
In general, when writing vb code a method is called by adding the name of the
method at the relevant point in the code

Private Sub Sub1()
...
...
Sub2()
...

End Sub

Private Sub Sub2
....
End Sub

My question is whether or not there is a way of doing the same thing except
that the name of the sub is a string or put another way, the method to be
called is not know until runtime. Somthing like

Private Sub Sub3
...
Exec( "Sub2")
...
End Sub

I use reflection to create classes at runtime based on a string name using
GetType and Activator.CreateInstance. It there something equivalent for
invoking a method when the name isn't know until runtime?


Where do you get the name from at runtime? If it's stored inside your
application, Reflection is very rarely the way to go. Otherwise, for
example if it's stored in a database, it's (AFAIK) the only way. You
know that the compiler can't check the name and late binding is very slow.



Armin
 
As it seems to often be the case, I came across the answer to my question 5
minutes after I made the post and this after a couple of hours digging
through the online help. The invokeMethod of the type class in reflection
will do what I want(I think.) As far as why, it is because I have many(lots)
of derived classes whose identity is based on a parameter returned from a
database. In some cases, these classes need to call a shared method in a
module that is specific to the class. The methods are in the module because
they also need to be called by other classes. Anyway, the options are to use
a switch statement based of the relevant parameter or to construct the method
name from the class name eg. AddNewRecord_+ "Class name" The problem with
the switch statement is that I have to add a new case statement each time a
new class is added which is both tedious and error prone.

As far as the execution speed, I think that is a complete non issue!! It may
be slow in terms of cpu cycles but it is more or less instantaneous in human
preception. I use reflection extensively to open forms from a dynamically
created menu based on a names derived from a database the I will assure you
that there is NO preceptual delay.
 
JB said:
As it seems to often be the case, I came across the answer to my question 5
minutes after I made the post and this after a couple of hours digging
through the online help. The invokeMethod of the type class in reflection
will do what I want(I think.) As far as why, it is because I have many(lots)
of derived classes whose identity is based on a parameter returned from a
database. In some cases, these classes need to call a shared method in a
module that is specific to the class. The methods are in the module because
they also need to be called by other classes. Anyway, the options are to use
a switch statement based of the relevant parameter or to construct the method
name from the class name eg. AddNewRecord_+ "Class name" The problem with
the switch statement is that I have to add a new case statement each time a
new class is added which is both tedious and error prone.

As far as the execution speed, I think that is a complete non issue!! It may
be slow in terms of cpu cycles but it is more or less instantaneous in human
preception. I use reflection extensively to open forms from a dynamically
created menu based on a names derived from a database the I will assure you
that there is NO preceptual delay.

Ok.


Armin
 
Reflection's performance has come a long way since v1.0, not least for the
fact that it's used a lot more extensively in the 3.5 extensions to the
framework. I will however say this - resorting to a reflection-based
solution to call common methods with names like "MethodName" + class-name is
a pattern I'd recommend against. You're introducing the potential for
subtle bugs, debugging nightmares, and poor maintainability in the long run.
You'd be better off re-examining your class hierarchy and inheritance
architecture IMO and looking for a more solid, design-time solution.
 
Back
Top