Casting problems with VI To .NET Object

[TylerDurden]

Hi everyone,

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.

Inserting an explicit conversion to a System.Object by "To More Generic Class" don't work either. Has anyone ideas about this?

Thanks in advance.

Andreas

[Norbert_B]

Andreas,

this is expected behavior as the "To .NET Object" function has an variant input in order to work for any LV data type.

Essentially, this VI checks the actual data type in the variant, creates a fitting .NET object (retaining that class) and transfers the data to this .NET object.

Because the .NET object wire exits the VI (containing any type of data!), the .NET reference wire has to be the common ancestor for all data types: Object.

You have to convert the specific object reference (e.g. STRING) to object best using .NET calls.

Norbert

[TylerDurden]

Hi Norbert,

Thank you for your fast reply. I fully understand the situation. But can you give me a hint how to do this with LabVIEW wires?

In .NET it is very easy. But how to do this in LabVIEW wires, because I don't have the = operator and System.Object has no methods to set or get a value.

I have attached a snippet from Visual Studio which shows that variable A is still an object, even if it has the same data as S. For LabVIEW the wire is System.Object but the data behind the wire is System.String which throws the exception in the following methods. I think the problem is now that I have no idea how to cast this to System.Object (Really!) with .NET calls without handling each datatype separatly.

Thanks.

Andreas

[Norbert_B]

Andreas,

there is a Convert class in the System class providing a "ChangeType" method. A short google search on it gives many forums threads where this method was marked as solution.

See here the MSDN documentation.

Norbert

EDIT: Possibly, if you already handle the object as a specific data type (e.g. double), the TryParse method could be another way for casting datat types.

[TylerDurden]

Hi Norbert,

thank you very much for your reply. We already checked this methods. When you execute this in LabVIEW you will see that the type of the object you get is an Int32 in this example. The type of the wire is System.Object, you see this if you make a right click on the wire and select Create Method. If you have an explizit System.Int32 you will see the explicit methods for the System.Int32 class. I think the problem is the different representation between the wire (System.Object) and the data in it (System.Int32). I'm not really the .NET developer, but I think this is the problem why my following .NET APIs are throwing errors because the explicitly want a System.Object which LabVIEW provides at Design Time (Wire Type = System.Object / No coercion dot, no broken wires) while at Run-Time the data in the wire is a System.Int32.

Maybe I'm getting a complete false view of the situation, but right now I don't see any other possibilties, or?

I have attached a current screenshot of my Test VI, maybe I'm doing something wrong, If so please tell me.

Thanks in advance.

Andreas

[Norbert_B]

Andreas,

i share your expectation on how LV works here and why the error occurs.

Looking at your screenshot, i would expect probe 1 to be Int32 during runtime, but probe 2 and 3 should be "Object".

Can you please attach the VI?

thanks,
Norbert

PS: I know this is *unwanted* but as a workaround, you can develop a smaller wrapper assembly which accepts specific data types and cast them to "object". I am curious if LV keeps "object" once you pass a cast reference back from .NET.

[TylerDurden]

Hi Norbert,

You expectation about the probes is correct. I have attached the VI as well as you proposal for the workaround. LV casts the type back to a System.Int32, even if you definitly return a System.Object.

Andreas

[Norbert_B]

Are you sure that your small assembly function really does a cast to "Object"?

I was thinking about moving the TYPE CAST (Convert) into a .NET assembly....

Norbert

[TylerDurden]

Hi Norbert,

I've changed the code in the assembly to

    public static object Test(object O)
    {
      return Convert.ChangeType(O, TypeCode.Object);
    }

which shows the same behaviour. I think the issue (problem or wanted operation) is in the output of the Invoke Node where the System.Object value is passed into LabVIEW.

I've attached the new version of the assembly.

Andreas

[Norbert_B]

Andreas,

i haven't found any information that a System.Object does NOT retain its type internally. To be more specific: Each System.Object has a field "Type" which contains information about the data type encapsulated as "Object". At least, it seems that all System.Object keep that information.

When relying on LV about that information, using the constructor for a generic System.Object states in the LV probe "Object" as type.

Once calling "GetType", the result is a System.Object again. But this time, the probe states "RuntimeType" as type.....

It seems to me, that essentially every System.Object keeps information on its data type. Only if no data is contained, it states "Object" as type.

I am wondering, if it is a limitation we see on LV and its probes, or if this is expected behavior in .NET overall.......

Norbert

EDIT: What you can try to do is: Create a constant for the inital method (SqlParameterCollection) parameter "value". Check the .NET class of this constant. Try to use "To More Specific Class" using this constant as 'target'.