From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
07-30-2020 09:59 AM
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.
Solved! Go to Solution.
07-30-2020 11:03 AM
@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.
07-30-2020 12:10 PM
@billko wrote:
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 definitely could. Unfortunately, I'm trying to debug some code snippets that are causing issues on a few of our servers; the issue appears to be linked to this WIN API call, so I'm trying to use the call to narrow down the problem.
07-30-2020 04:32 PM
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.
07-31-2020 03:41 AM - edited 07-31-2020 03:43 AM
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.
07-31-2020 04:06 AM - edited 07-31-2020 04:07 AM
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).
07-31-2020 09:36 AM
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!!!
07-31-2020 10:04 AM
@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.