Rif.: MultiFileSelectPopup

[MajklS]

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

[RobertoBozzolo]

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.

[MajklS]

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.

[RobertoBozzolo]

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)?

[MajklS]

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.

[RobertoBozzolo]

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).

[MajklS]

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

[RobertoBozzolo · Accepted solution]

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.

[MajklS]

Got it, thanks for the reply, uninstalled everything and back again and it's working now.
I won't install 2020 anymore 🙂