.NET interfaces in LabVIEW - Problem with overloading

[wjousts]

I'm using LabVIEW 7.1 and I've noticed an odd problem with how it is handling .NET Interfaces. In particular, if I have a .NET class which has an overloaded method (method with the same name but different parameters), then the method shows up in LabVIEW as MyMethod, MyMethod[1], MyMethod[2], etc where the [1] and [2] indicate the overloaded versions of MyMethod. This isn't pretty (in particular you can't see which method is which unless you select them one by one until you find the right one) but it works.
The problem however is when I use an interface which has an overloaded method. I have an interface, let's call it IMyInterface which has a method MyMethod(int a) and an overloaded version MyMethod(int a, int b). The problem is in LabVIEW both of these methods are showing up as MyMethod, not MyMethod and MyMethod[1]. That's purely cosmetic, but the real problem is if I select the second overload (the one with two parameters) it appears in the invoke with the first parameter, labeled as a, but with second one is labeled just "parameter". Wiring anything to this terminal doesn't work as it doesn't seem to get passed to b causing a .NET exception.
Does anybody have any idea what might be going on here? Is there a way around this.

Thanks

WJ

[Lycangeek]

I'm afraid this was a bug that was discovered and fixed in the 8.x versions. The good news is that not only is the problem fixed, but we display the method overloads with their signatures (list of parameters) rather than [1], [2], etc. (although that option is available under "short names"). The only solution I can think of besides upgrading is to create a wrapper assembly to issue the call for you, and then call the wrapper from LabVIEW.

[wjousts]

Thanks for the info Brian. It's good to know it's not just me, and it's even better to know that this has been fixed (and I can see the function signatures too).

We're working with an outside company who are using LabVIEW 7.1 and don't want to upgrade the whole project to 8.20 at this stage (we're nearly finished - at last!). I had changed my .NET dll to support a new feature and I'd hoped to maintain backwards compatibility with early versions of the software. It's really not that much of a problem just to lose the old version of the method in the interface. I just have to remember not to try and drop the new version of the dll into the old version of the software.