Dialog requestFileName

I have not tried Holger's patch, but it looks like it fixes what I found this
morning.

The problem is that FileDialog's volumesMenu has MenuItems whose values are
Filenames of disk volumes rather than the string names of disk volumes.  When
you execute #asFilename on a string representing a disk volume, VisualWorks
apparently does something that tries to "touch" the corresponding disk.  And
that can take seconds.  For example:
        'A:\' asFilename
Will take several seconds as the floppy drive is activated and a floppy disk
is not in the drive.  Similarly something like:
        '\\computer\share' asFilename
can take many seconds if the share requires some Windows behind-the-scenes
activity to "fetch" (?) it.

The solution is for volumesMenu to hold the string names of disk volumes
rather than the corresponding Filename objects.  This appears to be what
Holger did.

You will note that FileBrowser was changed in a similar manner somewhere
between VW 7.1 and VW 7.4.

Chris

Vassili Bykov wrote:

Reinout Heeck wrote:
There is truth to that, and it was documented as a warning in 7.2
release notes (Fall 2003). In a nutshell, despite the OFN_NOCHANGEDIR
flag, Microsoft does change the directory while the dialog is open as
you navigate the directories. The flag really means OFN_CHANGEDIRBACKPLEASE.

Note that this is only a feature of Windows-native dialogs. Switching
the preference to using the new Smalltalk-native dialog works around
that. (Uncheck the "Use native dialogs" option on the Tools page of the
Settings).


--- Begin Documentation ---
With the Multiproc UI on Windows, a new freedom has uncovered a
perilous feature in the Windows behavior.

Fact: On Windows platforms, an application that opens a "native"
file selection dialog (a dialog provided by Windows), there is an
unfortunate side effect that the application's current directory
is yanked around in synch with dialog's travels. Fortunately,
Windows does restore the current directory to its original setting
as soon as the dialog is closed. (Via an api option.)

Problem: There are at least two problems that can arrise from
this behavior. First, if an application opens two file dialogs,
the second dialog thinks it should restore whatever was current
when it was opened. Closing the dialogs in reverse order yields
the wrong restored directory.

Second, and far more typical, if your application allows the user
to select a file whilst another part of your application is busy
opening files, the busy process can fail if it uses the "relative
file path", stemming from the current directory. It will fail if
the user has begun looking at a different directory, since the
current directory will track the meanderings of the dialog.

This writer is aware of no workaround for the first problem
besides avoiding multiple native file dialogs at once. But if
your application needs to allow users to select files whilst
another process is busy opening files, then the busy process
needs to use the full file path, rather than a relative path.
This way, it safely ignores the current directory.
--- End Documentation ---



--
Vassili Bykov <[hidden email]>

[:s | s, s printString] value: '[s: | s, s printString] value: '

> There is truth to that, and it was documented as a warning in 7.2
> release notes (Fall 2003). In a nutshell, despite the OFN_NOCHANGEDIR
> flag, Microsoft does change the directory while the dialog is open as
> you navigate the directories. The flag really means
> OFN_CHANGEDIRBACKPLEASE.

ah, my mistake. I just Transcript'ed the defaultFilename and the
currentFilename in a forked process while opening the native file
dialog. They don't change.