GNU bug report logs - #13065
Bug in x-file-dialog with GetOpenFileName

Previous Next

Packages: emacs, w32;

Reported by: Du Yanning <duyanning <at> gmail.com>

Date: Mon, 3 Dec 2012 11:13:02 UTC

Severity: normal

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #8 received at 13065 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Du Yanning <duyanning <at> gmail.com>, jasonr <at> gnu.org
Cc: 13065 <at> debbugs.gnu.org
Subject: Re: bug#13065: Bug in x-file-dialog with GetOpenFileName
Date: Tue, 04 Dec 2012 21:10:39 +0200
> Date: Mon, 3 Dec 2012 19:09:49 +0800
> From: Du Yanning <duyanning <at> gmail.com>
> 
> Platform: Windows 7
> Emacs version: 24.2.1
> 
> Steps to reproduce this bug:
> emacs -Q
> 
> copy and paste the next line into the *scratch* buffer:
> (x-file-dialog "hi" "c:\\")
> 
> C-x C-e to evaluate it.
> The dialog appears.
> 
> Type "abc" (without the enclosing double quotes) in the "File name" field.
> Click the "Desktop" icon on the left side of the dialog.
> Click the "Open" button.
> The dialog does NOT disappear while it should.

This works fine on XP.  On Windows 7, I indeed see the problem, and it
seems to be related to any action in the dialog that changes the
original directory, which results in receiving in the dialog hook
procedure of the CDN_FOLDERCHANGE and CDN_SELCHANGE notifications
(which we don't handle).  If you just type "abc" and click "Open", the
dialog works as expected.  It also works if you do change to another
directory and select an existing file.

> I have tried GetOpenFileName/GetSaveFileName in my own Win32 programs and
> found that this behavior is casued by GetOpenFileName and GetSaveFileName
> is OK in such situation.

GetSaveFileName only works with existing files, which might explain
why it works where GetOpenFileName fails.

I tried to get this to work on Windows 7, or at least figure out why
it doesn't, but came up empty-handed.  Which is not surprising, since
I know absolutely nothing about Windows GUI dialogs in general, and
this dialog in particular.  It doesn't particularly help that:

 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.

 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?

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

I CC Jason, who is the author of this code, in the hope that he will
be able to give some advice.  Failing that, I really don't know what
to do to fix this.  Ideas and advice will be most appreciated.




This bug report was last modified 12 years and 183 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.