GNU bug report logs - #8181
23.2; Dired on Windows 7

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 8181 in the body.
You can then email your comments to 8181 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: "Robert I. Eachus" <rieachus <at> comcast.net>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.2; Dired on Windows 7
Date: Sat, 05 Mar 2011 17:55:25 -0500

Choosing Open Directory from the File menu opens a standard (Windows 7)
window that allows you to walk the directory tree, but there is no way
to open a directory in dired mode that I can find.  Cx d on the other
hand opens an emacs buffer in dired mode. (Normal behavior)


In GNU Emacs 23.2.1 (i386-mingw-nt6.1.7600)
 of 2010-05-08 on G41R2F1
Windowing system distributor `Microsoft Corp.', version 6.1.7600
configured using `configure --with-gcc (3.4) --no-opt --cflags 
-Ic:/xpm/include'

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1252
  default enable-multibyte-characters: t

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <menu-bar> <file>
<split-window> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <menu-bar> <file> <open-file> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1>
<mouse-1> <mouse-1> <mouse-1> <help-echo> <help-echo>
<help-echo> <menu-bar> <file> <open-file> <wheel-down>
<double-wheel-down> <wheel-down> <double-wheel-down>
<wheel-down> <wheel-down> <wheel-down> <wheel-down>
<wheel-down> <wheel-down> <wheel-down> <wheel-down>
<wheel-down> <wheel-down> <wheel-down> <wheel-down>
<wheel-down> <wheel-down> <wheel-down> <wheel-down>
<wheel-down> <wheel-down> <wheel-down> <double-wheel-down>
<wheel-down> <wheel-down> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <menu-bar> <help-menu>
<getting-new-versions> <wheel-down> <wheel-down> <double-wheel-down>
<triple-wheel-down> <triple-wheel-down> <wheel-down>
<double-wheel-down> <triple-wheel-down> <triple-wheel-down>
<triple-wheel-down> <wheel-up> <double-wheel-up> <triple-wheel-up>
<triple-wheel-up> <wheel-down> <double-wheel-down>
<triple-wheel-down> <triple-wheel-down> <wheel-up>
<double-wheel-up> <wheel-up> <double-wheel-up> <triple-wheel-up>
<triple-wheel-up> <wheel-up> <wheel-down> <wheel-up>
<double-wheel-up> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<help-echo> <menu-bar> <help-menu> <about-emacs> <help-echo>
<wheel-down> <help-echo> <wheel-up> <help-echo> <help-echo>
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo>
<menu-bar> <file> <dired> <help-echo> <help-echo> <wheel-down>
<double-wheel-down> <wheel-up> <help-echo> <wheel-up>
<double-wheel-up> <triple-wheel-up> <wheel-down> <help-echo>
<wheel-up> <double-wheel-up> <triple-wheel-up> <triple-wheel-up>
<wheel-up> <double-wheel-up> <triple-wheel-up> <triple-wheel-up>
<help-echo> <help-echo> <escape> x r e p SPC o r SPC
e SPC SPC <return>

Recent messages:
Indentation variables are now local.
Indentation setup for shell type sh
scroll-bar-toolkit-scroll: End of buffer [10 times]
Quit
View mode: type C-h for help, h for commands, q to quit.
byte-code: End of buffer
For information about GNU Emacs and the GNU system, type C-h C-a.
Quit
byte-code: Beginning of buffer
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse rfc2231
rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util netrc
time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock sha1
hex-util hashcash mail-utils emacsbug help-mode goto-addr thingatpt view
sgml-mode sh-script executable autoconf autoconf-mode conf-mode
newcomment dired cc-mode cc-fonts easymenu cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs regexp-opt tooltip ediff-hook
vc-hooks lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win
w32-vars tool-bar dnd fontset image fringe lisp-mode register page
menu-bar rfn-eshadow timer select scroll-bar mldrag mouse jit-lock
font-lock syntax facemenu font-core frame cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese hebrew
greek romanian slovak czech european ethiopic indian cyrillic chinese
case-table epa-hook jka-cmpr-hook help simple abbrev loaddefs button
minibuffer faces cus-face files text-properties overlay md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: "Robert I. Eachus" <rieachus <at> comcast.net>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Sun, 6 Mar 2011 01:08:04 +0100

