LabVIEW
using labview.dll in LV7.1
Ben wrote:Take the following with a grain of salt because I did not know that I would be tested on the question.
I think I read Rolf post about changes that preveted us to get at the function in the core. You may be seeing this change.
Ben
I'm not sure what you refer to, but in respect to the access of the LabVIEW manager functions you clearly misunderstood something. I never would have said that you can't get at those functions anymore. In fact it is by now a semi documented way since several posts here from NI people clearly pointed that possibility out and i have seen at least one LabVIEW knowledgebase or similar NI example using that feature without being password locked.
If you have an exception occurred error it is not the "LabVIEW" library name that does not work. If it would be that you would get an error at the moment you close the configuration dialog, saying that the shared library you have entered could not be found.
An exception is caused when you get something wrong with the parameters of the functions. The possible list of wrong doings in this aspect is long. Usually it is either that you got something wrong with pointers such that you pass in a variable by value but it is expected to be by reference or vice versa, or that you pass in a certain type of pointer while the function expects something else, or that you pass in a pointer to a buffer that is to small for the function to write in what it needs.
The first types of errors can be solved by carefully reading the function documentation and comparing all Call Library Node configurations carefully with the according function documentation. The last one is the typical error of most newby C programmer in general and LabVIEW programmers diving into the realms of the Call Library Node.
For a C function to return data such as an array or a string, the caller normally has to allocate the entire buffer before calling the function. A C function has no means to (re)allocate a passed in buffer if it is to small, in fact it can't even see how large the buffer is if the function itself doesn't provide for the extra parameter to pass in the size of the allocated buffer. This is so totally different to how LabVIEW works in its diagram programming that 99% of the LabVIEW programmers going into the Call Library Node depths stumble over this problem in one way or the other. But the only way LabVIEW could prevent people from running into this, would be to remove the Call Library Node althogether, preventing calls to external code
And no to prevent your objection that it worked in LabVIEW 8, forget this. If you happen to pass in a to small buffer the function will write over the end of that buffer. By doing so it will overwrite some memory location which can but does not always have to contain vital information for LabVIEW. By doing so you can create various situations ranging from worst to best:
- nothing happens (this sounds nice but is a sure time bomb, since as soon as you make some changes to the code one of the other cases can happen, and recompiling a VI to be loaded in a different version is a change to the code).
- the function overwrites memory that happens to be part of a loaded VI, if you happen to write back that VI later, it could crash or simply write a corrupted VI to disk.
- the function overwrites memory that happens to contain data in some wire, you get suddenly weird and unexplained results in your application since the data in the wires changes magically.
- the function overwrites memorey that conatians references to LabVIEW internal or other objects that will crash LabVIEW sometimes after the function was executed, at latest when you close down LabVIEW and it attempts to properly clean up everything, stumbling over those destroyed references.
- and last but not least the function overwrites memory that does not belong to the LabVIEW process, since the logical memory allocation hasn't been assigned past the end of the buffer to the process and you get an immediate access violation
