OK. The getOpenFileNames dialog is not crashing on Windows. It's returning a value for the rest of BookBrowser::AddExisting() to continue processing. There merely seems to be some sort of built-in guardrail in the non-native dialog (and the native one on linux) that returns an empty value when an url is detected.
Quote:
|
NOTE: the native getOpenFileNames dialog on my Linux Cinnamon desktop doesn't even give me a field to paste anything into. Just a folder Tree View, a file(s) selection pane, and OK/Cancel buttons.
|
The "actual" problem area on Windows is line 937 of BookBrowser.cpp
Code:
Resource *resource = m_Book->GetFolderKeeper()->AddContentFileToFolder(filepath);
I've added debug output immediately before and after that line, and what comes after never gets output.
Code:
Debug: Returned from getOpenFileNames QList("https://www.adfg.alaska.gov/static/fishing/images/sport/galleries/Sport_Fish.1.jpg")
Debug: Last folder open = "C:/Program Files/Sigil/https:/www.adfg.alaska.gov/static/fishing/images/sport/galleries"
Debug: File name portion = "Sport_Fish.1.jpg"
Debug: Preparing to add new resource for: "https://www.adfg.alaska.gov/static/fishing/images/sport/galleries/Sport_Fish.1.jpg"
Warning: Qt has caught an exception thrown from an event handler. Throwing
exceptions from an event handler is not supported in Qt.
You must not let any exception whatsoever propagate through Qt code.
Warning: Release of profile requested but WebEnginePage still not deleted. Expect troubles !
Warning: Release of profile requested but WebEnginePage still not deleted. Expect troubles !
Warning: Release of profile requested but WebEnginePage still not deleted. Expect troubles !
For what it's worth: I'm not at all opposed to using a non-native dialog on Windows here if it's the easiest fix. I also don't mind digging deeper (or adding a function that checks for urls entered and balks). **shrug**