Aitor Solar Posted February 2, 2008 Report Share Posted February 2, 2008 QUOTE(rolfk @ Feb 1 2008, 08:51 AM) Well, I see. It still might be a problem in the future, or the refusal to typecast to a strict typedefed VI refnum is maybe a bug?? Na, I don't think so. Neither do I, it's done on purpose because the "to more specific class" function doesn't admit a strict VI refnum either. So it seems NI doesn't want us to modify the type of the VI refnum, probably because it's error prone or just because the Call-by-Reference function needs the VI to be reserved, etc. Anyway, I would prefer the type cast to try anything I connect, even if is not recommended. Saludos, Aitor Quote Link to comment
Rolf Kalbermatter Posted February 2, 2008 Report Share Posted February 2, 2008 QUOTE(Aitor Solar @ Feb 1 2008, 03:53 AM) Anyway, I would prefer the type cast to try anything I connect, even if is not recommended. I can only second that. It's an esoteric function enough that I would guess that people using it in such ways do know what they are doing and otherwise are prepared to live with the consequences. I don't see a LabVIEW noob even knowing that it exists , let alone using it. As my workaround for the LuaVIEW Toolkit shows, treating the refnum as a 4 byte number and copying it into the 4 bytes of a strict typedef VI refnum still works correctly. So typecasting refnums at least in LabVIEW 8.5 is still simply a datatype change but does not change anything in the underlaying memory representation. I did assume that it might have been in preparation for more significant changes to the refnum system in LabVIEW in the future, that might break with simple typecasting. But your idea that it might be more something about guaranteeing that a strict typedefed VI refnum points to something to be sure in memory might be also a good guess. Rolf Kalbermatter Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.