bug#8181: 23.2; Dired on Windows 7

bug#8181: 23.2; Dired on Windows 7

[Robert I. Eachus]

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)

bug#8181: 23.2; Dired on Windows 7

[Lennart Borgman]

On Sat, Mar 5, 2011 at 11:55 PM, Robert I. Eachus <rieachus@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'.

bug#8181: 23.2; Dired on Windows 7

[Robert I. Eachus]

On 3/5/2011 7:08 PM, Lennart Borgman wrote:
> On Sat, Mar 5, 2011 at 11:55 PM, Robert I. Eachus<rieachus@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.

bug#8181: 23.2; Dired on Windows 7

[Lennart Borgman]

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

Oh, sorry.

bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

On Sun, Mar 6, 2011 at 01:40, Robert I. Eachus <rieachus@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

bug#8181: 23.2; Dired on Windows 7

[Dani Moncayo]

On Sat, Mar 5, 2011 at 23:55, Robert I. Eachus <rieachus@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

bug#8181: 23.2; Dired on Windows 7

[Eli Zaretskii]

> Date: Sun, 6 Mar 2011 14:14:26 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: 8181@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.

bug#8181: 23.2; Dired on Windows 7

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 975 bytes --]

bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

On Sun, Mar 6, 2011 at 17:04, Ben Key <bkey76@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

bug#8191: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Ben Key]

[-- Attachment #1.1: Type: text/plain, Size: 2198 bytes --]

Hello,

The attached patch fixes bug #8181: 23.2; Dired on Windows 7.  The patch is
for the Emacs trunk.  I can provide a patch for the Emacs 23 branch if it is
decided that this bug is important enough to go into Emacs 23.

This patch has been tested on Windows 7 32-bit, Windows 7 64-bit, and
Windows XP 32-bit.

This patch fixes three problems.

   1. 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.
   2. 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.
   3. Disabling the file name text field during dialog box initialization
   has undesirable side effects because this is the window that has focus when
   the open file dialog box is first opened by default.  The end result of
   disabling a window that would otherwise have focus is that focus lands in no
   man's land and the user is not able to navigate through the dialog box using
   the tab key.  Instead the system plays the system default error sound every
   time the tab key was pressed.  Now that the window is actually being
   disabled as a result of change 2, it is necessary to take steps to prevent
   this from happening.  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.


If it matters, I have already signed the appropriate copyright assignment
papers for Emacs.

[-- Attachment #1.2: Type: text/html, Size: 2487 bytes --]

[-- Attachment #2: emacs-bug-8181.patch --]
[-- Type: application/octet-stream, Size: 3091 bytes --]

=== modified file 'src/w32fns.c'
--- src/w32fns.c	2011-02-16 18:39:46 +0000
+++ src/w32fns.c	2011-03-07 03:57: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,6 +5870,26 @@
 	{
 	  HWND dialog = GetParent (hwnd);
 	  HWND edit_control = GetDlgItem (dialog, FILE_NAME_TEXT_FIELD);
+	  HWND list = GetDlgItem(dialog, FILE_NAME_LIST);
+	  if (NULL == edit_control)
+	    {
+	      /*
+	      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 hiearchy
+	      using Microsoft Spy++.
+	      */
+	      HWND tmp = GetDlgItem(dialog, FILE_NAME_COMBO_BOX);
+	      if (NULL != tmp)
+	        {
+	          tmp = GetWindow(tmp, GW_CHILD);
+	          if (NULL != tmp)
+	            {
+	              edit_control = GetWindow(tmp, GW_CHILD);
+	            }
+	        }
+	    }
 
 	  /* Directories is in index 2.  */
 	  if (notify->lpOFN->nFilterIndex == 2)
@@ -5875,6 +5897,20 @@
 	      CommDlg_OpenSave_SetControlText (dialog, FILE_NAME_TEXT_FIELD,
 					       "Current Directory");
 	      EnableWindow (edit_control, FALSE);
+	      if (CDN_INITDONE == notify->hdr.code)
+	        {
+	          /*
+	          Not 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.
+	          */
+	          SetFocus(list);
+	        }
 	    }
 	  else
 	    {
@@ -5946,10 +5982,32 @@
 	file_name_only++;
 
       strncpy (filename, file_name_only, MAX_PATH);
+      if (0 == filename[0] && ! NILP(only_dir_p))
+        {
+          /*
+          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.
+          */
+          strcpy(filename, "Current Directory");
+	    }
       filename[MAX_PATH] = '\0';
     }
   else
-    filename[0] = '\0';
+    {
+      filename[0] = '\0';
+      if (! NILP (only_dir_p))
+        {
+          /*
+          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.
+          */
+          strcpy(filename, "Current Directory");
+        }
+    }
 
   {
     NEWOPENFILENAME new_file_details;

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

On Mon, Mar 7, 2011 at 05:15, Ben Key <bkey76@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@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;

bug#8181: 23.2; Dired on Windows 7

[Jason Rumney]

Juanma Barranquero <lekktu@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.

bug#8181: 23.2; Dired on Windows 7

[Jason Rumney]

Ben Key <bkey76@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).

bug#8181: 23.2; Dired on Windows 7

[Jason Rumney]

Juanma Barranquero <lekktu@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?

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 156 bytes --]

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?

[-- Attachment #2: Type: text/html, Size: 193 bytes --]

bug#8181: 23.2; Dired on Windows 7

[Ben Key]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

On Mon, Mar 7, 2011 at 8:31 AM, Jason Rumney <jasonr@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.

[-- Attachment #2: Type: text/html, Size: 2056 bytes --]

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

> 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

bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

On Mon, Mar 7, 2011 at 15:31, Jason Rumney <jasonr@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

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

> 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

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Chong Yidong]

Juanma Barranquero <lekktu@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.

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

On Mon, Mar 7, 2011 at 21:16, Chong Yidong <cyd@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

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Chong Yidong]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Mar 7, 2011 at 21:16, Chong Yidong <cyd@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.

bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7

[Juanma Barranquero]

On Mon, Mar 7, 2011 at 21:59, Chong Yidong <cyd@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

bug#8181: 23.2; Dired on Windows 7

[Jason Rumney]

Juanma Barranquero <lekktu@gmail.com> writes:

> On Mon, Mar 7, 2011 at 15:31, Jason Rumney <jasonr@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.

bug#8181: closed (Re: bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7)

[Robert I. Eachus]

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. ;-)

bug#8181: closed (Re: bug#8181: Patch to fix bug#8181: 23.2; Dired on Windows 7)

[Juanma Barranquero]

On Tue, Mar 8, 2011 at 02:58, Robert I. Eachus <rieachus@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