QFileDialog returns wrong path
-
Hello,
Could somebody help me?
Recently, I am learning QT. I want to use QFileDialog to open some file. But I don't want to use native dialog, so I set QFileOption::DontUseNativeDialog to true. It works, and I can see QT own QFileDialog.
But there is a problem. If I use native dialog, it will select the first item by default when I enter a folder. But QT own QFileDialog doesn't act the same. Exactly, it works wrong.
Here is the detail.
When I open a QFileDialog, it select nothing, and the open button is disabled.
Then I select a file manully, and the open button is enabled.
Then I enter another folder, but it selects nothing in the folder. What's more the open button is still enabled.
Finally, I click the open button, and I get a file returned. But its path is not correctly. Its path is /tmp/VMwareDnD/config-err-2Emdj0. But the right path should be /tmp/config-err-2Emdj0
What should I do to solve this problem?
My environment.
ubuntu 16.04
Thanks.
-
Hello,
Could somebody help me?
Recently, I am learning QT. I want to use QFileDialog to open some file. But I don't want to use native dialog, so I set QFileOption::DontUseNativeDialog to true. It works, and I can see QT own QFileDialog.
But there is a problem. If I use native dialog, it will select the first item by default when I enter a folder. But QT own QFileDialog doesn't act the same. Exactly, it works wrong.
Here is the detail.
When I open a QFileDialog, it select nothing, and the open button is disabled.
Then I select a file manully, and the open button is enabled.
Then I enter another folder, but it selects nothing in the folder. What's more the open button is still enabled.
Finally, I click the open button, and I get a file returned. But its path is not correctly. Its path is /tmp/VMwareDnD/config-err-2Emdj0. But the right path should be /tmp/config-err-2Emdj0
What should I do to solve this problem?
My environment.
ubuntu 16.04
Thanks.
@Qingshui-Kong Did you check in Qt bug tracker whether this is a known issue? If it is not you can file a bug.
-
@Qingshui-Kong Did you check in Qt bug tracker whether this is a known issue? If it is not you can file a bug.
@jsulm
Thanks.I find a similar bug https://bugreports.qt.io/browse/QTBUG-2947. It was closed. But it was not soveld completely.
-
@jsulm
Thanks.I find a similar bug https://bugreports.qt.io/browse/QTBUG-2947. It was closed. But it was not soveld completely.
@Qingshui-Kong It isn't solved at all:
"Resolution: Out of scope"
"Fix Version/s: Some future release"I don't know why it is considered as "Out of scope".
Nobody voted for it. Maybe you can try to reopen it or file a new one. -
@Qingshui-Kong It isn't solved at all:
"Resolution: Out of scope"
"Fix Version/s: Some future release"I don't know why it is considered as "Out of scope".
Nobody voted for it. Maybe you can try to reopen it or file a new one.Yes. It isn't solved. But something must have changed. Because in my software the open button will be disabled, if I delete the file name.
Maybe, the reason is that it is a suggestion. But I think it is a bug!
-
Yes. It isn't solved. But something must have changed. Because in my software the open button will be disabled, if I delete the file name.
Maybe, the reason is that it is a suggestion. But I think it is a bug!
@Qingshui-Kong Isn't this exactly your problem:
"1) While browsing across different directories, if you select a file and
move to another directory, that file name does not get cleared from
'File name' text box.". -
@Qingshui-Kong Isn't this exactly your problem:
"1) While browsing across different directories, if you select a file and
move to another directory, that file name does not get cleared from
'File name' text box.". -
@Qingshui-Kong
The bug was reported in 2008 but never addressed, it seems. You could re-open the issue.You cannot affect the path it returns in this situation. The one it returns is "correct" in the sense of what the final screenshot shows, but that's not really the point.
What I suspect you really need to address is: it is possible for the dialog to return a file path which does not exist for a number of reasons, your code must handle the possibility.
-
@Qingshui-Kong
The bug was reported in 2008 but never addressed, it seems. You could re-open the issue.You cannot affect the path it returns in this situation. The one it returns is "correct" in the sense of what the final screenshot shows, but that's not really the point.
What I suspect you really need to address is: it is possible for the dialog to return a file path which does not exist for a number of reasons, your code must handle the possibility.
Thanks! Yes, the bug was reported before but never addressed. I reported a new bug.
I solved it by disabling the open button and clearing the lineedit in my slot for the currentChanged signal.
But I think there are some other bugs about the DontUseNativeDialog QFileDialog.