02-03-2023 01:27 AM
Hi, I'm having a problem with the multifileselect function using the MultiFileSelectPopup function.
The CallbackAllSlices function uses a file selection to retrieve the data and display it in a table.
The function first deletes all rows in the table and then inserts the number of rows corresponding to the number of selected files.
The problem occurs when I select many files and the program crashes and gives me an error:
NON-FATAL RUN-TIME ERROR: "TiskSestav.c", line 215, col 10, thread id 13420: Library function error (return value == -1704 [0xfffff958]).Filename is too long
I tried it on other computers and it works fine there. Why doesn't it work on my PC?
If I select more than 7 files, the program crashes, if less than 7, the program loads them.
I have a big enough variable, here is a piece of code how I load segments:
char g_cestaAdrDat[2000];
status = MultiFileSelectPopup (g_cestaAdrDat,"*.dbf","","", 0, 0, 1, &numFiles, &fileList);
Is the library damaged? I have no idea where the error is, it won't be in the code, because it works for me on another PC in LabWIndows.
Thank you for answer
Best regards
Michael
Solved! Go to Solution.
02-03-2023 02:06 AM
As you can see in the help for MultiFileSelectPopup function, the command expects a char ** NULL pointer and automatically allocates the proper memory area for it to complete. It may work by passing a finite buffer to it but it is not guaranteed. I suggest you try with the code samples provided in the function help.
02-03-2023 02:31 AM
Thank you, I also tried that but without success, I don't understand that it works for me on another PC.
I really have no idea where the error could be, I've already tried many variations.
02-03-2023 03:05 AM
Does it crash when working in the IDE or as a compiled executable as well?
Is there any difference in the file system on your machine with respect to the others where the program works (e.g. longer pathnames)?
02-03-2023 06:12 AM
It crashes in the IDE, even after creating the setup.exe as well.
I just checked it too, the path name is not different, we have server storage, so the access path is the same.
I am using version 2017 recently installed version 2020 so I have both versions. I have a feeling this could be the problem.
02-03-2023 07:09 AM
If you have installed CVI2020 you are actually using 2020 RTE; since the major variant introduced in 2020 is UTF encoding your feeling may be the right one.
According to shipping notes of 2020 release, CVI internally uses UTF-8 encoding for strings, your files list thus can be longer than you expect. Several caveats apply when transitioning to CVI2020 regarding UTF-8 conversion, and some of them are spread in help pages (e.g. this note in MAX_PATHNAME_LEN documentation about errors being returned by some functions that treat pathnames).
02-05-2023 11:25 PM
Ahaaa, thanks for the warning, so the solution is to uninstall the entire CVI and install the correct version? It's quite a problem because my programs don't work.
Thank you
02-06-2023 03:42 AM
Well, I have not yet started to extensively test CVI2020 but I had those notes in mind and I supposed they could shed some light on your problem.
The easiest solution could probably be to setup a temporary development machine with 2017 only and test how the application works. If no error arises and you want/need to switch to CVI2020 you'll have to understand how to address this problem but I'm afraid at present I cannot help you more than this.
02-06-2023 05:43 AM
Got it, thanks for the reply, uninstalled everything and back again and it's working now.
I won't install 2020 anymore 🙂