One of the problems with using DotNet in C/AL is that sometimes the C/AL compiled does not have enough information for select between different methods in the DotNet object.
As you might have gathered from my last posts, I am using DotNet more and more. It saves a lot of code writing and it is fast.
Today I was handling a web service that is delivering decimal value formatted with the is-IS method. The decimal character is a comma. I wanted to make sure that my C/AL code would be able to handle that no matter what the underlying language or region settings where.
Getting the decimal value was pretty straight forward. Just used the method Microsoft uses in Codeunit 10 with a predefined is-IS. Now for the other way around. Found a method for the System.String to format a decimal to a text based on the same is-IS.
But here comes the problem.
Ok, Vjeko sais everything can be solved with reflection – well perhaps not everything, but this problem sure can.
I listed all the methods for the System.String and found the one I wanted to use. Did not have to use the System.Activator since this is a static class.
Yes, a few more lines but they are effective and there is always fun to get challanged. So, if you ever get this error message again, reflection should be able to solve the problem.
here is the ISLFormatAndEvaluate code to download.
Be careful when selecting the correct method. The index, in this case 8, is note guaranteed
This is an excellent example and I was able to use this and iterate through the list of Methods in an object that I was having this very problem with. When I finally found the correct method ID & used the invoke with what I thought were the correct parameters, I got an much more meaningful error that indicated the expected parameter was of type XML Node instead of String.
When I changed the variable in my original code from string to XML Node everything compiled and the “The function cal was ambiguous” error went away.
Hello Gunnar, i’m experiencing the ambiguous call in NAV 2009 R2. While i was tring to apply your solution i discovered that GETDOTNETTYPE was not defined in this NAV version. Do you have any suggestion for this situation? Thank in advance
Hello Gunnar, i’m using NAV 2009 R2 and GETDOTNETTYPE is not defined in this version. Do you have any idea/suggestion about this?
Before GETDOTNETTYPE C/AL function we used.GetType to get the type.