LabVIEW
Missing external function in third party .dll
Solved!
There was some change in how errors get reported in one of the more recent LabVIEW versions, but the messages in the error dialog are the same when the loading of the DLL fails because dependencies can't be resolved.
@rolfk wrote:
There was some change in how errors get reported in one of the more recent LabVIEW versions, but the messages in the error dialog are the same when the loading of the DLL fails because dependencies can't be resolved.
Sad to hear it changed, as the messages are quite cryptic. Recollection of a message from prior experience was pretty much the only way to know what was going on (or not going on).
I wander if there's more information when you press the run button. IIRC, This used to give just a tiny bit more to go on.
Search LabVIEW like a graph!
wiebe@CARYA wrote:
@rolfk wrote:
There was some change in how errors get reported in one of the more recent LabVIEW versions, but the messages in the error dialog are the same when the loading of the DLL fails because dependencies can't be resolved.
Sad to hear it changed, as the messages are quite cryptic. Recollection of a message from prior experience was pretty much the only way to know what was going on (or not going on).
I wander if there's more information when you press the run button. IIRC, This used to give just a tiny bit more to go on.
Not sure what you mean. Since the loading of the DLL failed (and therefore the linking to the individual functions in that unloaded DLL) the run arrow is broken and you can't run anything. I would guess you simply get the same error list dialog again when you click the (broken) run button. As to if it is more or less useful than before that is definitely debatable. Before it simply told you that a specific DLL couldn't be loaded because it or one of its dependencies couldn't be found, now it gives you a list with an entry for each Call Library Node import with the <shared ;ibrary name>:<function name> that it couldn't find. General notion would be if there is one or a few imports that it couldn't link to then the DLL probably is present but might be a different version that doesn't export those specific functions, but if you get a ton of error messages for the same shared library (or at least an error for every Call Library Node for a specific shared library), something with the shared library itself is amiss.
@rolfk wrote:
wiebe@CARYA wrote:
@rolfk wrote:
There was some change in how errors get reported in one of the more recent LabVIEW versions, but the messages in the error dialog are the same when the loading of the DLL fails because dependencies can't be resolved.
Sad to hear it changed, as the messages are quite cryptic. Recollection of a message from prior experience was pretty much the only way to know what was going on (or not going on).
I wander if there's more information when you press the run button. IIRC, This used to give just a tiny bit more to go on.
Not sure what you mean. Since the loading of the DLL failed (and therefore the linking to the individual functions in that unloaded DLL) the run arrow is broken and you can't run anything. I would guess you simply get the same error list dialog again when you click the (broken) run button. As to if it is more or less useful than before that is definitely debatable. Before it simply told you that a specific DLL couldn't be loaded because it or one of its dependencies couldn't be found, now it gives you a list with an entry for each Call Library Node import with the <shared ;ibrary name>:<function name> that it couldn't find.
In the past, you'd get a general error popup when the exe loaded, and when pressing the broken run dialog, you would get more details on the exact VIs that where broken. It didn't used to be the same dialog. The run button used to specify exactly which VIs caused the main to be broken.
As it seems to be now, pressing the broken run button might not add anything.
To me, there's a difference between dll couldn't load (wrong bitness, path not found, etc.) and function not found (wrong version)... If that became the same message, there is a loss of information.
Anyway, I think we need to see actual code, dlls and exes. Something completely different might be wrong here. For instance, perhaps the CFNL has an external path specifier?