On Sat, Mar 5, 2011 at 11:55 PM, Robert I. Eachus <rieachus <at> comcast.net> wrote:
> Choosing Open Directory from the File menu opens a standard (Windows 7)
> window that allows you to walk the directory tree, but there is no way
> to open a directory in dired mode that I can find.  Cx d on the other
> hand opens an emacs buffer in dired mode. (Normal behavior)

See `use-file-dialog'.

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

From: "Robert I. Eachus" <rieachus <at> comcast.net>
To: Lennart Borgman <lennart.borgman <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Sat, 05 Mar 2011 19:40:34 -0500

On 3/5/2011 7:08 PM, Lennart Borgman wrote:
> On Sat, Mar 5, 2011 at 11:55 PM, Robert I. Eachus<rieachus <at> comcast.net>  wrote:
>> Choosing Open Directory from the File menu opens a standard (Windows 7)
>> window that allows you to walk the directory tree, but there is no way
>> to open a directory in dired mode that I can find.  Cx d on the other
>> hand opens an emacs buffer in dired mode. (Normal behavior)
> See `use-file-dialog'

Thanks for the quick answer, but I think you may be missing the point.  
First the File menu choice Open Directory, says that the keyboard 
equivalent is C-x d.  But the two are completely different in behavior.  
Second, if you do use the menu option, there is no way to select a 
directory, even though you can navigate through them.

I ran into this by accident, browsing through a large C source library.  
I used Cx d nine times (or a dozen) before I went to use the menu since 
I had a cup in my left hand.  I then wanted to see if I would get a 
dired buffer when I selected a directory, but instead I found that there 
is either no way to select a directory, or the choice gets silently lost.

It is not a big deal for me. Even if I am drinking something hot,  I can 
type Cx d with my right hand.  If nothing gets done I may submit a fix 
sometime when I am not in the process of digesting the source of a 
different application.

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

From: Lennart Borgman <lennart.borgman <at> gmail.com>
To: "Robert I. Eachus" <rieachus <at> comcast.net>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Sun, 6 Mar 2011 01:42:36 +0100

On Sun, Mar 6, 2011 at 1:40 AM, Robert I. Eachus <rieachus <at> comcast.net> wrote:
>
> Thanks for the quick answer, but I think you may be missing the point.

Oh, sorry.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: "Robert I. Eachus" <rieachus <at> comcast.net>
Cc: Lennart Borgman <lennart.borgman <at> gmail.com>, 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Sun, 6 Mar 2011 04:30:25 +0100

On Sun, Mar 6, 2011 at 01:40, Robert I. Eachus <rieachus <at> comcast.net> wrote:

>  Second, if you do use the menu option, there is no way to select a
> directory, even though you can navigate through them.

Try doing File / OpenDirectory, then in the File Types combo below
select All Files, then Directories again. The Name selection box will
say "Current Directory", and you can now Open the current dir.

If you're curious, this is implemented in file_dialog_callback
(src/w32fns.c:5860).

I'm not yet sure whether the fact that "Current Directory" is not
initially shown is a bug or a limitation of the Windows dialog. Do you
now whether it also happens on XP?

    Juanma

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: "Robert I. Eachus" <rieachus <at> comcast.net>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Sun, 6 Mar 2011 14:14:26 +0100

On Sat, Mar 5, 2011 at 23:55, Robert I. Eachus <rieachus <at> comcast.net> wrote:
> Choosing Open Directory from the File menu opens a standard (Windows 7)
> window that allows you to walk the directory tree, but there is no way
> to open a directory in dired mode that I can find.  Cx d on the other
> hand opens an emacs buffer in dired mode. (Normal behavior)
>

