LabVIEW
FindFirstFile library call
Solved!
@AllisonSCJ wrote:
Hello,
I'm attempting to call FindFirstFileA from Labview, but my current attempts lead to crashing. I'm assuming that the definition of the cluster that I'm passing to the library call is incorrect. I attempted to recreate the call in Visual Basic and ran into the same issue; the incorrect cluster/struct definition led to an overflow.
According to Microsoft documentation here the cluster includes a parameter of type WORD. But on PInvoke, this parameter is missing. I've tried the call both with and without this input, with no success.
I'm not sure what else may be wrong with my cluster definition.
The snippet is attached below. Be warned that this code will make Labview crash unceremoniously. Leaving the structure output unwired will give an error prior to the crash, but it will crash just the same.
Have you tried doing this with native LV functions? I'm sure you can accomplish what you need pretty easily - at least based on the description of the function you are trying to use.
I'm a little confused. So if I understand you correctly, you are trying to implement this call in LabVIEW so you can play around with it and see if you can duplicate what is going wrong on your servers?
Maybe you've found it. If it didn't work in both VB .NET and LV, maybe you aren't doing anything wrong.
This is probably 32 bit, and if you have 64 bit LabVIEW, it might need adjustments.
Never mind. This is so old it won't even open.
But I'm sure this has been done before. Trick is to find it.
Search LabVIEW like a graph! Here's a quick and dirty version.
Saved back to 13...
Note the input path. "\" is an escape character, and all should probably be replaced by "\\". Haven't really tested.
Not sure why everything after the file name is missing. Someone should read the manual (but not me).
wiebe@CARYA wrote:
Here's a quick and dirty version.
Saved back to 13...
Note the input path. "\" is an escape character, and all should probably be replaced by "\\". Haven't really tested.
Not sure why everything after the file name is missing. Someone should read the manual (but not me).
Ah, I see; the WORD input is the only unsigned input based on your solution.
Not only did you give me a solution, but you also gave me a way of debugging calls with a cluster in the future by passing a byte array, thus allowing an easier way to determine where I'm going wrong with calls like this. Thank you!!!
@AllisonSCJ wrote:Ah, I see; the WORD input is the only unsigned input based on your solution.
Not only did you give me a solution, but you also gave me a way of debugging calls with a cluster in the future by passing a byte array, thus allowing an easier way to determine where I'm going wrong with calls like this. Thank you!!!
Your welcome.
Note that it does not matter if the values are signed or unsigned, except for the values.
If a dll expects an U32, you can pass it an I32. Both are 4 bytes, so there will be no crashes. Just unexpected value results. When viewed in hex display, the U32 and I32 will show the same value.
For numeric clusters, I'd deduct the cluster, and then use the cluster as a dll input. That eliminates the need for the byte, long and word swapping (changing endianness). This doesn't work with clusters with fixed length strings (or arrays), as there is no way to communicate the fixed length of the string(s). You can replace the 260 bytes of the fixed string in the cluster with 35 U64s, and convert them, but that would be messy. It works with small fixed sized strings\array though.
