Qt-interest Archive, October 2006
QFileDialog
Message 1 in thread
Hello,
Is there a way to set the default suffix for the static
QFileDialog::getSaveFileName function?
I'm currently using a regexp to add it afterward, but if there's
another file of the same name with no extension in that directory, a
warning message that the file will be overwritten occurs. I'd like to
avoid that.
Failing that, is there another way to call the native Windows dialog
with QT, so that I can use the setDefaultSuffix() function?
Thanks
Ian Larsen
--
[ signature omitted ]
Message 2 in thread
Hi,
> I'm currently using a regexp to add it afterward, but if there's
> another file of the same name with no extension in that directory, a
> warning message that the file will be overwritten occurs. I'd like to
> avoid that.
Could you show us the actual code?
I'm not certain what you mean by "default suffix", is it different from
the filter/selectedFilter arguments?
> Failing that, is there another way to call the native Windows dialog
> with QT, so that I can use the setDefaultSuffix() function?
Sure, that's what QFileDialog::getSaveFileName() does, you can have a
look at the source code.
--
[ signature omitted ]
Message 3 in thread
Thanks for the reply, here's my current code:
if (filename == "")
{
filename = QFileDialog::getSaveFileName(this, "Save file as",
".", "KidBASIC File (*.kbs);;Any File (*.*)");
}
if (filename != "")
{
QRegExp rx("\\.[^\\/]*$");
if (rx.indexIn(filename) == -1)
{
filename += ".kbs";
}
My problem is that I want this to work like the non-static version,
with the function setDefaultSuffix() (already part of the QFileDialog
class), which adds .kbs automatically if there's no file extension
given.
The problem with using the non-static QFileDialog is that it doesn't
have the Desktop, My Documents, etc. shortcuts like a typical Windows
save dialog does.
It's not a big deal, but I was wondering if it was possible to somehow
tell the native windows save dialog to use the .kbs suffix, similar to
how you'd set it using the non-static QFileDialog class.
Thanks,
Ian Larsen
On 10/10/06, Dimitri <dimitri@xxxxxxxxxxxxx> wrote:
> Hi,
>
> > I'm currently using a regexp to add it afterward, but if there's
> > another file of the same name with no extension in that directory, a
> > warning message that the file will be overwritten occurs. I'd like to
> > avoid that.
>
> Could you show us the actual code?
>
> I'm not certain what you mean by "default suffix", is it different from
> the filter/selectedFilter arguments?
>
> > Failing that, is there another way to call the native Windows dialog
> > with QT, so that I can use the setDefaultSuffix() function?
>
> Sure, that's what QFileDialog::getSaveFileName() does, you can have a
> look at the source code.
>
> --
> Dimitri
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
>
>
--
[ signature omitted ]
Message 4 in thread
Yes.. In the OPENFILEDIALOG win32 structure, you can set a default
suffix, so when the user enters the name only, no suffix, its
automatically returned without the developer having to so it..
Unfortunately, the QFileDialog statics do not give complete access, but
rather give universal access to what QT has decided to implement on
unich.
For instance, remembering where the dialog was opened previously. Now a
standard on windows for 3+ years, but QT wont give access to that
either...
Scott
> -----Original Message-----
> From: Dimitri [mailto:dimitri@xxxxxxxxxxxxx]
> Sent: Tuesday, October 10, 2006 8:51 PM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Re: QFileDialog
>
> Hi,
>
> > I'm currently using a regexp to add it afterward, but if there's
> > another file of the same name with no extension in that directory, a
> > warning message that the file will be overwritten occurs. I'd like
to
> > avoid that.
>
> Could you show us the actual code?
>
> I'm not certain what you mean by "default suffix", is it different
from
> the filter/selectedFilter arguments?
>
> > Failing that, is there another way to call the native Windows dialog
> > with QT, so that I can use the setDefaultSuffix() function?
>
> Sure, that's what QFileDialog::getSaveFileName() does, you can have a
> look at the source code.
>
> --
> Dimitri
>
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body.
> List archive and information: http://lists.trolltech.com/qt-interest/
--
[ signature omitted ]
Message 5 in thread
Scott Aron Bloom wrote:
> For instance, remembering where the dialog was opened previously. Now a
> standard on windows for 3+ years, but QT wont give access to that
> either...
A simple workaround is to change the current working directory to the one
returned by the QFileDialog (it can be extracted from the filename). Next time
QFileDialog will open from the same directory:
QFileInfo fileinfo(filename);
QDir::setCurrent(fileinfo.dir().absolutePath());
Paul.
--
[ signature omitted ]
Message 6 in thread
> -----Original Message-----
> From: Paul Koshevoy [mailto:paul@xxxxxxxxxx]
> Sent: Wednesday, October 11, 2006 12:09 AM
> To: qt-interest@xxxxxxxxxxxxx
> Subject: Re: QFileDialog
>
> Scott Aron Bloom wrote:
>
> > For instance, remembering where the dialog was opened previously.
Now a
> > standard on windows for 3+ years, but QT wont give access to that
> > either...
>
> A simple workaround is to change the current working directory to the
one
> returned by the QFileDialog (it can be extracted from the filename).
Next
> time
> QFileDialog will open from the same directory:
>
> QFileInfo fileinfo(filename);
> QDir::setCurrent(fileinfo.dir().absolutePath());
>
> Paul.
>
That's a pretty extreme solution... Since your whole app now is looking
at that dir...
But it also doesn't solve the multi process issue, nor the app-reentrent
issue. Windows stores it in the registry so next time it comes up. Its
there...
Scott
--
[ signature omitted ]
Message 7 in thread
"Scott Aron Bloom" <scott@xxxxxxxxxxxx> wrote in message
news:E2E5EA152B64E044B464DA705AF44AAE04F236@xxxxxxxxxxxxxxxxxxxxxx
<snip>
>> QFileInfo fileinfo(filename);
>> QDir::setCurrent(fileinfo.dir().absolutePath());
>That's a pretty extreme solution... Since your whole app now is looking
>at that dir...
You can set the start directory in QFileDialog so I usually extract
the directory info from the returned filename and use that as
the initial directory next time QFileDialog is opened.
>But it also doesn't solve the multi process issue, nor the app-reentrent
>issue. Windows stores it in the registry so next time it comes up. Its
>there...
My boss is always complaining about that one. I guess you
could use QSetting and write it yourself but I'm trying to avoid
that one.
--
[ signature omitted ]
Message 8 in thread
What I wound up doing, was wrapping the statics, with a set of static functions myself, that do exactly that, use qsettings to save/restore the directory.
Scott
________________________________
From: Duane Hebert [mailto:spoo@xxxxxxxxx]
Sent: Wed 10/11/2006 9:27 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: QFileDialog
"Scott Aron Bloom" <scott@xxxxxxxxxxxx> wrote in message
news:E2E5EA152B64E044B464DA705AF44AAE04F236@xxxxxxxxxxxxxxxxxxxxxx
<snip>
>> QFileInfo fileinfo(filename);
>> QDir::setCurrent(fileinfo.dir().absolutePath());
>That's a pretty extreme solution... Since your whole app now is looking
>at that dir...
You can set the start directory in QFileDialog so I usually extract
the directory info from the returned filename and use that as
the initial directory next time QFileDialog is opened.
>But it also doesn't solve the multi process issue, nor the app-reentrent
>issue. Windows stores it in the registry so next time it comes up. Its
>there...
My boss is always complaining about that one. I guess you
could use QSetting and write it yourself but I'm trying to avoid
that one.
--
[ signature omitted ]
Message 9 in thread
Hi,
> For instance, remembering where the dialog was opened previously. Now a
> standard on windows for 3+ years, but QT wont give access to that
> either...
Right, but this should still be possible using the current Qt API. It
does require some coding on your part but it's possible.
--
[ signature omitted ]
Message 10 in thread
I guess my frustration stems from the notion of using the lowest common denominator to determine functionality.
If QT did not set the startup directory in the FILEOPENDIALOG win32 structure, in the QFileDialog_win area, then it would work fine.
But if I set the startup dir via the startWith, using a QString:null or QString(), it sets it to an empty string in the win32, rather then null, which is how Win32 says, oh he wants it to be based on CWD, vs let me determine where it goes.
When I spoke to support 2+ years ago on this, their response was, since Unix and MacOSX dont suppor that, we dont want to support it on windows. I said, why not wrap the MacOSx and Unix to support it ?
Scott
________________________________
From: Dimitri [mailto:dimitri@xxxxxxxxxxxxx]
Sent: Wed 10/11/2006 10:31 AM
To: qt-interest@xxxxxxxxxxxxx
Subject: Re: QFileDialog
Hi,
> For instance, remembering where the dialog was opened previously. Now a
> standard on windows for 3+ years, but QT wont give access to that
> either...
Right, but this should still be possible using the current Qt API. It
does require some coding on your part but it's possible.
--
[ signature omitted ]
Message 11 in thread
Hi,
> When I spoke to support 2+ years ago on this, their response was, since Unix and MacOSX dont suppor that, we dont want to support it on windows. I said, why not wrap the MacOSx and Unix to support it ?
Sure, it makes sense. I'm just pointing out that remembering where the
dialog was opened previously is possible using the current Qt API, at
the expense of some additional portable code. On the other hand the
"default suffix" issue can't be worked around as far as I can see -
other than rewriting the whole static function.
--
[ signature omitted ]
Message 12 in thread
Scott Aron Bloom wrote:
> I guess my frustration stems from the notion of using the
> lowest common denominator to determine functionality.
>
> If QT did not set the startup directory in the FILEOPENDIALOG
> win32 structure, in the QFileDialog_win area, then it would
> work fine.
>
> But if I set the startup dir via the startWith, using a
> QString:null or QString(), it sets it to an empty string in
> the win32, rather then null, which is how Win32 says, oh he
> wants it to be based on CWD, vs let me determine where it goes.
>
> When I spoke to support 2+ years ago on this, their response
> was, since Unix and MacOSX dont suppor that, we dont want to
> support it on windows. I said, why not wrap the MacOSx and
> Unix to support it ?
Maybe you should simply try again.
Andre'
--
[ signature omitted ]
