File-open dialog does not accept non-existing *.img files as target

[Andreas N]

Version 0.8
Windows 7 x64 SP1
-----------------------------------------

Selecting an image file in the file-open dialog only works if that file already exists.
When you want to backup your memory card you also would like to use that file-dialog in order to specify the target *.img file.

Currently, the file-open dialog won't accept non-existing files. I propose a modification, that will enable your tool to accept non-existent files.

As of now, a workaround is to type or paste the target filename (including full path) directly into the text box. The [read] button becomes available then.

Some thoughts:
According to your code, you are only using QFileDialog::getOpenFileName(). That is probably the reason, why only existing files can be selected. You probably have to add some distinction, what to do (read or write) and depending on that use getOpenFileName() or getSaveFileName().
A possible solution is to replace the READ and WRITE buttons with a START button and add another group with radio buttons as some sort of input information. Depending on which radio button has the bullet in it, you chose the appropriate file dialog.
I attached a screenshot of a possible GUI that shows what's in my minds eye.

[Andreas N (der-andi)]

The GUI from the screenshot was quickly created with Qt Designer. If you find this useful, I give you the *.ui (XML format) below.

[Jeff B (skydiver38)]

The "open/save" file dialog problem is one we've discussed before, and I was going to write a more generic "fileDialog" that didn't restrict your selection based on whether you were trying to "open" or "save" a file.

That said, the radio button idea is a good one, and certainly easier than writing a dialog.

It's Tobin's call - I could live with either solution. Thanks for the thoughts and files!

[Tobin Davis (gruemaster)]

Thanks for the idea. Part of the problem is Windows and it's constantly changing behavior. v0.6 and earlier used getSaveFileName() and didn't have any issues. With Windows 7, if the file selected existed AND was read-only, the dialog would fail. When fixing this and adding features to v0.7, I switched to getOpenFileName() and added a comment in the readme about the change and the (temporary) work around for saving a new file (just type in the filename and click read, the program will write a new image file in your %USER%/Downloads directory (which can now be overridden with %DiskImageDir% in v0.8).

I am looking into a generic file selection option, or the ability to add a button to the Open File dialog to create a new file (similar to the New Directory button).

I do like your solution and will give it a lot of consideration. Main thing is I want to get something working before the end of June, so I can push another release that also fixes lp:1118217 (another fine example of Windows API changes).

[Tobin Davis (gruemaster)]

Jeff B made an excellent change that gives us 1 dialog without changing the main UI. Will release this in a binary soon (this weekend?).

[Tobin Davis (gruemaster)]

This has been fixed with release v0.9. Please test it thoroughly and let us know if it still has issues. As always, please file new bugs found separately, and only reopen this bug if this issue is not resolved.

Thank you for your patience and continued support.