Solved QFileDialog selected paths under Windows
-
I develop my Qt application only under Linux. My users run under mixed Linux or Windows. But I do not run my application/Qt under Windows, so I cannot test for myself and rely on the documentation --- or you guys! --- for behaviour/differences across platforms.
I understand that Qt represents
QFile
paths internally using/
as the directory separator regardless of platform. Under Linux there is never any problem. Under Windows this is all fine while it's all handled internally, but not when a pure string is involved (noQFile
).In the case of
QFileDialog
methods, there are some which return the selected path(s) as aQString
, not as aQFile
, e.g.QString QFileDialog::getOpenFileName()
,QStringList QFileDialog::selectedFiles() const
.Now, it may not matter whether that comes back with
/
s or\
s for passing around as an argument to other Qt file-handling code, but it does matter when I need to "export" this to the "outside world". And the Qt documenation does not seem to tell me anything about how the path will be fromQFileDialog
under Windows. I need to know at minimum the following:-
For all the strings returned by
QString QFileDialog::getOpenFileName()
,QStringList QFileDialog::selectedFiles() const
and any otherQFileDialog
methods --- including any which return a directory instead of a file, e.g.QString QFileDialog::getExistingDirectory()
--- which directory separator will be used under Windows? -
Is the format affected by whether I do or do not specify
QFileDialog::DontUseNativeDialog
option? For example, I'm pretty sure that the actual Windows native dialog will be returning paths with\
s not/
s in them, but even if Qt is using that will it be translating the selected path back into Qt/
-format? The answer must also be correct where the Windows native directory rather than file chooser is being used, if that behaves differently. -
For now, my question of path strings returned by Qt applies only to
QFileDialog
. However, if there are any other Qt functions you know of which return a new path string, please also let me know.
Finally --- and incidentally, since I may use my own non-Qt file path routines for this --- is there any native Qt class/method for translating between Qt
/
file paths and actual native file paths, in both directions? -
-
@JNBarchan said in QFileDialog selected paths under Windows:
Finally --- and incidentally, since I may use my own non-Qt file path routines for this --- is there any native Qt class/method for translating between Qt / file paths and actual native file paths, in both directions?
-
@raven-worx
Thanks for those functions, I had been looking inQFile
class!Now if you know what the situation about my
QFileDialog
-returned paths, please do let me know...! -
@JNBarchan said in QFileDialog selected paths under Windows:
Now if you know what the situation about my QFileDialog-returned paths, please do let me know...!
What prevents you of simply trying this yourself within 30-45 secs?!?!
-
@raven-worx
Can't believe you asked that! The first paragraph of my post states extremely carefully & explicitly:I develop my Qt application only under Linux. My users run under mixed Linux or Windows. But I do not run my application/Qt under Windows, so I cannot test for myself and rely on the documentation --- or you guys! --- for behaviour/differences across platforms.
That's why I put it first. Is that not clear enough?
-
@JNBarchan
ok sorry from my side on that.
QFileDialog should always return/
as path separator.
But good practice is, whenever use '/' as separator for internal passed paths and convert them to native separators when you pass them externally. And i believe that is how Qt strictly handles it to unify the paths within the API.
But you can safely call fromNativeSeparators() on the path string everytime.But still i am wondering (and it's clearly out of my business) that you are developing a Windows application without even testing it once on a windows machine?!
-
ok sorry from my side on that.
:) Unlike some posters here, I always spend a lot of time testing/reading before I post a question...! If I do post, it represents something which I really can't discover for myself.
QFileDialog should always return / as path separator.
Thanks for that. I will bear that in mind, and will indeed look at ensuring I call
fromNativeSeparators()
everywhere I might want to output. (It's actually a touch more complex for me: I use Python/PyQt, and I use Python'spathlib
module for everywhere I deal with paths except across Qt boundaries, so I have to be careful.)But still i am wondering (and it's clearly out of my business) that you are developing a Windows application without even testing it once on a windows machine?!
I am developing an application which is to be cross-platform, for Linux & Windows. I am using Qt precisely because it is a cross-platform solution. Since it's cross-platform, and seems to do an admirably good job at it, why would I want to put myself through the grief of testing it under Windoze? It's my users, not me, who might be running Windoze. Normally you can use Windows users as guinea pigs, because if anything goes wrong you can just say it was typical Windoze misbehaviour. However, in this particular case the code involved is copying a large directory structure over another directory structure. If I get that wrong with
/
s and\
s I could blat all their data, and I even i would feel guilty in that situation.... ;-)