Misleading function help of MultiFileSelectPopup

[Wolfgang]

Hello NI,

when viewing the function help for the Selection Status of the MultiFileSelectPopup I was a bit surprised to see the VAL_NEW_FILE_SELECTED value: I am not aware of a possibility to choose a new file in the MultiFileSelectPopup...

Did I miss this possibility or is it a bug in the documentation (using CVI10.0) ?

---

The selection status or error codes generated during the function call.

0	VAL_NO_FILE_SELECTED
1	VAL_EXISTING_FILE_SELECTED
2	VAL_NEW_FILE_SELECTED

Negative values indicate that an error occurred.

[D_Biel · Accepted solution]

Wolfgang,

You are correct, there is no way to receive a return value of VAL_NEW_FILE_SELECTED. The reason that value is available is because it uses the same enumeration as FileSelectPopup where that is a valid value (save or ok button type). I will look into removing this from the documentation.

[Wolfgang]

Thanks

[Wolfgang]

Hi Darren,

The good news: in CVI 2012 the help has indeed been fixed - for the original function.

Unfortunately, the guy correcting the text did not talk to the guy writing / copying the help file of the new function MultiFileSelectPopupEx (don't tell me it's been you in both cases )

MultiFileSelectPopup

selectionStatus

integer

The selection status or error codes generated during the function call. 0 VAL_NO_FILE_SELECTED 1 VAL_EXISTING_FILE_SELECTED

MultiFileSelectPopupEx

selectionStatus

integer

The selection status or error codes generated during the function call. 0 VAL_NO_FILE_SELECTED 1 VAL_EXISTING_FILE_SELECTED 2 VAL_NEW_FILE_SELECTED

So I'll keep my tag for this post until CVI2013...

[D_Biel]

Ah, good catch, but we did actually consider both functions. In MultiFileSelectPopupEx, VAL_NEW_FILE_SELECTED is actually a valid return value. Try running the MultiFileSelectPopupEx function and type in a new file name rather than selecting an existing file. 

[Wolfgang]

Hi Darren,

oops, sorry for my premature comment

But that's an interesting addition... so it's not only a new graphical design of the popup, but also functionality has changed, that's good to learn!

Now that I am embarrassed anyway I can continue asking...: Is there any application one could use this new feature for? At first sight, it seems a bit illogical to me - in my application at least. I have a menu to open one data file and another menu to open several data files simultaneously, for the latter I used MultiFileSelectPopup. Now, with the new, modern function a user can create a file instead of opening one... (starting from my File / Open ... menu this is not logical...)

[Kevin_B.]

MultiFileSelectPopupEx doesn't actually create a new file, the developer has to add that functionality if they want users to be able to do it. It's not too hard to think of a hypothetical application where normally one or more files will be selected, but the user might want to specify a new file or some existing files and a new file, etc. As long as the code which handles fileList checks the filenames returned then there should be no problems. We made the decision not to limit user functionality even though it's not a very common use case.

Note: There is one really minor hidden limitation that Windows imposes on the MultiFileSelectPopupEx dialog. You can specify "existing1.c" "existing2.c" "newfile.c" or  "existing1.c" "newfile.c" "existing2.c" and everything will work fine. However, if you try to return "newfile.c" "existing1.c" "existing2.c" the dialog will notify you that newfile.c does not exist and refuse to exist the dialog until you make it not the first item in the list. Strangely, attempting to return either "newfile.c" or "newfile.c" "newfile2.c" is perfectly okay. It seems that Windows just really wants an existing file to be first in the list if you're going to specify one.

[Wolfgang]

Hi Kevin,

thanks for the extra explanation, at least I understand now why this selection status of 2 is not available for the single file popup...

What I find confusing is the following scenario on Windows 7: Specifying "existing1.c" "existing2.c" "newfile.c" yields a selection status of 2 - although two existing files have been selected... (existing files would have translated to selection status of 1)

So '2' means that at least one non-existing file has been specified, as a warning to the programmer that I cannot simply proceed and open all the selected files as in the past... Much extra effort is required just to eliminate this very exotic case - or did I get it wrong?

In my current understanding the new (well, for CVI) optics comes at a price that I would consider too high.

What I would like to have is the new popup graphics appearance but without the 'feature' to add a non-existing file

So it is not possible at all to simply replace the old with the new function...

Please tell me that I am wrong...

[Kevin_B.]

It's not really all that much effort. Let's assume that in your case you would prefer to skip non-existing files. You can check for a status of 2 and if you get that, just display a popup to the user saying they must select an existing file and recall the function, or you can do something like the following: 

for (i=0; i<numFiles; ++i) {

  exists = GetFileInfo(fileList[i],&size); // returns 0 if the file does not exist
  if (exists != 0)

    // open fileList[i] or whatever you want to do with it here

  else

    // you can create the file here, or just skip over it if you want.

  free (fileList [i]);
  fileList [i] = NULL;

}

That shouldn't be all the different from the standard post-MultiFileSelectPopup handling you're already doing. Unfortunately there's no way to prevent the user from returning files that don't currently exist.