I tested this on Windows XP (2011-02-28 published binaries). The
behavior seems to be this: You have to navigate through the directory
tree until you are _inside_ the directory you want to open in dired.
Then simply click "Open" (yes, even though there isn't anything
selected).

FWIW, this doesn't seems too clean to me. IMO, It would be more
intuitive to be able to select the directory you want to open, and
then click "Open".


Regards,

-- 
Dani Moncayo

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: rieachus <at> comcast.net, 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Sun, 06 Mar 2011 09:17:06 -0500

> Date: Sun, 6 Mar 2011 14:14:26 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: 8181 <at> debbugs.gnu.org
> 
> I tested this on Windows XP (2011-02-28 published binaries). The
> behavior seems to be this: You have to navigate through the directory
> tree until you are _inside_ the directory you want to open in dired.
> Then simply click "Open" (yes, even though there isn't anything
> selected).

Yes.

> FWIW, this doesn't seems too clean to me. IMO, It would be more
> intuitive to be able to select the directory you want to open, and
> then click "Open".

Tell this to Microsoft.  AFAIK, this is a limitation of their
file/directory selection dialog.

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

From: Ben Key <bkey76 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: bug#8181: 23.2; Dired on Windows 7
Date: Sun, 6 Mar 2011 10:04:47 -0600

[Message part 1 (text/plain, inline)]

Hello,

I consider the fact that it is necessary to change the selected item in the
"Files of Type" combo box to "All Files (*.*)" and back to "Directories"
before you can successfully select a directory (at least on Windows 7) to be
a bug.  I am looking into this problem and will attempt to fix it.

By the way, does anyone know why we do not use SHBrowseForFolder if
only_dir_p is non nil instead of GetOpenFileName?  In my opinion,
SHBrowseForFolder
provides a much cleaner interface for browsing for an existing folder name
than GetOpenFileName.  I know that the online version of the MSDN Library
claims that Windows XP is required for SHBrowseForFolder but according to
the MSDN Library that ships with Visual Studio 2005 the minimum supported
operating system is Windows NT 4.0 and Windows 95.

[Message part 2 (text/html, inline)]

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Ben Key <bkey76 <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Sun, 6 Mar 2011 21:28:48 +0100

On Sun, Mar 6, 2011 at 17:04, Ben Key <bkey76 <at> gmail.com> wrote:

> I consider the fact that it is necessary to change the selected item in the
> "Files of Type" combo box to "All Files (*.*)" and back to "Directories"
> before you can successfully select a directory (at least on Windows 7) to be
> a bug.

It is definitely a bug, yes. Or perhaps two; I've been stepping
through file_dialog_callback and I see two problems.

One is the fact that the initial setting of FILE_NAME_TEXT_FIELD does
not work. WM_NOTIFY is received with the appropriate arguments, and
CommDlg_OpenSave_SetControlText (at w32fns.c:5875) is called, but it
apparently has no effect. Perhaps some order-of-initialization issue
that's changed (undocumentedly) on Windows 7?

The other is that GetDlgItem (dialog, FILE_NAME_TEXT_FIELD) is
returning always 0, so the EnableWindow calls are no-ops (in fact,
that's easy to see because after setting the combo to "Directories",
you can still edit the text field).

I'm seeing these problems in Windows 7 SP1 64-bit, BTW.

    Juanma

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Ben Key <bkey76 <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 06:37:45 +0100

On Mon, Mar 7, 2011 at 05:15, Ben Key <bkey76 <at> gmail.com> wrote:

> The attached patch fixes bug #8181: 23.2; Dired on Windows 7.

Thanks.

> The code that was attempting to set the text of the file name text field
> when processing the CDN_INITDONE WM_NOTIFY message does not work.  This is
> because the code that processes the lpstrFile member of the OPENFILENAME
> structure to set the initial value of the window is called after the
> CDN_INITDONE WM_NOTIFY message is processed.  The correct way to set the
> text of the file name text field to "Current Directory" is to set the
> initial value of the lpstrFile member of the OPENFILENAME structure to
> "Current Directory" in the only_dir_p case if it does not already have
> another value.

