Bad file dialog on W32 popped up by a click on C source

Bad file dialog on W32 popped up by a click on C source

[Eli Zaretskii]

"C-h f some-function RET" shows "C source file" for functions defined
in C.  If you click on the xref, and if the source files are not in
the place where Emacs expects to find them (e.g., if you removed the
source tree), Emacs pops up a file dialog asking you to find the
directory of the source file.  So far so good, but, at least on W32, I
see 2 problems with this dialog:

  . it doesn't say what directory it is looking for and doesn't show
    me the name of the file, so I need to guess that it wants the src
    directory

  . if I select the src directory where the file lives and click Open,
    it errors out saying "Current Directory -- file not found"

The latter problem seems to be specific to MS-Windows, as it overrides
the file name with a literal string "Current Directory"; this works
with File->Open Directory from the menu bar, but fails in the above
situation.  I'm not sure whether the former problem is MS-Windows
specific.

Any suggestions for how to solve this?

Re: Bad file dialog on W32 popped up by a click on C source

[Lennart Borgman]

Eli Zaretskii wrote:

>"C-h f some-function RET" shows "C source file" for functions defined
>in C.  If you click on the xref, and if the source files are not in
>the place where Emacs expects to find them (e.g., if you removed the
>source tree), Emacs pops up a file dialog asking you to find the
>directory of the source file.  So far so good, but, at least on W32, I
>see 2 problems with this dialog:
>
>  . it doesn't say what directory it is looking for and doesn't show
>    me the name of the file, so I need to guess that it wants the src
>    directory
>
>  . if I select the src directory where the file lives and click Open,
>    it errors out saying "Current Directory -- file not found"
>
>The latter problem seems to be specific to MS-Windows, as it overrides
>the file name with a literal string "Current Directory"; this works
>with File->Open Directory from the menu bar, but fails in the above
>situation.  I'm not sure whether the former problem is MS-Windows
>specific.
>
>Any suggestions for how to solve this?
>  
>
Would it be better to use the standard directory dialog (rather than the 
file dialog)?

Re: Bad file dialog on W32 popped up by a click on C source

[Eli Zaretskii]

> Date: Sun, 12 Jun 2005 16:03:01 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: emacs-devel@gnu.org
> 
> Would it be better to use the standard directory dialog (rather than the 
> file dialog)?

I'm nowhere near being a specialist in W32 GUI programming, but the
comments in w32fns.c sound like there's no ``standard directory
dialog'' available, or perhaps it couldn't be used here:

    /* Callback for altering the behaviour of the Open File dialog.
       Makes the Filename text field contain "Current Directory" and be
       read-only when "Directories" is selected in the filter.  This
       allows us to work around the fact that the standard Open File
       dialog does not support directories.  */

Re: Bad file dialog on W32 popped up by a click on C source

[Jason Rumney]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Would it be better to use the standard directory dialog (rather than
> the file dialog)?

There are contexts where the user should be able to select either a
file or directory.

Re: Bad file dialog on W32 popped up by a click on C source

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> "C-h f some-function RET" shows "C source file" for functions defined
> in C.  If you click on the xref, and if the source files are not in
> the place where Emacs expects to find them (e.g., if you removed the
> source tree), Emacs pops up a file dialog asking you to find the
> directory of the source file.

I just get "find-function-C-source: The C source file w32fns.c is not
available" 

>   . it doesn't say what directory it is looking for and doesn't show
>     me the name of the file, so I need to guess that it wants the src
>     directory

Seems like a problem with the prompt.

>   . if I select the src directory where the file lives and click Open,
>     it errors out saying "Current Directory -- file not found"

An Emacs error in the echo area, or a system error in a dialog?
If the latter then it is caused by the file-must-exist flag being set,
which does not work for directories.

Re: Bad file dialog on W32 popped up by a click on C source

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Jason Rumney <jasonr@gnu.org>
> Date: Sun, 12 Jun 2005 18:36:12 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > "C-h f some-function RET" shows "C source file" for functions defined
> > in C.  If you click on the xref, and if the source files are not in
> > the place where Emacs expects to find them (e.g., if you removed the
> > source tree), Emacs pops up a file dialog asking you to find the
> > directory of the source file.
> 
> I just get "find-function-C-source: The C source file w32fns.c is not
> available" 

Strange...doesn't it pop the file selector for you?  Anyway, what you
get is not a good response, either, right?

> >   . it doesn't say what directory it is looking for and doesn't show
> >     me the name of the file, so I need to guess that it wants the src
> >     directory
> 
> Seems like a problem with the prompt.

Well, the prompt actually says "Emacs C source dir:", so perhaps it's
okay (although maybe something like "Directory of fileio.c source
file" would be better).

> >   . if I select the src directory where the file lives and click Open,
> >     it errors out saying "Current Directory -- file not found"
> 
> An Emacs error in the echo area, or a system error in a dialog?

The latter.  It pops a dialog saying

    Current Directory
    File not found
    Please verify the correct file name was given.

> If the latter then it is caused by the file-must-exist flag being set,
> which does not work for directories.

You mean the MUSTMATCH arg to x-file-dialog?  That is, should I change
the code so that this flag is ignored for directories?

Re: Bad file dialog on W32 popped up by a click on C source

[Jason Rumney]

Eli Zaretskii <eliz@gnu.org> writes:

> Strange...doesn't it pop the file selector for you?

I only deleted one file, not the whole source tree. Maybe that makes a
difference. But the following seems to reproduce the same behaviour:

(x-file-dialog "test" "c:/emacs" nil t t)


>> If the latter then it is caused by the file-must-exist flag being set,
>> which does not work for directories.
>
> You mean the MUSTMATCH arg to x-file-dialog?  That is, should I change
> the code so that this flag is ignored for directories?

The following change seems to fix it for me, as long as the code that
is calling x-file-dialog sets only-dir-p. If the user switches to
"Directories" in a dialog that has mustmatch set but not only-dir-p,
it still fails but maybe that is OK, since such code is probably
expecting a file. Changing the flags does not seem to work once the
dialog is active.



*** w32fns.c	10 Jun 2005 23:42:01 +0100	1.248
--- w32fns.c	12 Jun 2005 19:19:46 +0100	
***************
*** 7833,7839 ****
      file_details.Flags = (OFN_HIDEREADONLY | OFN_NOCHANGEDIR
  			  | OFN_EXPLORER | OFN_ENABLEHOOK);
      if (!NILP (mustmatch))
!       file_details.Flags |= OFN_FILEMUSTEXIST | OFN_PATHMUSTEXIST;
  
      file_details.lpfnHook = (LPOFNHOOKPROC) file_dialog_callback;
  
--- 7833,7844 ----
      file_details.Flags = (OFN_HIDEREADONLY | OFN_NOCHANGEDIR
  			  | OFN_EXPLORER | OFN_ENABLEHOOK);
      if (!NILP (mustmatch))
!       {
! 	file_details.Flags |= OFN_PATHMUSTEXIST;
! 	/* Do not include FILEMUSTEXIST flag if we are expecting a dir.  */
! 	if (NILP (only_dir_p))
! 	  file_details.Flags |= OFN_FILEMUSTEXIST;
!       }
  
      file_details.lpfnHook = (LPOFNHOOKPROC) file_dialog_callback;

Re: Bad file dialog on W32 popped up by a click on C source

[Jason Rumney]

Jason Rumney <jasonr@gnu.org> writes:

> The following change seems to fix it for me.

I checked this in, along with a further change I made after reading
the latest documentation for GetOpenFileName, which enables the list
of special folders on the left of the dialog.