Dialog requestFileName

Hi,

7.4 still has the habit of ignoring the given message when requesting a
filename. Instead, there is some *cough* interesting sniffing code:

looksLikeSaveFileMessage: aString
    | noCaseMessage messages |
    noCaseMessage := aString asLowercase.
    messages := (#saveKeywords << #labels >> 'save\out\write') asString.
    messages := messages tokensBasedOn: $\.
    ^messages contains:
       [:clue |
       (noCaseMessage findString: clue startingAt: 1) ~= 0]

This leads to some odd results:

On a win32 machine (German language)
"Dialog requestFileName: 'Choose heavenly file'"
will open a file dialog with the window title
"Öffnen"

Linux (German)
"Dialog requestFileName: 'Choose heavenly file'"
==> "Open File"

Win32 (German)
"Dialog requestFileName: 'Choose file out of hell'"
==> "Datei speichern unter"

Linux (German)
"Dialog requestFileName: 'Choose file out of hell'"
==> "SaveFile"

Proposal:
- Use the message string as window title, instead of ignoring it
- add new methods without message string to Dialog:
     Dialog requestFilename (which will show the "Open" dialog)
     Dialog requestNewFilename (which will show the "Save as" dialog)

Regards,
Holger

> 7.4 still has the habit of ignoring the given message when requesting a
> filename.

Ah, I just discovered that there is another method which does not ignore
the message:

Dialog requestFileNameWithMessage:default:version:ifFail:for:

Still odd, that all the other 10 methods ignore the message.

Hi Holger,
there are two interfaces to file dialogs. The one you tried is the old
one provided for backward compatibility (so that all tools can use new
file dialogs without any change). And it behaves just as it does in
previous releases.

The new interface is a FileDialog class itself. With that you can do
many things that was not possible before. Changing dialog title is one
of them.
I suggest you to use this interface.

Regards,
Milan Čermák

Holger Kleinsorgen napsal(a):
--
Ing. Milan Čermák
programátor, analytik

[hidden email]

................................................................
e-FRACTAL, s.r.o. => e-business driven company
nám. Míru 15, Praha 2, http://www.e-fractal.cz
tel: 222 512 000, fax: 222 515 000
................................................................

> there are two interfaces to file dialogs. The one you tried is the old
> one provided for backward compatibility (so that all tools can use new
> file dialogs without any change). And it behaves just as it does in
> previous releases.
>
> The new interface is a FileDialog class itself. With that you can do
> many things that was not possible before. Changing dialog title is one
> of them.
> I suggest you to use this interface.

I don't think that it is deprecated, there is no comment or protocol
name indicating this, and it's still in the docs (GUIAppDevGuide):

"To open a file request dialog, send requestFileName: to the Dialog
class, with a string for the label (the argument is ignored by the
Windows file dialog):
Dialog requestFileName: 'Open memory file named...'"

Holger Kleinsorgen wrote:
Milan didn't say the old interface was deprecated. He is right, the old
API behaves the way it does to reconcile the old prompter-based Dialog
API from late 80s and its uses throughout (and outside!) the system with
native file dialogs, and now with new portable dialogs. It's not always
an easy marriage, and the "interesting" code you found is the necessary
evil. If you are attached to the old API, deal with it. To not deal with
it, use the new one.

--
Vassili Bykov <[hidden email]>

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

> Milan didn't say the old interface was deprecated.

Right. But it still sounds like one should not use the old interface
anymore.

 > He is right, the old
> API behaves the way it does to reconcile the old prompter-based Dialog
> API from late 80s and its uses throughout (and outside!) the system with
> native file dialogs, and now with new portable dialogs. It's not always
> an easy marriage, and the "interesting" code you found is the necessary
> evil.

Providing a comment in the old interface and a brief description of the
new interface in the docs would be nice.

Holger Kleinsorgen wrote:
>
> Providing a comment in the old interface and a brief description of the
> new interface in the docs would be nice.

Yep, I guess it's time for the old interface to say it's not the center
of the universe anymore. The new one isn't in the paper docs, but the
code is (I think) pretty well-documented. You can start with the comment
to FileDialog and its subclasses.

Cheers,

--Vassili

--
Vassili Bykov <[hidden email]>

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

Speaking of the new one -- we have a network mounted drive on our
windows XP boxes, and the new
request dialog takes over a minute just to open.  We don't use it.

Vassili Bykov wrote:
--
Dennis Smith                        [hidden email]
Cherniak Software Development Corporation       +1 905.771.7011
400-10 Commerce Valley Dr E                Fax: +1 905.771.6288
Thornhill, ON Canada L3T 7N7    http://www.CherniakSoftware.com

Dennis Smith wrote:

> Speaking of the new one -- we have a network mounted drive on our
> windows XP boxes, and the new
> request dialog takes over a minute just to open.  We don't use it.

Exactly.  The writer of the "new interface" failed to pay attention to the
improvements in the File Browser (available from VisualLauncher / File / File
Browser), which no longer exhibits this unacceptable delay, probably because
it no longer feels compelled to "touch" each disk volume before opening.  (By
the way, having a floppy disk drive also causes delays for the "new
interface".)  This particular bug (and yes, it is a bug) is unacceptable and
needs an immediate patch.

Another thing that is wrong: inextensibility due to hard-coded references to
subclasses of FileDialog.  If I *wanted* to customize FileDialog, I must
override multiple methods to refer to my subclass(es).  *And* I must subclass
not just one class (SimpleDialog) but possibly four (all the subclasses of
FileDialog)!  With the "old interface" I had to make only one subclass of
SimpleDialog and override one method (Dialog class >> dialogSupplier).

Another thing that is wrong: Inability to use the "old interface", even when I
set Dialog.UseOldFilePrompters to true.  Why? Because Cincom broke its own
framework which used Dialog class >> dialogSupplier to get the proper object
(SimpleDialog new) to handle the request.  Methods like Dialog class >>
requestFileNameWithMessage:default:version:ifFail:for: use hard-coded
references to SimpleDialog rather than invoking the #dialogSupplier method.
That means my subclass of SimpleDialog no longer gets called.  If my product
broke backward compatibility like this my customers would scream like crazy.

Another thing that is wrong: The "file types" drop-down list of the "new
interface."  Yeah, there are methods that let me add my types into the list,
but no methods that let me *delete* the default file types that I don't want.
  So my end customers would see Smalltalk-ish file types (*.pst, *.st, etc.)
in the list that are meaningless to them.  Unacceptable.

Chris

Look in the public repository for packages called "Sentinet File Dialog
Types" and "Sentinet File Dialog Types Test". It's a port of a older package
I used to have in previous versions of VisualWorks. I didn't add support to
the new dialog, but the hooks are there and are trivial enough for
interested parties to pick up and finish for me :)

Basic pattern is as follows. You have specific file "types" (gif, txt, mp3)
as well as "groups" (images, documents, audio) as instances of Filetype and
FiletypeSet respectively. Both of them understand #pick: protocol such as,

Filetype gif pick: [Dialog requestFileName: 'Open'].
FiletypeSet developmentSet pick: [Dialog requestFileName: 'Open'].

For more pointers see,

Filetype class>>gif
FiletypeSet class>>developmentSet

This is slightly more convenient than having to fix all the obsolete
protocols. Its also fairly easy to integrate throughout your application
with a few rewrite rules, so that's a bonus.

Feel free to do anything you want with this, but please contribute any
changes that you may make back to the community, maybe one day this or some
form of it will make it into base.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Chris Winemiller [mailto:[hidden email]]
Sent: Wednesday, March 01, 2006 2:16 PM
To: [hidden email]
Subject: Re: Dialog requestFileName

Dennis Smith wrote:

> Speaking of the new one -- we have a network mounted drive on our
> windows XP boxes, and the new
> request dialog takes over a minute just to open.  We don't use it.

Exactly.  The writer of the "new interface" failed to pay attention to the
improvements in the File Browser (available from VisualLauncher / File /
File
Browser), which no longer exhibits this unacceptable delay, probably because

it no longer feels compelled to "touch" each disk volume before opening.
(By
the way, having a floppy disk drive also causes delays for the "new
interface".)  This particular bug (and yes, it is a bug) is unacceptable and

needs an immediate patch.

Another thing that is wrong: inextensibility due to hard-coded references to

subclasses of FileDialog.  If I *wanted* to customize FileDialog, I must
override multiple methods to refer to my subclass(es).  *And* I must
subclass
not just one class (SimpleDialog) but possibly four (all the subclasses of
FileDialog)!  With the "old interface" I had to make only one subclass of
SimpleDialog and override one method (Dialog class >> dialogSupplier).

Another thing that is wrong: Inability to use the "old interface", even when
I
set Dialog.UseOldFilePrompters to true.  Why? Because Cincom broke its own
framework which used Dialog class >> dialogSupplier to get the proper object

(SimpleDialog new) to handle the request.  Methods like Dialog class >>
requestFileNameWithMessage:default:version:ifFail:for: use hard-coded
references to SimpleDialog rather than invoking the #dialogSupplier method.
That means my subclass of SimpleDialog no longer gets called.  If my product

broke backward compatibility like this my customers would scream like crazy.

Another thing that is wrong: The "file types" drop-down list of the "new
interface."  Yeah, there are methods that let me add my types into the list,

but no methods that let me *delete* the default file types that I don't
want.
  So my end customers would see Smalltalk-ish file types (*.pst, *.st, etc.)

in the list that are meaningless to them.  Unacceptable.

Chris

Scratch the part where it says it does not support new dialogs, it most
certainly does :)

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Boris Popov [mailto:[hidden email]]
Sent: Wednesday, March 01, 2006 2:46 PM
To: Chris Winemiller; [hidden email]
Cc: [hidden email]
Subject: RE: Dialog requestFileName

Look in the public repository for packages called "Sentinet File Dialog
Types" and "Sentinet File Dialog Types Test". It's a port of a older package
I used to have in previous versions of VisualWorks. I didn't add support to
the new dialog, but the hooks are there and are trivial enough for
interested parties to pick up and finish for me :)

