<file multiple="true"> in CLI to select multiple files in GUI

Dear all,

In CLI xml file, although the tag support multiple files in the command line calling of the CLI module, in the GUI, the file selection dialog box does not allow selection of multiple files (using, say, shift or ctrl keys). I read this notice on wiki:


Limitation: the automatically built GUI will not support selecting multiple volumes for the image and pointfile argument, but they can be passed on the command line.

Could I know if there is a solution to do multiple file selection in GUI?


Hi Yi -

Thanks for the report - I don’t think anyone has looked at that code in a while. I’m sure you remember the old days when Jim and Bill were adding this functionality to slicer3 and there was a lot of activity (ahh, the old days…). It’s possible that when this feature was ported to Qt for slicer4 this feature was missed. If it’s in your critical path it should be possible to track down and add this option to the dialog. The limitation you cite is for the mrml node combo boxes, but the file dialogs should be workable.


The feature could be added for both node and file selectors. For file selectors it would be probably pretty easy (just enable multi-select in a standard file dialog). For node selectors we could use qMRMLCheckableNodeComboBox or qMRMLSubjectHierarchyTreeView - they both support multi-select.

Hi Steve, Hi Andras,

The CLI “file multiple” corresponds to a ctkPathLineEdit. In the ctkPathLineEdit.cpp line 651, it opens a QFileDialog through a static function getOpenFileName(), which returns a QString.

However, the static function version getOpenFileNames() (with an “s” at the end) opens multiple files returns a QStringList.

According to

The same CLI xml tag may return a std::string or a std::vectorstd::string, depending on the “multiple” switch.

I guess changing this may affect several places that uses this CLI mechanism.

Please advice a direction and i can try work on this.


Hi @gaoyi.cn - I think it’s worth getting this fixed, but I agree there may be some side effects. We could spot-check the CLIs in the core and some extensions to see if this would be a breaking change. At first thought I don’t think it’s likely to be a big problem.

File input and output is rarely used (as inputs and outputs are usually nodes or simple parameter values). Where files were used as input/output it was always just a single file (there is no CLI in Slicer that uses file multiple="true"). So, it is unlikely that adding support for multiple input/output files would cause a problem anywhere.