[Rhino6/RhinoCommon] File import plug-in does not get correct file type index for dropped file

I just noticed that when a file import plug-in has multiple file types declared, that when a file gets dropped onto Rhino the index in de ReadFile method is incorrect. When the file gets opened from the File>Open or File>Import menu, the problem does not appear.

When I drag a file with extension .dat onto Rhino when the file import plug-in (see below for code) is loaded, I get the following:

Observed output

Received index 0
TXT file

Expected output

Received index 1
DAT File

private int txtIndex, datIndex, wordIndex;

protected override Rhino.PlugIns.FileTypeList AddFileTypes(Rhino.FileIO.FileReadOptions options)
  var result = new Rhino.PlugIns.FileTypeList();
  txtIndex = result.AddFileType("Text file (*.txt)", "txt");
  datIndex = result.AddFileType("Data File (*.dat, *.plt)", "dat", "plt");
  wordIndex = result.AddFileType("Word Document (*.docx)", "docx");

  RhinoApp.WriteLine("TXT index {0}", txtIndex);
  RhinoApp.WriteLine("DAT index {0}", datIndex);
  RhinoApp.WriteLine("WORD index {0}", wordIndex);
  return result;

protected override bool ReadFile(string filename, int index, RhinoDoc doc, Rhino.FileIO.FileReadOptions options)
  bool read_success = false;

  RhinoApp.WriteLine("Received index {0}", index);

  if (index == txtIndex)
    RhinoApp.WriteLine("TXT file");
  else if (index == datIndex)
    RhinoApp.WriteLine("DAT file");
  else if (index == wordIndex)
    RhinoApp.WriteLine("WORD file");

  return read_success;

@menno - I believe this was fixed for SR11. You might download the SR11 RC and test.

Rhino 6 SR11 Release Candidate Available

– Dale

Confirmed. Thanks for clearing that up.

@dale Currently I’m running SR16, and I see this happening again - I drag a file that can be opened by one of our file import plug-ins, the code gets the incorrect index in ReadFile(string filename, int index, RhinoDoc doc, FileReadOptions options) and file loading fails. Is this a known issue/regression?

Hi @menno,

Can you provide me with some code, along with any instructions I need, to reproduce?


– Dale

I think the problem is related to the fact that we have multiple file import plug-ins and some of them have file types that have the same extension. When I create two file import plug-ins that support multiple file types, and a duplicate file extension on both of them having a different index, the incorrect index is given to the plug-in loading the file with the duplicate file extension.

Ideally, the system would track duplicate file extensions and present the user with a list of options while loading files, to choose if they want to load their file according to file type from plug-in A, or from plug-in B.

Please find attached code, compiled plug-ins and a set of files with the supported extensions.
FileImportPlugins.zip (437.4 KB) files.zip (632 Bytes)

Hi @menno,

Is this a ficticous case, or do you really have two file import plug-ins that support the same file extension? And if so, why?


– Dale

The files uploaded is a minimal reproduction case and fictional, but we do have multiple import plugins that have file types with the same extension for loading files. This is because we support a lot of file types; MARIN is a file oriented organisation where many simulation tools are developed, and extension clashes are unavoidable.

Hi @menno,

Thanks for the usable sample - I’ve logged the issue.


– Dale

I have created a workaround in our plug-ins to handle this situation: when extension clashes are found, the user is explicitly asked to choose the correct file type on the commandline.

During testing I found that the error is not only happening when a file is dropped; it also happens when the file is opened from the menu and the required file type is not chosen from the drop down list, i.e. the file type is Supported files (*.*)


Furthermore, I found that dropping files with the extension .pat is completely impossible because Rhino thinks it is a hatch pattern file and gives a message that loading these will be supported in a future version, whereas in our case it is a PATRAN file.