Basic pattern is as follows. You have specific file "types" (gif, txt, mp3)
as well as "groups" (images, documents, audio) as instances of Filetype and
FiletypeSet respectively. Both of them understand #pick: protocol such as,

Filetype gif pick: [Dialog requestFileName: 'Open'].
FiletypeSet developmentSet pick: [Dialog requestFileName: 'Open'].

For more pointers see,

Filetype class>>gif
FiletypeSet class>>developmentSet

This is slightly more convenient than having to fix all the obsolete
protocols. Its also fairly easy to integrate throughout your application
with a few rewrite rules, so that's a bonus.

Feel free to do anything you want with this, but please contribute any
changes that you may make back to the community, maybe one day this or some
form of it will make it into base.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Chris Winemiller [mailto:[hidden email]]
Sent: Wednesday, March 01, 2006 2:16 PM
To: [hidden email]
Subject: Re: Dialog requestFileName

Dennis Smith wrote:

> Speaking of the new one -- we have a network mounted drive on our
> windows XP boxes, and the new
> request dialog takes over a minute just to open.  We don't use it.

Exactly.  The writer of the "new interface" failed to pay attention to the
improvements in the File Browser (available from VisualLauncher / File /
File
Browser), which no longer exhibits this unacceptable delay, probably because

it no longer feels compelled to "touch" each disk volume before opening.
(By
the way, having a floppy disk drive also causes delays for the "new
interface".)  This particular bug (and yes, it is a bug) is unacceptable and

needs an immediate patch.

Another thing that is wrong: inextensibility due to hard-coded references to

subclasses of FileDialog.  If I *wanted* to customize FileDialog, I must
override multiple methods to refer to my subclass(es).  *And* I must
subclass
not just one class (SimpleDialog) but possibly four (all the subclasses of
FileDialog)!  With the "old interface" I had to make only one subclass of
SimpleDialog and override one method (Dialog class >> dialogSupplier).

Another thing that is wrong: Inability to use the "old interface", even when
I
set Dialog.UseOldFilePrompters to true.  Why? Because Cincom broke its own
framework which used Dialog class >> dialogSupplier to get the proper object

(SimpleDialog new) to handle the request.  Methods like Dialog class >>
requestFileNameWithMessage:default:version:ifFail:for: use hard-coded
references to SimpleDialog rather than invoking the #dialogSupplier method.
That means my subclass of SimpleDialog no longer gets called.  If my product

broke backward compatibility like this my customers would scream like crazy.

Another thing that is wrong: The "file types" drop-down list of the "new
interface."  Yeah, there are methods that let me add my types into the list,

but no methods that let me *delete* the default file types that I don't
want.
  So my end customers would see Smalltalk-ish file types (*.pst, *.st, etc.)

in the list that are meaningless to them.  Unacceptable.

Chris

Chris Winemiller wrote:

> Another thing that is wrong: inextensibility due to hard-coded
> references to subclasses of FileDialog. If I *wanted* to customize
 > FileDialog, I must override multiple methods to refer to my
 > subclass(es).

Not true. Subclasses of FileDialog are factories. As they are now, they
create either portable dialogs or Win32 surrogate, depending on the
context. To substitute your own classes, you make them instantiate them
instead of the stock dialogs. Methods are not all API is about--classes
are API too!

> Another thing that is wrong: The "file types" drop-down list of the "new
> interface."  Yeah, there are methods that let me add my types into the
> list, but no methods that let me *delete* the default file types that I
> don't want.  So my end customers would see Smalltalk-ish file types
> (*.pst, *.st, etc.) in the list that are meaningless to them.

You dont' need a delete method. A newly created file dialog starts off
with an empty type list. You populate it with the filters you want.
Smalltalk-specific filters are only present in dialogs opened using the
old interface in Dialog, just as they were present in Windows-native
dialogs opened using that interface ever since version 5i.3.




--
Vassili Bykov <[hidden email]>

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

Can I suggest an improvement? ;)

