QFileDialog::setDirectory does not appear to work properly in OpenSuSE 11.3 QT 4.6.3

[crubel]

When we use this same code snippet in openSuSE 10.3 which is
running QT 4.5.2 the setDirectory works OK and the dialog opens
listing the expected contents...

"NOTE: the path does not seem to matter"

QFileDialog dialog;
QString filename;
QString path = ConvertPath("ScenarioDir");

dialog.setDirectory( "/tmp/" );

QDir rdir = dialog.directory();
NOTE: rdir is correct here in all cases..

filename = dialog.getOpenFileName();

if ( filename.toStdString().empty() )
return;

However when running OpenSuSE 11.3 which is running QT 4.6.3 it appears
the dialog opens up using the path of where the QT binary program we are running
is executed from....

Are we missing something here...

Thanks,

Curtis
crubel@compro.net

[ChrisW67]

I cannot reproduce this in C++. The dialog opens where the directory was set. If the directory does not exist it defaults to the root directory. Post a small, self-contained example that breaks this way.

[crubel]

I cannot reproduce this in C++. The dialog opens where the directory was set. If the directory does not exist it defaults to the root directory. Post a small, self-contained example that breaks this way.

I beginning to wonder if this has to do with the implementation of OpenSuSE 11.3's KDE ...that is somehow overriding the directory setting somehow.

However, I will be out of the office all morning tomorrow. As soon as I get back in to the office I will create one and post it for you.

Thanks for the quick response..

[Lykurg]

Also you can try to install the official sdk alongside the SuSE ones and see if the error arise there too.

[crubel]

If I did all of this correctly there is a small gui app attached to this post that
exhibits the error under openSuSE 11.3 and not under openSuSE 10.3

I am also in the process of adding in a vanilla Qt SDK and attempting the
same test on that. I will post the results as soon as I have them.

Thanks.....

[crubel]

Just a quick note to add to this thread..

This morning I installed the latest SDK 4.7, rebuilt the app I have attached
to my previous post. Verified that it was using the newly installed QT libraries
and not the version installed via openSuSE.

Same result, the file dialog still insists on opening in the same dir you start
the app from instead of where it was set to go to...

[ChrisW67]

You are trying to mix the static getOpenFileName() convenience function, which expects to get the working directory in its calling parameters, and using the dialog exec() or show() methods.

Try either the static approach:

void MainWindow::on_pushButton_clicked()
{
    QString fileName = QFileDialog::getOpenFileName(this,
        tr("Open File"), 
        "/tmp", 
        tr("All Files (*.*)")
    );
 
    if ( filename.isEmpty() )
        return;
}

void MainWindow::on_pushButton_clicked()
{
    QString fileName = QFileDialog::getOpenFileName(this,
        tr("Open File"), 
        "/tmp", 
        tr("All Files (*.*)")
    );

    if ( filename.isEmpty() )
        return;
}

To copy to clipboard, switch view to plain text mode 

or the conventional dialog approach

void MainWindow::on_pushButton_clicked()
{
    QFileDialog dialog;
    QString filename;
 
    dialog.setDirectory( "/tmp" );
    dialog.setFileMode(QFileDialog::ExistingFile);
    if (dialog.exec()) {
        QStringList filenames = dialog.selectedFiles();
        filename = filenames.at(0);
    }
    else
        // dialog rejected
}

void MainWindow::on_pushButton_clicked()
{
    QFileDialog dialog;
    QString filename;

    dialog.setDirectory( "/tmp" );
    dialog.setFileMode(QFileDialog::ExistingFile);
    if (dialog.exec()) {
        QStringList filenames = dialog.selectedFiles();
        filename = filenames.at(0);
    }
    else
        // dialog rejected
}

To copy to clipboard, switch view to plain text mode 

The behaviour is inconsistent if you mix the two it would seem.

[crubel]

SOLVED -- Thank you very much -- ChrisW67

Making the changes as you suggested has solved this issue for us.

Again thanks for the help and the explanation to the cause of the
problem. Seems no one here caught that mix of the two separate
approaches, not to mention throwing us off because it had worked
in the older versions of QT and KDE.

Curtis