LabVIEW
Coercion Dot appears if enum is changed to type def
Solved!
Hello All,
In one of my application I'm using Library Function node. I'm using Enum Control to Pass Value to the Node as shown in the below Image. As can be seen there's no Coercion Dot.
If i convert the same enum to type def Coercion Dot appears as shown below.
Can anyone tell me why is this happening ??
A typedefed enum is always only compatible to itself without any conversion operation. If you have two different typedefs whose enum entries are exactly the same you still will get a conversion dot. In the first case your enum is really just a glorified unsigned int32 and hence there is no conversion needed. The second case has to " convert" between the typedef and the generic unsigned integer of the Call Library Node terminal. You could configure the Call Library Node parameter to Adapt to type but that has two major consequences:
1) The Adapt to Type will pass the scalar by reference, so your DLL needs to be programmed like that.
2) A LabVIEW programmer who gets later tasked to modify your application, could break the Call Library Node runtime behavior by inadvertently changing the numeric datatype of the enum in a way that is incompatible to what the DLL function was programmed for and therefore cause memory corruptions or application crashes.
Therefore it is usually safer to stick to specific datatypes in the Call Library Node configuration unless the DLL is tied tightly to LabVIEW anyways and will generally require a careful review of both the interface VIs containing the Call Library Nodes and the DLL source code together.
So the conversion dot can mean really two things in LabVIEW. Either you have a numeric datatype difference or a typedef difference between source and sink. For scalars conversion dots should be reviewed but are no problem if you determined that they are valid. For arrays, especially big ones, you should always investigate if there are ways to avoid them.