<shameless plug>

I'd still prefer to do something along the lines of,

FiletypeSet cDevelopment pick: [OpenFileDialog open]

instead of,

| dialog |
dialog := OpenFileDialog new.
dialog
 addFileFilter: 'C source (*.c)' pattern: '*.c';
 addFileFilter: 'C++ source (*.cc;*.cpp)' pattern: '*.cc;*.cpp';
 addFileFilter: 'C header (*.h)' pattern: '*.h';
 addFilterForAllFiles;
 fileCondition: #any.
^dialog open
  ifTrue: [dialog selection]
  ifFalse: [nil]

</shameless plug>

Admittedly, people can factor their code to re-use various addFileFilter
cascades, but it'd be nice if OOish API was included out of the box.

Cheers!

-Boris

--
+1.604.689.0322
DeepCove Labs Ltd.
4th floor 595 Howe Street
Vancouver, Canada V6C 2T5

[hidden email]

CONFIDENTIALITY NOTICE

This email is intended only for the persons named in the message
header. Unless otherwise indicated, it contains information that is
private and confidential. If you have received it in error, please
notify the sender and delete the entire message including any
attachments.

Thank you.

-----Original Message-----
From: Vassili Bykov [mailto:[hidden email]]
Sent: Wednesday, March 01, 2006 5:32 PM
To: [hidden email]
Subject: Re: Dialog requestFileName

