I'm using a custom .Net api on a current project, and for reasons that are too lengthy to explain I've resorted to using a typecast to change a .Net reference wire from one .Net object type to a different, but similar .Net object type. (Property nodes have similar fields, but in a different order.)
It works okay while smoke testing, but I'm not very comfortable with it at all. I don't know the underlying mechanics of how LV maps property nodes to .Net accessors, leaving me wondering what kinds of failures I'm likely to see. Anyone have insight they'd like to share?
How bad is typecasting .Net references?
Started by
Daklu
, Feb 24 2012 05:31 PM
5 replies to this topic
#1
Daklu
-
- Premium Member
-
- 1,752 posts
Bringing the Fu to you
- Location:Seattle
- Version:LabVIEW 2009
- Since:2006
Posted 24 February 2012 - 05:31 PM
Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.
Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.
There are two secrets to success:
Secret #1 - Never tell everything you know.
#2
asbo
-
- V I Engineering, Inc.
-
- 1,273 posts
I have no idea what you're talking about... so:
- Version:LabVIEW 2011
- Since:2008
Posted 24 February 2012 - 07:29 PM
I'm surprised that it even works at all, since the properties are in a different order. I take that to mean LV maps its property nodes in a somewhat intelligent way, but for speed's sake, I hope it's not via reflection... My expectation would be access violations, or corrupted data at the very least. You are both reading and writing?
#3
Daklu
-
- Premium Member
-
- 1,752 posts
Bringing the Fu to you
- Location:Seattle
- Version:LabVIEW 2009
- Since:2006
Posted 24 February 2012 - 10:08 PM
Yep, reading and writing.
Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.
Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.
There are two secrets to success:
Secret #1 - Never tell everything you know.
#4
mje
-
- Premium Member
-
- 813 posts
The 500 club
- Location:Milford MA USA
- Version:LabVIEW 2011
- Since:1997
Posted 25 February 2012 - 04:00 AM
Also surprised it works at all, my guess is if you tried calling any methods on the refnum you'd see fireworks.
I take it these objects are unrelated, so you can't do proper dynamic casts via the to more specific primitive?
I take it these objects are unrelated, so you can't do proper dynamic casts via the to more specific primitive?
#5
Daklu
-
- Premium Member
-
- 1,752 posts
Bringing the Fu to you
- Location:Seattle
- Version:LabVIEW 2009
- Since:2006
Posted 26 February 2012 - 05:26 PM
I don't really know how they are related as I don't have access to the .Net source code. If I were to guess I would say they might be siblings, but they're actually interfaces--not concrete classes--and they may not be in any sort of inheritance hierarchy.I take it these objects are unrelated, so you can't do proper dynamic casts via the to more specific primitive?
Here's a snippet showing the full property nodes before and after the typecast. Oddly, the SteppedLevelGenerator property node (before typecasting) always returns error 1172 while the FrequencySweepGenerator node (after typecasting) does not.
[Grrr... my premium membership incorrectly expired and I'm over the freebie upload quota. I'll try to upload it once I get my membership sorted out.]
Edited by Daklu, 26 February 2012 - 05:27 PM.
Certified LabVIEW Architect
Dak's First Law of Problem Solving: If the solution looks simple, I don't know enough about the problem.
Yes, the QSM is flexible. So is Jello. That doesn't make it good construction material.
There are two secrets to success:
Secret #1 - Never tell everything you know.
#6
candidus
-
- Members
-
- 63 posts
Very Active
- Version:LabVIEW 2010
- Since:2002
Posted 27 February 2012 - 11:20 AM
I don't really know how they are related as I don't have access to the .Net source code. If I were to guess I would say they might be siblings, but they're actually interfaces--not concrete classes--and they may not be in any sort of inheritance hierarchy.
You might be able to get information about their relationship without source code. Use IL disassembler (ildasm.exe) that ships with the .NET SDK.
