[KevinH]

I am wondering is this is the only file dialog that has the bug that causes a crash when hand entering an external url.

I grepped the Sigil source for "getOpenFileNames" and only found this routine in BookBrowser that BeckyEbook provided a fix for above.

But if I instead grep "getOpenFileName" I get the following long list of places it is used in Sigil

kbhend@MacBook-Pro src % grep getOpenFileName `find ./ -name "*.cpp"` 
.//Misc/OpenExternally.cpp:    const QString selectedFile = QFileDialog::getOpenFileName(parent,
.//MainUI/MainWindow.cpp:        QString filename = QFileDialog::getOpenFileName(this,
.//Dialogs/SearchEditor.cpp:    QString filename = QFileDialog::getOpenFileName(this,
.//Dialogs/IndexEditor.cpp:    QString filename = QFileDialog::getOpenFileName(this,
.//Dialogs/ClipEditor.cpp:    QString filename = QFileDialog::getOpenFileName(this,
.//Dialogs/PreferenceWidgets/PluginWidget.cpp:    QString zippath = QFileDialog::getOpenFileName(this, 
.//Dialogs/PreferenceWidgets/PluginWidget.cpp:    QString name = QFileDialog::getOpenFileName(this, 
.//Dialogs/PreferenceWidgets/GeneralSettingsWidget.cpp:    QString xeditorPath = QFileDialog::getOpenFileName(this,
.//Dialogs/EmptyLayout.cpp:    QString inipath = QFileDialog::getOpenFileName(this, 
.//main.cpp:    QString filename = QFileDialog::getOpenFileName(0,

So will someone with access to Windows try one of the other getOpenFileName instances above and try hand typing in an external url and hitting open and verifying if any of these crash. If so, we may need to move to non-native QFileDialogs for Windows throughout the Sigil code. If not, we will have found and fixed the only occurrence.

Looking at that list, the easiest one to test might be to open Sigil Preferences and try typing in an external url to the xeditor path where typically a path to PageEdit is put and see what happens.

Thanks!