bug#13065: Bug in x-file-dialog with GetOpenFileName

[Jason Rumney <jasonr@gnu.org>]

Sorry for the late reply.


Eli Zaretskii <eliz@gnu.org> writes:

>  a) Windows 7 deprecated this kind of dialogs and instead wants us to
>     use some hotshot new ones.  So it could be simply a bug in the
>     implementation of this dialog on Windows 7.

Is it not just a case of doing the same as we did previously?

  /* If we compile with _WIN32_WINNT set to 0x0400 (for NT4
     compatibility) we end up with the old file dialogs. Define a big
     enough struct for the new dialog to trick GetOpenFileName into
     giving us the new dialogs on newer versions of Windows.  */


>  b) We use a file selection dialog in non-standard ways, to be able to
>     open directories, not just files.  The way we do this employs some
>     undocumented tricks which I don't fully understand.  E.g., when
>     the hook gets the CDN_INITDONE notification, we access the File
>     Name field of the dialog, but don't do anything with it, and just
>     call EnableWindow.  Is that really necessary, and if so, why?


The purpose is to disable the File Name field when "Directories" is
selected so the user does not try to type a filename (which will
subsequently be ignored).  "Current Directory" is put into the field
when it is disabled to indicate to the user that the current directory
will be chosen if they press OK.

>
>  c) The filter string uses some "*|*" magic in the directory filter,
>     which doesn't seem to be documented anywhere.  What does it do?

Nothing.  It has to be different than the *.* that is used for normal
file selection, but couldn't be simply * IIRC. The magic is in the
callback function and the code that strips away the filename when the
dialog call has finished if the "Directories" option is selected.

But in this report, the Directory filter was never chosen, so I don't
think it is related.  You could try removing the Directories portion of
the filter string and the callback to be sure.