There's no need to duplicate the code in both branches of "if (STRINGP
(default_filename))"; "Current Directory" is shorter than MAX_PATH, so
there are no worries about buffer overflow. You can just add

  /* The code in file_dialog_callback that attempts to set the text
     of the file name edit window when handling the CDN_INITDONE
     WM_NOTIFY message does not work.  Setting filename to "Current
     Directory" in the only_dir_p case here does work however.  */
  if (filename[0] == 0 && ! NILP (only_dir_p))
    strcpy (filename, "Current Directory");

afterwards.

> The attempt to find the window handle of the file name text field failed, at
> least on Windows XP and Windows 7.  By using Microsoft Spy++ I was able to
> discover the correct way to obtain this Window handle.  I modified the code
> in file_dialog_callback that initializes the edit_control using this
> information.

Having to go fishing for the window handles is hackish, but not your
fault, but Microsoft's. Unless someone knows of a better way, that's
what we're stuck with.

> My solution was to set focus to the list box if the
> file name text field is disabled during dialog box initialization.  This
> part could use a little more work.

I don't see anything wrong with this.

Here's your patch, slighty reworked to be more on line with current
Emacs coding conventions (the "0 == X" and "NULL == X" styles are not
frequently used) and with a proposed ChangeLog entry (feel free to
rewrite it, of course).

    Juanma



