Windows file open dialog changes default directory

Terry,

We've had to work around this as well, mostly by switching to “ObjectMemory imageDirectory” convention when accessing local resources and using absolute paths everywhere else. The bigger PITA were external interfaces where we ended up with “ObjectMemory imageDirectory beCurrentDirectory” in the startup sequence for library lookup to succeed. It’s a bit of a mess all around, but I believe this behavior is a “feature” of the OS, thus, not much can be done about it from within VisualWorks. There's OFN_NOCHANGEDIR flag for the save dialog on Windows, but it doesn't have any effect for the open dialog, making it quite useless.

http://blogs.msdn.com/b/oldnewthing/archive/2010/11/12/10089878.aspx

http://msdn.microsoft.com/en-us/library/ms646960(v=vs.85).aspx

The dialog box automatically changes your current directory when the user selects a different drive or directory. To prevent the dialog box from changing your current directory, set the OFN_NOCHANGEDIR flag. This flag does not prevent the user from changing directories to find a file.

http://msdn.microsoft.com/en-us/library/ms646839(v=vs.85).aspx

OFN_NOCHANGEDIR - Restores the current directory to its original value if the user changed the directory while searching for files. This flag is ineffective for GetOpenFileName.

HTH,

-Boris

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Terry Raymond
Sent: Wednesday, August 31, 2011 9:11 AM
To: VWNC
Subject: [vwnc] Windows file open dialog changes default directory

We encountered a bug where we were getting a file not found error.

As it turns out, we have a background process that does file I/O.

While the process is running, the user performs an action that opens the windows open file dialog. If the background process attempts to open a file using a relative path and the file dialog is in a different directory, the error occurs.

When the debugger was up, at the same time the open file dialog was up, I printed the result of "Filename findDefaultDirectory".

After closing the file dialog, while the debugger was still open, I printed the expression result again, they were different!!

I should also add, that the directory that the dialog opened in was not the default directory, I did not navigate in the dialog.

Anyway, one would not expect the open file dialog to change the image default directory.

Terry

===========================================================

Terry Raymond

Crafted Smalltalk

80 Lazywood Ln.

Tiverton, RI  02878

(401) 624-4517      [hidden email]

<http://www.craftedsmalltalk.com>

===========================================================

_______________________________________________

vwnc mailing list

[hidden email]

http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We too have corrections for this. It’s actually even worse that Boris says: not only do you have to change back to VW’s default directory at the start of each refresh, you also have to change back to Windows’ default directory at the end of each refresh. Otherwise some operations within the Windows dialog can crash, as the default directory has changed under their feet (IIRC this was in the printer dialog, which uses a similar approach). Also, I don’t think you can assume that the windowManager is non-nil -  see the comment below for cases where it can be nil.

This is what we had as a fix for 7.6 (original Cincom code in bold):

CommonDialogsFilenameRequest>>refreshParentWindow

   ownerWindow ifNotNil: [:window |

        window windowManager ifNotNil: [:wm | "wm can be nil, if the dialog was started from an ApplicationModel that has been partly built but not opened yet: the Window exists, but it is not yet in any WindowManager (and may never be, e.g. if we use #allButOpen*)"

            Filename ensureVWDefaultDirectory. "Windows changes the system default directory while the dialog is open"

            [wm processNonCloseOutstandingEventsFor: window]

                ensure: [Filename ensureOSDefaultDirectory]]]

Filename class>>ensureOSDefaultDirectory

                             "If the remembered OS current directory shared var is not nil, set it as the OS current directory and clear the shared var"

                             LastOSDefaultDirectory ifNotNil: [:osDir |

                                                          osDir beOSCurrentDirectory.

                                                          LastOSDefaultDirectory := nil]

ensureVWDefaultDirectory

                             "If the OS current directory is different from what VW remembered, sets the OS current directory back to VW's value. Sets the LastOSDefaultDirectory shared var to remember the overwritten value, or nil if they were the same, and returns it"

                             | vwDefault |

                             vwDefault := Filename defaultDirectory.

                             LastOSDefaultDirectory := Filename findDefaultDirectory.

                             vwDefault ~= LastOSDefaultDirectory

                                                          ifTrue:                [vwDefault beOSCurrentDirectory]

                                                          ifFalse:               [LastOSDefaultDirectory := nil].

                             ^LastOSDefaultDirectory

Filename>>beOSCurrentDirectory

                             "Set the receiver to be the current directory, without affecting open streams or VW default directory"

                             "Copied from beCurrentDirectory and class setCurrentDirectory:"

                             (self exists and: [self isDirectory]) ifFalse:

                                                          [self error: (#errExistingDirectory << #dialogs >> 'receiver must be an existing directory.')].

                             OSSystemSupport concreteClass new setCurrentDirectory: (self class encodeFilename: self asString).

Looking now I see that in 7.7 the refresh mechanism changed: rather than a loop with a 100ms delay and processing all non-close events, it now processes each event on its own in a loop. That means we need to change directory before and after each individual event, which presumably is going to be a lot slower. I haven’t tried that yet, basically we need to move our #refreshParentWindow additional code into the callAsyncApi: eventProcess.

Another thing to watch out for is that VW sends #setFileMustExist for multiple file selection. Since we can’t guarantee Windows will have the right directory at that point (despite our best efforts), that flag should be turned off otherwise Windows will be upset when it tries to find the (relative) filenames and can’t. Instead, the VW app should check the returned file names.

Steve

So, if I understand what Steve and Boris are saying, then one solution

would be;

1.       always use absolute filenames

2.       don’t even bother with actually changing the OS default directory

3.       Use some other concept of the image’s current directory that would

ensure an attempt to make a relative filename would be converted

to an absolute path.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================

Yes, I’d say that’s the best approach, assuming you can change all existing code that uses relative filenames (yours, Cincom’s, third party).

It does have a performance hit, though: building the long absolute filenames can take up a noticeable amount of time compared to the short relative ones. Hard to believe, I know, but true at least in our case. If your app uses a few dozen files, like our database or VW’s .pst files, it mounts up: all the conversion between VW and platform character set, copying to FileConnections, and the long strings of Windows, e.g.

demo\manager.ab

C:\Documents and Settings\Steven Kelly\My Documents\MetaEdit+ 4.5 Client\demo\manager.ab

Steve

Technically, there’s also the option of disabling native file dialogs on Windows…

Yes, I’d say that’s the best approach, assuming you can change all existing code that uses relative filenames (yours, Cincom’s, third party).

It does have a performance hit, though: building the long absolute filenames can take up a noticeable amount of time compared to the short relative ones. Hard to believe, I know, but true at least in our case. If your app uses a few dozen files, like our database or VW’s .pst files, it mounts up: all the conversion between VW and platform character set, copying to FileConnections, and the long strings of Windows, e.g.

demo\manager.ab

C:\Documents and Settings\Steven Kelly\My Documents\MetaEdit+ 4.5 Client\demo\manager.ab

Steve

Well, you only need to change where a Filename is created, i.e.

#createInstanceNamed: . Also, I created a shared var DefaultDirectoryFilename

which I use to construct the absolute Filename. Added a new method

#beDefaultDirectory, which is to be used in place of #beCurrentDirectory.

I will also create some helper methods to obtain relative file paths.

Terry

===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================