Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: 1. Create a FileDialog to open a file 2. Type in a filename (see below - case (d) is the failure) 3. Click 'Open' or press 'Enter' If the filename is: a) in the current directory of the dialog (ie: "myfile" or "myfile.txt"), it works b) in a directory that exists (ie: "C:\temp\myfile" or "C:\temp\myfile.txt", and the directory "C:\temp\" exists), it works c) in a directory that doesn't exist, and the file has an extension (ie: "C:\temp\myfile.txt", and "C:\temp\" doesn't exist), it works d) in a directory that doesn't exist, and the file DOESN'T have an extension (ie: "C:\temp\myfile" and "C:\temp\" doesn't exist), then it fails. More information: By "failure", I mean that the FileDialog behaves the exact same on "Open" as it does on "Cancel". The problem only happens if trying to choose a file in a directory that doesn't exist, and the file has no extension. The general use case for this is when the user is trying to type out a directory - ie: "c:\temp\blah\somewhere", and accidentally mistypes one of the characters, the dialog behaves as if it was cancelled instead of trying to open the non-existent file/directory
*ping* - still an issue in 3.4 M7.
On my home Vista box, I get a warning dialog that says: c:\bogus\myfile Path does not exist. Check the path and try again. This seems like expected (good) behavior to me. I get the same behavior for both case (c) and (d). I will try it on my work XP in the morning.
Interesting. The XP dialog does have some very strange behavior. It's even weirder than you mentioned... it actually depends on what names I type. MS must not have tested very well for the keyboard user. They have fixed this for Vista - there, the dialog is much pickier, and that is good. Here are my results. Note that c:\bogus and c:\temp2 do not exist. I used the SWT ControlExample's Dialog tab, with FileDialog selected. In all cases, I am either clicking on Open, or typing Return. 1) Type c:\temp2\readme.txt FileDialog Result: C:\temp2\readme.txt <<< good getFileNames() = getFilterIndex() = 0 2) Type c:\temp2\readme FileDialog Result: null <<<< this is the bad 'cancel' behavior you described getFileNames() = getFilterIndex() = 0 3) Type c:\bogus\afile.txt FileDialog Result: c:\bogus\afile.txt <<< good getFileNames() = getFilterIndex() = 0 3) Type c:\bogus\afile (compare with (2) - same scenario, different names) FileDialog Result: C:\afile <<<< this really bad! It lost the 'bogus' completely getFileNames() = getFilterIndex() = 0 Yoiks. If I type c:\bogus\temp and type Enter, I navigate into my (existing) c:\temp directory. And yet c:\lalala\temp Enter returns null, which is the 'cancel' behavior. Anyhow, I don't think this is us - we relinquish control to the platform after opening the dialog. I am tempted to close this as "Not Eclipse".
I tried this in Notepad. They do not have these strange issues there, and it looks like they are using the same dialog, so they are doing something right. So we may be able to fix this - I will investigate after 3.4 ships. It would probably help if you ping me again in August or so.
Thanks for looking into this - I've also verified that there is no problems with this dialog on Vista, and that the problem is limited to XP, Although I haven't been having as much problems with it that you seem to be having...mine's been pretty consistent with giving me the same incorrect null result for case (d) every time. In any case, thanks for letting me know that this is *out* for 3.4 - I'll ping back again later if necessary.
*ping* - any plans to look into this further?
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
