Utilities.CallByName to invoke method?

david.wendelken posted on Monday, April 23, 2007

C#

I've gotten the Utilities.CallByName to work for calling properties on an object, but I haven't been able to get it to work as expected for invoking methods.

This works like a charm to get a property out of an object:

Object o = Utilities.CallByName(target, ee.PropertyList.ToString(), CallType.Get);

So, I tried a similar approach to invoke a method that was defined in my Business Object:

Object o = Utilities.CallByName(businessObjectType, "MyMethod", CallType.Method, "MyParamValue");

Worked fine.  So, since every business object needs the same routine, I moved it to my copy of BusinessBase, which is what my business object subclasses. 

Surprise!  It does not find the method!

What gives?

RockfordLhotka replied on Monday, April 23, 2007

If you look at the code you'll see a very simplistic implementation of calling a method.

If you then look at the MethodCaller class used by the data portal you'll see what really has to be done to call a method - handling parameter overloads, virtual methods, generics, etc.

It gives one great appreciation for the work the VB team did in writing the real CallByName() method for the VB runtime...

What I'm getting at, is that you'll need to replicate code more like MethodCaller than like Utilities.CallByMethod to get the results I imagine you are looking for.

Alternately you could do what I personally think more people should do, and just use the VB runtime. It is this really cool library of highly tested functionality, just sitting there waiting to be used. It is the kind of thing people pay hundreds of dollars for when they buy that sort of thing from a 3rd party vendor, just free for the taking.

I didn't (couldn't) use the runtime in the C# CSLA project, because there are too many purists out there who'd have cried foul - even though the resulting code would have been more complete and far better tested than my partial ports... Just like with religion, "purity" often trumps any sort of rationality when it comes to these sorts of things.

david.wendelken replied on Monday, April 23, 2007

RockfordLhotka:

...Alternately you could do what I personally think more people should do, and just use the VB runtime. It is this really cool library of highly tested functionality, just sitting there waiting to be used. It is the kind of thing people pay hundreds of dollars for when they buy that sort of thing from a 3rd party vendor, just free for the taking.

I didn't (couldn't) use the runtime in the C# CSLA project, because there are too many purists out there who'd have cried foul - even though the resulting code would have been more complete and far better tested than my partial ports... Just like with religion, "purity" often trumps any sort of rationality when it comes to these sorts of things.

I'm a pragmatist.  :)   Thanks for the tip!

david.wendelken replied on Tuesday, April 24, 2007

Well, darn.

The Microsoft.VisualBasic.Interaction.CallByName executed correctly (it found the base class method), but it produced unwanted results. :(

I was hoping that a method in a base class would use the Resources file that belongs to the sub-class assembly, not the base class assembly.  No such luck.

 

RockfordLhotka replied on Tuesday, April 24, 2007

david.wendelken replied on Tuesday, April 24, 2007

RockfordLhotka:

If you make that method abstract so it must be overridden by the subclass then you’d get the result you want, because the executing code would be from the subclass.

Right now, the method is a static one, and I can't do that with static methods. 

I'm looking into making the method non-static.

Who ever said that one can't put static methods in an interface or override them in sub-classes was being silly.  More religion, I suspect.