Typecast .NET reference in LabVIEW?

[Joe_Gerhardstein]

Well, my biggest concern is not with LV 7.1, in which this appears to work okay, but what will happen with LV 8 and beyond.  The application I am working on has a planned life span of >10 years, so we will be porting to future versions of LabVIEW as they become available.  Is the LV/.NET interop going to be rewritten for 8?  The support for .NET is significantly better in 8 than 7, so I would wonder if this will be the case.

I'm much more of a C++ programmer than C#/.NET, so the "you WILL do this now" type cast makes perfect programmatic sense to me.  I'm a novice in the "managed code" requirements that .NET imposes on LabVIEW.  So if there is a way to do this type cast within the limitations of .NET, then I'm all for finding it.

Joe

[Lycangeek]

I don't believe that the changes made in LV 8 would impact what you are doing, but I can't say beyond that.  I know that we are going to have to rearchitect it for the new technologies under the Longhorn umbrella. Also, there is a very high chance that the breaking change is going to come from the .NET runtime. The internal changes to the CLR between 1.1 and 2.0 are significant and it is only going to be more so as .NET continues to evolve. Remember that .NET is becoming the basis for Microsoft coding/applications (even the OS) so it is going to keep evolving over the next 10 years.

What you want to focus on is that the boundaries of a "type" in .NET are much thicker than in C++. In C++, you have a pointer into memory so you can always work around any boundaries put up by the compiler. In .NET, it isn't so much the compiler that is creating these boundaries as it is the runtime itself. Any hole you find in the barrier is likely to move or be closed in the future - that is the concern I have.

With that in mind, I'd like to start talking about what these two classes are and why you want to switch between them for the same data set. I'd love to help you come up with a solution that is .NET friendly. Feel free to email me (bloggingbrian@gmail.com) if you want to take this off the open airways. We can even switch to voice if you email me your phone number. Let me know if I can help.

[Joe_Gerhardstein]

Brian:

The following is from Murali Mohan, my .NET counterpart:

Here is the example of implementation used for type casting

namespace A

{
    class A
    { }
    class B inherits A

    {
        Method A
    }
}
Assume the application returns class A but the actually object reference contains class B reference.  When the user tries to access method A from class B then an error "Method not found" is thrown. So we had a bug in our code in class A constructor and made a few changes to work it right.

[Lycangeek]

Oh, this is completely different because the two classes do have more in common than being in the same namespace. If B is a child of A, then you can use the To More Generic and To More Specific - that is what they are designed for.

To make sure I understand, you have something like

A foo()

{

   return new B()

}

...

A a = foo();

So now you want to call Method A. Then you just need to use To More Specific and Bob's Your Uncle. The other big benefit over Type Cast is that if something were to change and suddenly foo() returned an instance of A, or an instance of a sibling C, then the runtime error would let you know that a problem occurred. Type Cast wouldn't tell you.

[Joe_Gerhardstein]

Well, the plot thickens.  Discussions with one of the project architects on the .NET side revealed that A and B were suppose to be the same class, not one the child of the other.  So the .NET team is undergoing some rework to fix this, which should make the whole type casting irrelevent. 

Stay tuned for the next exciting episode!

[Lycangeek]

So class A was really the secret twin of B lost in the jungles for the last 20 years, not the child of B, which would explain why they seemed to be the same age. I always knew there was something fishy about A'...

Message Edited by Lycangeek on 07-25-2005 10:40 AM