Chris Winemiller wrote:

> Another thing that is wrong: inextensibility due to hard-coded
> references to subclasses of FileDialog. If I *wanted* to customize
 > FileDialog, I must override multiple methods to refer to my
 > subclass(es).

Not true. Subclasses of FileDialog are factories. As they are now, they
create either portable dialogs or Win32 surrogate, depending on the
context. To substitute your own classes, you make them instantiate them
instead of the stock dialogs. Methods are not all API is about--classes
are API too!

> Another thing that is wrong: The "file types" drop-down list of the "new
> interface."  Yeah, there are methods that let me add my types into the
> list, but no methods that let me *delete* the default file types that I
> don't want.  So my end customers would see Smalltalk-ish file types
> (*.pst, *.st, etc.) in the list that are meaningless to them.

You dont' need a delete method. A newly created file dialog starts off
with an empty type list. You populate it with the filters you want.
Smalltalk-specific filters are only present in dialogs opened using the
old interface in Dialog, just as they were present in Windows-native
dialogs opened using that interface ever since version 5i.3.



--
Vassili Bykov <[hidden email]>

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

Hi Boris,

I have nothing against creativity of course but here is how I see this.

I don't see anything inherently non-OO in a cascade of messages, and I
think it's more precise to describe the alternative not as "adding OO"
but rather as adding abstraction. I couldn't possibly write here such an
engaging overview of it as Richard Gabriel in his Abstraction Descant,
so I'll only refer to it (it's a chapter in his Patterns of Software
published some 10 years ago).

