I need to pass a value into a .dll that I am not able to modify. The data type shows as a Nullable System.UInt32. At the Invoke Node, if I select to create a Constant or Control, then a .NET object is created. However, if I connect the output of a To .NET Object.vi to the Invoke Node, then the help screen shows Wire:Class conflict. (I tried a variety of inputs in case it was input dependent, to no avail.)
How do I convert a LV data class to be able to create a usable Control at the Invoke Node, in this case?
maybe someone of you has an idea about this. I want to convert an array of variants to an array of .NET objects. Should be no problem, I'm using the VI "To .NET Object.vi". Then I give the results to a list object and add it. Here begins the trouble. The LabVIEW wire that leaves the "To .NET Object.vi" is of the type System.Object. The next method wants a System.Object as an input parameter. Unfortunately I get the error 1172 that the method requires a System.Object and not a String.
This sounds bonkers. EVERY .Net object IS a System.Object. That is the very basic of object inheritance. So how could the function complain that it wants a System.Object when anything you can pass in (except maybe an uninitialized refnum although I would expect LabVIEW to pass a NULL reference then) is always a System.Object too. To require a pure System.Object as input parameter makes little sense as this class has no means to store any data internally. So it is at best a void variable. The data storage (and data specific methods) are implemented by the class objects that get derived from System.Object.
There must be something else going on here and the reported error from the .Net method is somehow borked.
Have you tried to remove the explicit To Variant conversion node? It is not needed and might have some strange influence.
As to the last post stating they have a similar problem, please be more specific. It may appear to you similar but could be quite different, so explain what happens and attach some VIs that show the behaviour. We are all mere mortals and have no magic crystal ball that can tell us what someone elses problems might be.
Just attaching to an existing thread and shouting "me too" doesn't sound to me like you have an important problem. If you can't take the time to explain the problem and provide some test cases to retry it on our own computers I'm not sure why I should expend the time to try to help you. Help us to help you and don't expect a ready made solution on a silver plate.
you're absolutely right - at the moment i am trying to get a permission to post the (third party) assembly together with some test-code here.
Kind regards, Pete