Is there a way that I can force the native dialog with QFileDialog?

[A Former User]

I'm working under Windows 7, Qt 5.1. I see the following behaviour:
When I start the application from the commandline, I get the native dialog. However, when the application is started by another application via the Windows API (CreateProcess(); ) I always get the Qt internal dialog.

I see that there is an option to prevent the native dialog QFileDialog::DontUseNativeDialog but is there a way to force the native dialog?

Edit:
The reason why I want to force the native dialog can be seen in "my other post here":http://qt-project.org/forums/viewthread/32484/

[mbnoimi]

As far as I know using static function will use the native dialog so did you try to use the static function?

[A Former User]

My question is: Is it possible to force the native dialog. Not the other way around.

To answer your question: I did use both. You can have the native dialog also with not the static function(s). Both of the functions below give the exact same native file dialog on Windows 7. (You can "force" the Qt dialog for both of them by passing the QFileDialog::DontUseNativeDialog flag, but that's not the scope for now.)

@
// static
void MainWindow::on_pushButton_clicked()
{
QFileDialog::getOpenFileName(0,"test","text");
}

// Object
void MainWindow::on_pushButton_2_clicked()
{
QFileDialog * dialog = new QFileDialog();
dialog->exec();
delete dialog;
}
@

The strange thing happens when you start the application from another process with the windows API functions CreateProcess(). Then you always get the Qt dialog.

[mbnoimi]

[quote]The strange thing happens when you start the application from another process with the windows API functions CreateProcess(). Then you always get the Qt dialog. [/quote]
I suggest to file a bug report about this issue https://bugreports.qt-project.org/

Personally I advice you to get rid of Windows API unless you couldn't find any alternatives in Qt (ex. for you example use QProcess)

[A Former User]

I'll create a bug report. But I think I'll need to investigate the real issue a bit more deeply before doing it.

I absolutlely agree with your advice, but this is not a viable option at the moment.
How should I convince the other programmer of changing his code since the "bug" seems to be on my side of the code?
The function call is in a lightweight library. Pulling in Qt there is an overkill and QProcess is not found in non-Qt. I would have to check other solutions first (like posix threads, boost threads etc...) and there's the possibility that the source of the issue is even from before the library.

[mbnoimi]

[quote] How should I convince the other programmer of changing his code since the “bug” seems to be on my side of the code?[/quote]
If that programmer insist to use the API while Qt has encapsulated most API calls; I'll encourage him to leave Qt and hack around another toolkit (ex. For Windows he can use stupid MFC)