#376 QwtPlotRenderer::renderDocument does not report unhandled format

[Anonymous]

Calling QwtPlotRenderer::exportTo() under Linux and manually writing the name of a new file (without explicitely adding the file extension) leads to an unsupported (an empty QString) format in QwtPlotRenderer::renderDocument() with Qt 5.15.2.
This in turn leads to QwtPlotRenderer::renderDocument not producing any output.
So would it be possible for QwtPlotRenderer::renderDocument()-functions to return true on success and false otherwise? Then one could write bool const renderResult = renderDocument( plot, fileName, sizeMM, resolution ); in bool QwtPlotRenderer::exportTo(), open an Info-Dialog if both renderResult is false and #ifndef QT_NO_FILEDIALOG and warn about the unsupported file extension. And finally return renderResult.

Under Windows however the Qt dialog QFileDialog::getSaveFileName() seems to always append the first listed extension of the selected image filter - so the above problem seems to be Linux only.

[Anonymous]

If this seems feasable, I would be willing to create a git Branch and create a PullRequest - I wanted to ask about the willingness to accept such a change first however.

[Anonymous]

As promised, here a proposal for the changes.
I did not auto-deduce a file-extension on Linux, as that would have required to change from the OS-native static QFileDialog::getSaveFileName() (see here).

Would be glad about any feedback.

[Anonymous]

In addition, the actual QwtPlotRenderer::render stil don't return a value - as they are virtual and I suppose do have derived implementations.
Should this be fully consistent, then this would require breaking API changes. Or one would have to introduce slightly differently named methods, that actually return a bool.
Anyone got an opinion?

[Uwe Rathmann]

I committed the patch to develop with 2 adjustments:

• fixing the Qt config guard of QMessageBox
• modified the text of the error box

Regarding QwtPlotRenderer::render: this method only fails, when passing in invalid parameters like a nullptr for the plot. Doing nothing then seems to be the expected behavior - IMO not worth to break compatibilities by introducing a return value.

[Anonymous]

Great - thanks.