2011-03-07  Ben Key  <bkey76 <at> gmail.com>

	* w32fns.c (FILE_NAME_COMBO_BOX, FILE_NAME_LIST): Define.
	(file_dialog_callback): Fix locating the window handle of the File Name
	text field.  After disabling it, set focus on the list control.
	(Fx_file_dialog): If only_dir_p is non-nil, set the text of the File
	Name text field to "Current Directory" if it does not already have
	another value.  (Bug#8181)


=== modified file 'src/w32fns.c'
--- src/w32fns.c	2011-02-16 18:39:46 +0000
+++ src/w32fns.c	2011-03-07 05:01:46 +0000
@@ -60,6 +60,8 @@
 #include <dlgs.h>
 #include <imm.h>
 #define FILE_NAME_TEXT_FIELD edt1
+#define FILE_NAME_COMBO_BOX cmb13
+#define FILE_NAME_LIST lst1

 #include "font.h"
 #include "w32font.h"
@@ -5868,13 +5870,37 @@
 	{
 	  HWND dialog = GetParent (hwnd);
 	  HWND edit_control = GetDlgItem (dialog, FILE_NAME_TEXT_FIELD);
-
-	  /* Directories is in index 2.  */
+	  HWND list = GetDlgItem (dialog, FILE_NAME_LIST);
+
+	  /* At least on Windows 7, the above attempt to get the window handle
+	     to the File Name Text Field fails.	 The following code does the
+	     job though.  Note that this code is based on my examination of the
+	     window hierarchy using Microsoft Spy++.  bk */
+	  if (edit_control == NULL)
+	    {
+	      HWND tmp = GetDlgItem (dialog, FILE_NAME_COMBO_BOX);
+	      if (tmp)
+		{
+		  tmp = GetWindow (tmp, GW_CHILD);
+		  if (tmp)
+		    edit_control = GetWindow (tmp, GW_CHILD);
+		}
+	    }
+
+	  /* Directories is in index 2.	 */
 	  if (notify->lpOFN->nFilterIndex == 2)
 	    {
 	      CommDlg_OpenSave_SetControlText (dialog, FILE_NAME_TEXT_FIELD,
 					       "Current Directory");
 	      EnableWindow (edit_control, FALSE);
+	      /* Note that at least on Windows 7, the above call to EnableWindow
+		 disables the window that would ordinarily have focus.	If we
+		 do not set focus to some other window here, focus will land in
+		 no man's land and the user will be unable to tab through the
+		 dialog box (pressing tab will only result in a beep).
+		 Avoid that problem by setting focus to the list here.	*/
+	      if (CDN_INITDONE == notify->hdr.code)
+		SetFocus (list);
 	    }
 	  else
 	    {
@@ -5951,6 +5977,13 @@
   else
     filename[0] = '\0';

+  /* The code in file_dialog_callback that attempts to set the text
+     of the file name edit window when handling the CDN_INITDONE
+     WM_NOTIFY message does not work.  Setting filename to "Current
+     Directory" in the only_dir_p case here does work however.  */
+  if (filename[0] == 0 && ! NILP (only_dir_p))
+    strcpy (filename, "Current Directory");
+
   {
     NEWOPENFILENAME new_file_details;
     BOOL file_opened = FALSE;

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: "Robert I. Eachus" <rieachus <at> comcast.net>, 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Mon, 07 Mar 2011 22:19:13 +0800

Juanma Barranquero <lekktu <at> gmail.com> writes:

> I'm not yet sure whether the fact that "Current Directory" is not
> initially shown is a bug or a limitation of the Windows dialog. Do you
> now whether it also happens on XP?

Current Directory is initially shown for me on Windows XP SP3.

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Ben Key <bkey76 <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Mon, 07 Mar 2011 22:28:37 +0800

Ben Key <bkey76 <at> gmail.com> writes:

> Hello,
>
> I consider the fact that it is necessary to change the selected item
> in the "Files of Type" combo box to "All Files (*.*)" and back to
> "Directories" before you can successfully select a directory (at least
> on Windows 7) to be a bug.  I am looking into this problem and will
> attempt to fix it.

Yes, if you have to do that on Windows 7, then something needs
fixing. It isn't neccesary on Windows XP or earlier versions of Windows.

> By the way, does anyone know why we do not use SHBrowseForFolder if
> only_dir_p is non nil instead of GetOpenFileName?

IIRC it had its own problems, such as not being able to open
non-existing files (even if used only for directories, the standard file
dialog at least allows you to create directories inside the dialog).  It
also seemed a bit clumsy and left behind from an earlier version of
Windows, but things may have changed since the dialog support was first
added. I'm not aware of any other programs that use it, so it doesn't
have the benefit of being familiar to Windows users that the file dialog
has (though the familiarity is lost when we start using it to select
directories, which it was never designed to do).

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org, Ben Key <bkey76 <at> gmail.com>
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Mon, 07 Mar 2011 22:31:36 +0800

Juanma Barranquero <lekktu <at> gmail.com> writes:

> One is the fact that the initial setting of FILE_NAME_TEXT_FIELD does
> not work. WM_NOTIFY is received with the appropriate arguments, and
> CommDlg_OpenSave_SetControlText (at w32fns.c:5875) is called, but it
> apparently has no effect. Perhaps some order-of-initialization issue
> that's changed (undocumentedly) on Windows 7?
>
> The other is that GetDlgItem (dialog, FILE_NAME_TEXT_FIELD) is
> returning always 0, so the EnableWindow calls are no-ops (in fact,
> that's easy to see because after setting the combo to "Directories",
> you can still edit the text field).
>
> I'm seeing these problems in Windows 7 SP1 64-bit, BTW.

Has Microsoft changed the names of these fields in Windows 7, or is it
some new "security" feature getting in the way of changing this dialog
programmatically?

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

From: Ben Key <bkey76 <at> gmail.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 09:56:46 -0600

[Message part 1 (text/plain, inline)]

Hello,

I have tested the updated patch by Juanma Barranquero and it works fine.  I
say we go with it.  What is the next step to get this change committed?

[Message part 2 (text/html, inline)]

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

From: Ben Key <bkey76 <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: Juanma Barranquero <lekktu <at> gmail.com>, 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 10:19:19 -0600

[Message part 1 (text/plain, inline)]

On Mon, Mar 7, 2011 at 8:31 AM, Jason Rumney <jasonr <at> gnu.org> wrote:

>
> Has Microsoft changed the names of these fields in Windows 7, or is it
> some new "security" feature getting in the way of changing this dialog
> programmatically?
>

Hello,

Note that a patch to fix the issue has already been submitted by my and
improved upon by Juanma Barranquero.  See the messages <
http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-03/msg00270.html>  and
<http://lists.gnu.org/archive/html/bug-gnu-emacs/2011-03/msg00269.html> for
more details.

The cause of the problem that prevented Emacs from being able to set the
initial value of the file name text field was a result of the fact that the
code that processes the lpstrFile member of the OPENFILENAME structure to
set the initial value of the window is now called after the CDN_INITDONE
WM_NOTIFY message is processed.  Since lpstrFile was set to an empty string,
this caused the text to be removed from the window after it was set.  The
fix for that was to set lpstrFile to "Current Directory" in the only_dir_p
case.

The cause of the problem that caused Emacs to be unable to disable the edit
window was simply a change in the window hierarchy of the File Open dialog
box since the bad old Windows 95 days.

The patches resolve both issues.  Note that only the latest patch by Juanma
Barranquero should be committed.

[Message part 2 (text/html, inline)]

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Ben Key <bkey76 <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 19:06:14 +0100

> I have tested the updated patch by Juanma Barranquero and it works fine.  I
> say we go with it.  What is the next step to get this change committed?

If we have your papers on file, it's just a matter of committing it.

    Juanma

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Jason Rumney <jasonr <at> gnu.org>
Cc: 8181 <at> debbugs.gnu.org, Ben Key <bkey76 <at> gmail.com>
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 19:09:31 +0100

On Mon, Mar 7, 2011 at 15:31, Jason Rumney <jasonr <at> gnu.org> wrote:

> Has Microsoft changed the names of these fields in Windows 7, or is it
> some new "security" feature getting in the way of changing this dialog
> programmatically?

The names haven't changed, but something has. I'm inclined to believe
the "security" idea :-(

    Juanma

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Ben Key <bkey76 <at> gmail.com>
Cc: Chong Yidong <cyd <at> stupidchicken.com>, 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 20:54:33 +0100

> If we have your papers on file, it's just a matter of committing it.

We already have non-trivial changes by you (from Nov 2002), so I
suppose it is OK.

Chong, if it is OK to install this change, what about porting it to
23.3? It's an usability issue, and affects just the Windows port (so
not much of a regression risk). Were you planning on making another
pretest because of the cc-cmds.el change?

    Juanma

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org, Ben Key <bkey76 <at> gmail.com>
Subject: Re: bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 07 Mar 2011 15:16:19 -0500

Juanma Barranquero <lekktu <at> gmail.com> writes:

> Chong, if it is OK to install this change, what about porting it to
> 23.3? It's an usability issue, and affects just the Windows port (so
> not much of a regression risk). Were you planning on making another
> pretest because of the cc-cmds.el change?

I am planning on making another rc, but this change doesn't look small
and self-contained enough to squeeze through.  Let's just leave it for
Emacs 24, please.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8181 <at> debbugs.gnu.org, Ben Key <bkey76 <at> gmail.com>
Subject: Re: bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 21:24:07 +0100

On Mon, Mar 7, 2011 at 21:16, Chong Yidong <cyd <at> stupidchicken.com> wrote:

> I am planning on making another rc, but this change doesn't look small
> and self-contained enough to squeeze through.  Let's just leave it for
> Emacs 24, please.

OK. Can you please confirm that Ben has signed papers, so I can commit
this change to the trunk?

Thanks,

    Juanma

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

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org, Ben Key <bkey76 <at> gmail.com>
Subject: Re: bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 07 Mar 2011 15:59:29 -0500

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Mon, Mar 7, 2011 at 21:16, Chong Yidong <cyd <at> stupidchicken.com> wrote:
>
>> I am planning on making another rc, but this change doesn't look small
>> and self-contained enough to squeeze through.  Let's just leave it for
>> Emacs 24, please.
>
> OK. Can you please confirm that Ben has signed papers, so I can commit
> this change to the trunk?

Yes, I see him now, listed under Benjamin E. Key.

Could you do me a favor and also remove the (tiny change) tag to the
previous ChangeLog entry under his name?  Thanks.

Message #72 received at 8181-done <at> debbugs.gnu.org (full text, mbox):

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 8181-done <at> debbugs.gnu.org, Ben Key <bkey76 <at> gmail.com>
Subject: Re: bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7
Date: Mon, 7 Mar 2011 22:17:17 +0100

On Mon, Mar 7, 2011 at 21:59, Chong Yidong <cyd <at> stupidchicken.com> wrote:

> Yes, I see him now, listed under Benjamin E. Key.

OK, committed.

> Could you do me a favor and also remove the (tiny change) tag to the
> previous ChangeLog entry under his name?  Thanks.

Done.

    Juanma

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

From: Jason Rumney <jasonr <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 8181 <at> debbugs.gnu.org, Ben Key <bkey76 <at> gmail.com>
Subject: Re: bug#8181: 23.2; Dired on Windows 7
Date: Tue, 08 Mar 2011 07:04:07 +0800

Juanma Barranquero <lekktu <at> gmail.com> writes:

> On Mon, Mar 7, 2011 at 15:31, Jason Rumney <jasonr <at> gnu.org> wrote:
>
>> Has Microsoft changed the names of these fields in Windows 7, or is it
>> some new "security" feature getting in the way of changing this dialog
>> programmatically?
>
> The names haven't changed, but something has. I'm inclined to believe
> the "security" idea :-(

After looking at the patch, it seems it is the name (and type) of the
filename field that has changed afterall.

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

From: "Robert I. Eachus" <rieachus <at> comcast.net>
To: 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: closed (Re: bug#8181: Patch to fix bug#8181: 23.2;
	Dired on Windows 7)
Date: Mon, 07 Mar 2011 20:58:12 -0500

On 3/7/2011 4:19 PM, GNU bug Tracking System wrote:
> Your bug report
>
> #8181: 23.2; Dired on Windows 7
>
> which was filed against the emacs package, has been closed.
Good and fast work by all.  But I still have my original question.  Why 
is the behavior different from Cx d which it lists as an equivalent?  I 
can see that having access to a Windows dialog box can be useful for 
things like recently visited directories, so the ability to access the 
Microsoft dialog boxes is nice.  I had assumed that Visit New File... 
gave the same result as C-x C-f, and Open File.., with no keyboard 
equivalent went through the the Windows menuing system.  It wasn't until 
now that I found out they were the same.   (I started in computing well 
before terminals with displays and windowing systems were common, and I 
have been using Emacs for over 30 years.  So by the time I conclude  I 
want to open a file or directory, I'm typing its name in the 
minibuffer.  (Unless, apparently, I have a hot cup of tea in my left 
hand. ;-)

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: "Robert I. Eachus" <rieachus <at> comcast.net>
Cc: 8181 <at> debbugs.gnu.org
Subject: Re: bug#8181: closed (Re: bug#8181: Patch to fix bug#8181: 23.2;
	Dired on Windows 7)
Date: Tue, 8 Mar 2011 03:24:10 +0100

On Tue, Mar 8, 2011 at 02:58, Robert I. Eachus <rieachus <at> comcast.net> wrote:

> But I still have my original question.  Why is
> the behavior different from Cx d which it lists as an equivalent?

Because, apparently, most users prefer a GUI file dialog when using
the mouse, but a keyboard interface when invoking find-file or dired
from the keyboard.

If you don't like the default, just customize `use-dialog-box' and
`use-file-dialog'.

    Juanma

Previous Next

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