Community
Participate
Working Groups
If I create a FileDialog and use setFilterPath to set a directory, I expect the file dialog to open with that directory shown. If I use the dialog to determine a filename to save a file, that works the first time. If I try a second time, and since I didn't change directories the first time, it works again. This second time I choose a different folder. I try a 3rd time. It unexpectedly shows the folder where I last saved the file, not the path set via setFilterPath. If I terminate my Eclipse runtime and restart it, the problem is still there. If I reboot my system and try again, still it uses the last used folder location rather than what I set via setFilterPath. I use Windows 10.
Is this a regression? If yes, it could be due bug 571571 changes in 4.20.
I checked: Eclipse ESCET v0.1 -> based on Eclipse Platform 2020-06/4.16 (issue present) Eclipse ESCET v0.2 -> based on Eclipse Platform 2021-06/4.20 (issue present) So it seems it does not seem to be a regression in Eclipse 2021-06/4.20.
Windows dialogs remember the last used folder natively and use that remembered folder as long as you keep passing the same folder to setFilter. I'm pretty sure this behavior hasn't changed when I migrated to COM API, I'll re-check. Whether setFilter should yield to natively remembered folder or behave like a hard override is another question.
> Whether setFilter should yield to natively remembered folder or behave like a hard override is another question. Would it technically be possible to have such a hard override?
(In reply to Dennis Hendriks from comment #4) > > Whether setFilter should yield to natively remembered folder or behave like a hard override is another question. > > Would it technically be possible to have such a hard override? Yes. But SWT only has one setFilter function. If it wasn't a hard override before, we'll need a good reason to change it.
> Yes. But SWT only has one setFilter function. > If it wasn't a hard override before, we'll need a good reason to change it. If it wasn't a hard override before, could we change it like this: setFilterPath(String path) setFilterPath(String path, boolean override) The first method stays as is, ensuring backward compatibility. It calls the second method with for the 2nd argument value 'false'. The second allows to hard override by setting the 2nd argument to 'true'. This is backward compatible, but does allow the 'hard override'.
I am can confirm this behavior changed with the new COM-based API. The following snippet can be used to reproduce the issue: public class Snippet72 { public static void main (String [] args) { Display display = new Display (); Shell shell = new Shell (display); shell.open (); FileDialog dialog = new FileDialog (shell, SWT.OPEN); dialog.setFilterPath("C:\\windows"); System.out.println ("Selected file: " + dialog.open ()); while (!shell.isDisposed ()) { if (!display.readAndDispatch ()) display.sleep (); } display.dispose (); } } With SWT 4.9 (from https://archive.eclipse.org/eclipse/downloads/drops4/R-4.9-201809060745/swt-4.9-win32-win32-x86_64.zip), setFilterPath works even if a file from a different directory was previously selected. With the newest SWT version, the directory of the previously selected file overrides setFilterPath.
*** Bug 578045 has been marked as a duplicate of this bug. ***
(In reply to Rolf Theunissen from comment #8) > *** Bug 578045 has been marked as a duplicate of this bug. *** This bug contains a possible fix for the issue, i.e., clearing the persisted data of the file dialog.
(In reply to Rolf Theunissen from comment #9) > (In reply to Rolf Theunissen from comment #8) > > *** Bug 578045 has been marked as a duplicate of this bug. *** > > This bug contains a possible fix for the issue, i.e., clearing the persisted > data of the file dialog. I tried out the proposed fix in bug 578045, will be sharing a gerrit shortly.
New Gerrit change created: https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189371
Gerrit change https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189371 was merged to [master]. Commit: http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/?id=5544e1405e798123adc57305ba130c14fbf6e965
(In reply to Eclipse Genie from comment #12) > Gerrit change > https://git.eclipse.org/r/c/platform/eclipse.platform.swt/+/189371 was > merged to [master]. > Commit: > http://git.eclipse.org/c/platform/eclipse.platform.swt.git/commit/ > ?id=5544e1405e798123adc57305ba130c14fbf6e965 Resolving now.
Is is possible to backport this patch in Eclipse 2021-09?
*** Bug 578415 has been marked as a duplicate of this bug. ***
Verified on Win10 using Eclipse Build id: I20220216-1800
I'm going to revert this, because it doesn't match the historical (non-COM) FileDialog behavior and causes Bug 579359 and Issue #95 (https://github.com/eclipse-platform/eclipse.platform.swt/issues/95) I.e. we are going back to the system-managed remembered folder with FileDialog.setFilterPath being the default, not a hard override. Also, I was unable to confirm the claims from Bug 578415 that it used to work like a hard override before 4.20. Niraj, what do you think?
(In reply to Nikita Nemkin from comment #17) > I'm going to revert this, because it doesn't match the historical (non-COM) > FileDialog behavior and causes Bug 579359 and Issue #95 > (https://github.com/eclipse-platform/eclipse.platform.swt/issues/95) > > I.e. we are going back to the system-managed remembered folder with > FileDialog.setFilterPath being the default, not a hard override. Also, I was > unable to confirm the claims from Bug 578415 that it used to work like a > hard override before 4.20. > > Niraj, what do you think? Hi Nikita, Reopening, as below PR reverts the fix made in this bug: https://github.com/eclipse-platform/eclipse.platform.swt/pull/142 But we should continue to look for a possible fix here.
(In reply to Nikita Nemkin from comment #17) > I'm going to revert this, because it doesn't match the historical (non-COM) > FileDialog behavior and causes Bug 579359 and Issue #95 > (https://github.com/eclipse-platform/eclipse.platform.swt/issues/95) > > I.e. we are going back to the system-managed remembered folder with > FileDialog.setFilterPath being the default, not a hard override. Also, I was > unable to confirm the claims from Bug 578415 that it used to work like a > hard override before 4.20. > > Niraj, what do you think? I tested with SWT versions 4.16 through 4.25M1 and on Windows 10 the versions prior to 4.20 work as hard override for me, so does 4.23. Working as hard override: 4.16, 4.17, 4.18, 4.19, 4.23 Working as soft default: 4.20, 4.21, 4.22, 4.24, 4.25M1 Please provide a way to hard override again. Not being able to do a hard override breaks some very common use cases when working with multiple file types. (e.g.: When loading a config file we want to point the user to the folder where config files are saved by default. This should be possible even if the user exported some unrelated data to a different directory earlier. With the current SWT version this is not possible as far as I can tell.) Snippet used for testing: public static void main(String[] args) { Display display = new Display (); Shell shell = new Shell (display); shell.open (); FileDialog dialog = new FileDialog (shell, SWT.OPEN); dialog.setFilterPath("C:\\Windows"); dialog.open(); //select file C:\\Windows\\notepad.exe FileDialog dialog2 = new FileDialog (shell, SWT.OPEN); dialog2.setFilterPath("C:\\"); dialog2.open(); //check if we land in C:\\Windows or in C:\\ display.dispose (); }
RFC: https://github.com/eclipse-platform/eclipse.platform.swt/pull/466 I tried to make it configurable to please everyone.
