LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Implicit typecast notification, or error, for strict type def

I've created several strict typedefs for my bespoke C++ DLL objects.  Unfortunately, if I incorrectly wire a reference/pointer to the wrong type, LabVIEW implicit type cast kicks in and the limited notification I get is that little dot.

 

Are there options to disable implicit typecast for my strict type defs, or to warn me?  I didn't see an option in block panel options, nor did I see it as an option in the CTL type..

 

BTW:  I know I kinda can do this with LabVIEW objects, though that's a whole lotta complexity I don't want to add to my codes.  Seems it'd be as easy for the LV Macro program to make that a broken wire than to add the dot.

0 Kudos
Message 1 of 17
(1,774 Views)

I've used strict typedef refnums for my bespoke C++ objects, casting to/from 32 bit unsigned pointers.  It helps me with readability, so that I won't confuse the reference wires with data wires and a notification dot appears if I've wired the incorrect reference type.

 

I don't remember seeing a generic/user reference, so I use an "Occurrence" refnum, just because.

 

In translating my old code to 64 bit, I haven't found a 64 bit reference that I can treat in the same fashion (cast to/from 64 bit unsigned/pointer-sized), did I just miss it?

 

If it doesn't exist, would NI add a generic/user pointer-sized refnum, castable to/from unsigned pointer-sized integer?

0 Kudos
Message 2 of 17
(1,770 Views)

Best you can do is a malleable VI, taking the value input and a type input.

 

That would probably be pointless, as you'd probably create the type input from the value input. So if you get the value wrong, the type will be wrong.

 

Normally, you'd make a VI around the API call that has validated inputs, and the types of the VI would protect from wiring something wrong.

0 Kudos
Message 3 of 17
(1,754 Views)

Hi dgholstein,

 

You can wrap your U32/U64 reference inside an LV class:

raphschru_0-1664980587367.png

 

This way it will be incompatible with regular numeric data:

raphschru_1-1664980771863.png

Find the example wrapper class attached (LV2020):

 

0 Kudos
Message 4 of 17
(1,752 Views)

I've already done that, kinda, with C++ std::lists.  My DLL keeps track of all the objects to make sure my object pointer is in the list - problem is I have to wait to runtime before finding my error.

 

What you describe sounds like the complexity of LV Objects.

 

I've grown accustomed to Visual Studio and VS Code with the squiggly lines, I believe NI LabVIEW was ahead of the curve twenty years ago with LV 7.1, but have been surpassed since then with Intellisense.

0 Kudos
Message 5 of 17
(1,743 Views)

Thanks, I was aware of that solution and had used it.  I want the simplicity of of a simple refnum.

0 Kudos
Message 6 of 17
(1,742 Views)

Then use a Data Value Reference or a 1-element Queue to store the U64 value, I cannot think of a simpler method.

0 Kudos
Message 7 of 17
(1,682 Views)

Nice.  Plus it's a property node "value" property instead of type cast.

0 Kudos
Message 8 of 17
(1,665 Views)

Not sure who merged these topics. They seem two very different questions...

 

The accepted answer solves yet another problem (and creates a few as well).  I don't really see how it's an answer to one of the questions, but maybe OP can let us know what the status of the inquiry is?

 

 

0 Kudos
Message 9 of 17
(1,601 Views)

Unfortunately, the "value reference" proposal isn't a solution.

 

I tried it out last night and it limits me to one pointer only. I use C++ objects for DB connections, XML nodes, Python modules, etcetera; I can't limit myself to one reference for each.

 

At least for the strict typedef refnums, I can do what I want.  As I said in the original post, all I want is NI to implement a generic, pointer-sized refnum. 

 

64-bit messed up a good thing for me.  I know, I know, I can create a class with the 64-bit pointer - that's way more work than what I have to do with 32-bit refnums - programming should make our lives easier, not harder.

0 Kudos
Message 10 of 17
(1,583 Views)