DontUseNativeDialog option and non-static functions

[Qtbl]

When I create a file dialog using a static function from QFileDialog the DontUseNativeDialog option can be enabled or or disabled. But if I create a file dialog using the constructor that option is enabled no matter what I do. Even when testOption(QFileDialog::DontUseNativeDialog) returns false. Is there something related I miss?
Thanks

[ttvo]

I experience the same problem of not being to force a native dialog on Windows when using the QFileDialog constructor. Can someone help?

[tbscope]

If you create a QFileDialog subclass, this is documented behavior:

the native file dialog is used unless you use a subclass of QFileDialog that contains the Q_OBJECT macro.

Is this the case?

[ttvo]

No, it isn't. I use the QFileDialog constructor isntead of the static ones (because I have the need to use the setHistory etc ...).

[tbscope]

No, it isn't. I use the QFileDialog constructor isntead of the static ones (because I have the need to use the setHistory etc ...).
Okidoki, I didn't know I need to use a static function to create a subclass. I did learn something new, thanks.

First of all, the meaning of DontUseNativeDialog is understood correctly? When true, it does not show the native dialog, when false is does.
If so, can you please provide a small compilable example of the problem so I can test some things out on my computer?

[ttvo]

Code where the windows native dialog is NOT used and can't find any flags to enable that


QFileDialog dialog(this);
dialog.setFileMode(QFileDialog::AnyFile);
dialog.setHistory("list of my custom path histories");
dialog.exec();


when using the static calls, of course, the native dialog is used, but then I can't setHistory etc ...

Thx

[tbscope]

and can't find any flags to enable that

Did you try:

dialog.setOption(QFileDialog::DontUseNativeDialog, false);
?

[Qtbl]

@ tbscope: Did you?

[tbscope]

@ tbscope: Did you?

No, it is a simple question for you or the other poster. Answer it with any of the following please:
1. Yes, but it still doesn't work.
2. Yes, and now it works.
3. No.


A: Help my car doesn't start.
B: Did you try to turn it on?
A: Did you?

Edit:
Yes, I tried it.


QFileDialog dlg(this);

dlg.exec();
This shows the native dialog in KDE.


QFileDialog dlg(this);

dlg.setOption(QFileDialog::DontUseNativeDialog, true);
dlg.exec();
This shows the Qt file dialog in KDE.


QFileDialog dlg(this);

dlg.setOption(QFileDialog::DontUseNativeDialog, false);
dlg.exec();
This shows the native KDE dialog

[nish]

A: Help my car doesn't start.
B: Did you try to turn it on?
A: Did you?

oh man!! .. ROTFL

[Qtbl]

If you want to help us just do it. Don't BS us with deep truisms:

... First of all, the meaning of DontUseNativeDialog is understood correctly? When true, it does not show the native dialog, when false is does.


If you read my first post you'll notice that I have this situation: the file dialog created using a constructor is the one Qt provides even when DontUseNativeDialog is disabled - set to false using setOption (when testOption(QFileDialog::DontUseNativeDialog) returns false).

Glad to hear it works on your system. Does this help me? Nope

LE:
@ MrDeath: Dude, don't interrupt a small talk, try Cartoon Network instead

[nish]

Can you show your sample code please. how you are setting the option? The last code u pasted, did not set that option.

[tbscope]

Qtbl,

Can you please post a small compilable example so I can test it on my computer?
That you already set that option explicitly was not clear to me.

What operating system do you use?

[Qtbl]

FileDialogTest.pro

QT += gui

TEMPLATE = app
TARGET = FileDialogTest

HEADERS += FileDialogTest.h
SOURCES += main.cpp

main.cpp

#include <QApplication>
#include "FileDialogTest.h"

int main(int argc, char* argv[])
{
QApplication app(argc, argv);
FileDialogTest fileDialogTest;

fileDialogTest.show();

return app.exec();
}

FileDialogTest.h

#ifndef FILE_DIALOG_TEST
#define FILE_DIALOG_TEST

#include <QDialog>
#include <QFileDialog>
#include <QVBoxLayout>
#include <QPushButton>
#include <QLabel>
#include <QCheckBox>

class FileDialogTest : public QDialog
{
Q_OBJECT

public:
FileDialogTest(QWidget* parent = 0) : QDialog(parent)
{
QVBoxLayout* main_layout = new QVBoxLayout(this);
QPushButton* createFileDialog_btn = new QPushButton("Open file");
useNativeDialog = new QCheckBox("Use native dialog");
dialogType = new QLabel("DontUseNativeDialog = ?");

connect(createFileDialog_btn, SIGNAL(clicked()), this, SLOT(createFileDialog()));

main_layout->addWidget(createFileDialog_btn);
main_layout->addWidget(useNativeDialog);
main_layout->addWidget(dialogType);
}

private slots:
void createFileDialog()
{
QFileDialog dialog(this);

dialog.setOption(QFileDialog::ShowDirsOnly);
if (useNativeDialog->isChecked())
dialog.setOption(QFileDialog::DontUseNativeDialog, false);
else
dialog.setOption(QFileDialog::DontUseNativeDialog, true);

dialogType->setText(QString("DontUseNativeDialog = %1").arg(dialog.testOption(QFileDialog::DontUseNative Dialog)));

dialog.exec();
}

private:
QCheckBox* useNativeDialog;
QLabel* dialogType;
};

#endif // FILE_DIALOG_TEST

On my system (Windows XP SP3) the type of the dialog is the same - Qt file dialog - even though in the first case (default, when the state of the checkbox is unchecked) the label shows 1 and in the second it shows 0.
So what's wrong with this code? (Remember, I'm a newbie)

[tbscope]

I did some testing and reading.

This DOES work on Linux. It does NOT work on Windows XP
This means there's an inconsistency. This alone is worth a bug report.

Edit: Just to note that I've found a reply of the person who maintains QFileDialog and according to him:


Since 4.5 on the mac if you use the class QFileDialog (not static functions), it will display the native Mac dialog unless you give the flag QFileDialog::DontUseNativeDialog. Unfortunately this feature is not implemented for Windows. The only way to get the native dialog on Windows is static functions. Of course you have no control on the native one. So, why not using the Qt one instead?

[Qtbl]

Oh, I see. Thanks for the info.