He talks how abstractions reduce what he calls "habitability" of
software. The more heavily abstractions are used in composition, the
more effort and time it takes for a newcomer to learn and internalize
them. You don't have to share his negative stance to quite the same
degree (I don't), but abstractions do carry cognitive cost. So, is the
value of hiding a few filename wildcards behind what is essentially a
new language construct high enough to offset the costs?

I always say that APIs are user interfaces and it makes sense to talk
about usability in that context. Consider the usability of the two
approaches, in how close each of them matches the typical user's mental
model. When you look at a class library for a way to open a dialog to
request the name of a file to open, what name will capture your
attention as the potential solution: OpenFileDialog or FiletypeSet? And,
once you find OpenFileDialog, are you likely to go off looking for a
policy class that will populate it for you with filename extensions, or
will you consider that such an easy task you won't even think to look
for a pre-packaged solution?

Cheers,

--Vassili

Vassili Bykov wrote:
That's fair and I did mention I'm not particularly attached to the
concept described in my previous emails. It worked quite well in the old
world that had gazillion various selectors for what was essentially a
single point of functionality by allowing one to configure file types in
the dialogs without adding another gazillion equivalent selectors with
an extra parameter.

I guess what I was aiming towards by bringing this up is my longing for
a framework that encourages users to define file types, which are
combinations of a textual description and equivalent extension(s) as
well as functional groups, such as images, audio, video not via
repeating copy-and-paste cascades, but rather as objects. Certainly
there's nothing subjectively wrong about the approach new file dialogs
use at the moment, but I feel that there's still a step we can take to
bring this up a notch. Lets consider various Icon libraries that you've
added to VisualWorks in somewhat recent past. Prior to them being in
place, people were used to coding images and masks in their classes
throughout the application and certainly they didn't mind creating
methods that composed the two together and returned transparent images
for use in UI models. I remember very well wishing there was someplace
that took care of all the issues I had to deal with over and over and
over again at the time. Please welcome IconLibraries, classes that do
the right thing as long as you simply add your images and masks to them
with a predefined yet simple and understandable selector format. You
always know where to find your resources and changes to the defining
methods are always reflected anywhere you happen to reference that image
via the proper protocol. Now imagine a real world application, say a
text editor, that has to deal with a multitude of various file dialogs
to edit files, compare files, compile files, email files etc. Those are
all file dialogs and I can bet that sooner or later you'll see people
coping and pasting the following every time they need to open some kind
of C file:

| dialog |
dialog := OpenFileDialog new.
dialog
  addFileFilter: 'C source (*.c)' pattern: '*.c';
  addFileFilter: 'C++ source (*.cc;*.cpp)' pattern: '*.cc;*.cpp';
  addFileFilter: 'C header (*.h)' pattern: '*.h';
  addFilterForAllFiles;
  fileCondition: #any.
^dialog open
   ifTrue: [dialog selection]
   ifFalse: [nil]

Its not just because people aren't trying to reuse, its mostly because a
convenient way of reuse isn't readily exposed and available. How
inconceivable is it that at some point in the future, someone decides
that '*.hdr' is a perfectly valid extension for a C header file.
Wouldn't you agree that changing something like a single "definition" of
a C header file type from,

cHeader
   ^self description: 'C Header' extension: '*.h'

to,

cHeader
  ^self description: 'C Header' extensions: #('*.h' '*.hdr')

is much nicer way of introducing change than it is to search all methods
for various spellings of 'C Header' or look at all senders of
#addFileFilter: to see where you may need to add a new pattern?

Or say adding a new image format to all supported image formats by
changing a group "definition" from,

supportedImageTypes
   ^self with: Filetype png with: Filetype jpg

to,

supportedImageTypes
   ^self with: Filetype png with: Filetype jpg with: Filetype gif

Like I said, I very much see your point that my suggested protocol may
not be the most obvious thing for the user, and I agree. It did fine for
what it was supposed to do, but so long as the issues I outlined above
are addressed on some level, I'd be all for whatever new approach you
may decide on. So far everything you've done to VisualWorks tools and
frameworks has been no less than exceptional, so don't take everything I
suggest literally and feel free to elaborate and change as much as you'd
like.

That's my C$0.02 anyway ;)

Cheers!

-Boris

Dennis Smith wrote:
> Speaking of the new one -- we have a network mounted drive on our
> windows XP boxes, and the new
> request dialog takes over a minute just to open.  We don't use it.

And it has a nice M$ twist:
the current working directory of the image changes while this dialog is in
use. Other threads manipulating files can get confused by this 'feature'...


R
-

Reinout Heeck wrote:
I just test the FileDialog on Win2000 and WinXP and I'm not able to
reproduce it.
To dialog slowness on network drives: I don't see any slowdown. Dennis,
can you send me piece of code which demonstrates that? How is the drive
"mounted"?
To current directory changes: I tried following code in workspace:

     Filename defaultDirectory (print it)
     FileDialog openFileExample (do it)
     (choose file from different directory or drive)
     Filename defaultDirectory (print it)

In both cases #defaultDirectory returned same result.
Reinout, can you tell me how did you found out?
One thing might confuse you. The dialog remembers last chosen directory
(or the directory from which the file was chosen).

Milan Čermák

Milan Čermák wrote:
> Reinout Heeck wrote:
>> And it has a nice M$ twist:
>> the current working directory of the image changes while this dialog
>> is in use. Other threads manipulating files can get confused by this
>> 'feature'...
>
>
> I just test the FileDialog on Win2000 and WinXP and I'm not able to
> reproduce it.

The Win32 file dialog sets the OFN_NOCHANGEDIR, so it should not change
the current directory. I could not reproduce it, too.

About the speed:
It does not take a minute in our network environment to open the
non-native dialog, but still a few seconds. I've made a quick patch to
improve the startup speed. Haven't tested if it breaks anything else.

<?xml version="1.0"?>

<st-source>
<!--
Name: FileDialogPatch
DbIdentifier: nil
DbTrace: nil
PackageName: FileDialogPatch
Parcel: #('FileDialogPatch')
PrintStringCache: nil
Date: 2:50:19 pm March 2, 2006
 -->
<time-stamp>From VisualWorks®, 7.4 of Montag, 5. Dezember 2005 on Donnerstag, 2. März 2006 at  14:50:19</time-stamp>


<do-it>(Dialog confirm: 'You are filing-in a Parcel source file!\\While this is possible it will not have\the same effect as loading the parcel.\None of the Parcel''s prerequisites will\be loaded and none of its load actions\will be performed.\\Are you sure you want to file-in?' withCRs) ifFalse: [self error: 'Parcel file-in abandoned.  Choose terminate or close.']</do-it>

<methods>
<class-id>Tools.FileDialog</class-id> <category>private</category>

<body package="FileDialogPatch" selector="currentDirectoryContent">currentDirectoryContent

        | content directory |
        directory := self directoryHolder value.
        ^[content := directory directoryContents.
        content := content collect: [:string | directory constructSafe: string].
                "Names with invalid characters may produce Filenames that appear not to exist.
                Observed under OSX with a filename containing a CR."
        content := content select: [:some | some exists].
        self showHiddenHolder value
                ifFalse: [content := content reject: [:filename | filename isHidden]].
        content := self filterFilenames: content.
        self resortList: content]
                on: OsIllegalOperation, OSErrorHolder nonexistentSignal, OSErrorHolder invalidArgumentsSignal
                do: [:ex | | errorHolder | "Inaccessible volume; can happen in Windows."
                        errorHolder := ex parameter.
                        self reportFileError: errorHolder.
                        ex return: List new]</body>
</methods>

<methods>
<class-id>Tools.FileDialog</class-id> <category>aspects</category>

<body package="FileDialogPatch" selector="directoryHolder">directoryHolder

        | valueHolder |
        directoryHolder isNil
                ifTrue:
                [ valueHolder := ValueHolder with: Filename new.
                        directoryHolder := ( PluggableAdaptor on: valueHolder )
                                getBlock: [: m | m value ]
                                putBlock: [: m : v | m value: v asFilename ]
                                updateBlock: [: m : a : p | false ]
                ].
        ^ directoryHolder</body>
</methods>

<methods>
<class-id>Tools.FileDialog</class-id> <category>private</category>

<body package="FileDialogPatch" selector="reportFileError:">reportFileError: aFileErrorHolder

        | filename text |
        filename := aFileErrorHolder filename.
        text := filename asString, ': ', (aFileErrorHolder errorReporter errorDescriptionFor: aFileErrorHolder errorCode).
        "Make a nicer notice for known errors."
        (#(21 87) includes: aFileErrorHolder errorCode) "ERROR_NOT_READY or ERROR_INVALID_PARAMETER "
                ifTrue: [text := #Drive1SNotReady &lt;&lt; #dialogs &gt;&gt; 'Drive &lt;1s&gt; is not ready.' expandMacrosWith: filename volume].
        Dialog warn: text</body>

<body package="FileDialogPatch" selector="volumesMenu">volumesMenu

        ^volumesMenu ifNil:
                [volumesMenu := Menu new.
                Filename volumes do:
                        [:each | | item |
                        item := MenuItem labeled: each.
                        item
                                labelImage: (ListIconLibrary visualFor: #hardDrive);
                                value: each.
                        volumesMenu addItem: item].
                volumesMenu]</body>
</methods>

<do-it>"Imported Classes:"</do-it>

<do-it>self error: 'Attempting to file-in parcel imports.  Choose terminate or close'</do-it>

<class>
<name>FileDialog</name>
<environment>Tools</environment>
<super>UI.SimpleDialog</super>
<private>false</private>
<indexed-type>none</indexed-type>
<inst-vars>windowTitle acceptButtonLabel defaultExtension volumesMenu directoryHolder fileListHolder filenameHolder showHiddenHolder fileSelectionTailHolder fileFilters fileFilterHolder sortSelectorHolder fileFiltersMenuHolder fileCondition </inst-vars>
<class-inst-vars>lastDirectory </class-inst-vars>
<imports></imports>
<category>UIApplications-New</category>
<attributes>
<package>Tools-Dialogs</package>
</attributes>
</class>

</st-source>

Holger Kleinsorgen wrote:
> Milan Čermák wrote:
> > Reinout Heeck wrote:
> >> And it has a nice M$ twist:
> >> the current working directory of the image changes while this dialog
> >> is in use. Other threads manipulating files can get confused by this
> >> 'feature'...
> >
> > I just test the FileDialog on Win2000 and WinXP and I'm not able to
> > reproduce it.

Hmm, I'll check my facts...


>
> The Win32 file dialog sets the OFN_NOCHANGEDIR, so it should not change
> the current directory. I could not reproduce it, too.
>
> About the speed:
> It does not take a minute in our network environment to open the
> non-native dialog, but still a few seconds. I've made a quick patch to
> improve the startup speed. Haven't tested if it breaks anything else.

Holger Kleinsorgen wrote:
> About the speed:
> It does not take a minute in our network environment to open the
> non-native dialog, but still a few seconds. I've made a quick patch to
> improve the startup speed. Haven't tested if it breaks anything else.

It doesn't break the unit tests. Can the people who complained about the
speed please try Holger's patch and say if it helps?

--
Vassili Bykov <[hidden email]>

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