Save/Open (including Save/Load Session) file dialogs don't accept forward slashes in 'File name:' box

[sasumner]

Description of the Issue

Post integration of PR #9286, I noticed that the SaveAs dialog used when saving a session does not support forward slashing in the pathname. It would be nice if such slashing were allowed.

Steps to Reproduce the Issue

1. File > _Save Session...
2. Attempt to specify a (valid) full path with forward slashes in its name into the SaveAs dialog's File name box:
   
3. Press the Save button and observe the error:
   
4. Change the slashes to backward ones:
   
5. Observe session file saves without error into the destination pathname

Expected Behavior

To be able to use either forward ( / ) or backward ( \ ) slashes in pathnames in the SaveAs (and Open) dialogs.

Actual Behavior

Unable to use forward slashes.

Debug Information

Notepad++ source after this commit: b9f498f

[mere-human]

I would like to work on this issue. Could it be assigned to me?

[mere-human]

It seems that common item dialogs don't allow a custom validation of the file name.
There are several features that I've tried so far:

• SetOptions: FOS_NOVALIDATE, FOS_NOTESTFILECREATE
• IFileDialogEvents to receive notifications of events within the dialog (a warning is shown before OnFileOk).

Neither of those works. The warning is shown nevertheless:

It seems the advanced features like file name validation is hidden intentionally by design.

So now I'm trying more tricky ways.
When we need custom file names like the ones with a forward slash, then we'll do workarounds.
My idea:

1. hide the standard "OK" button
   
2. add a new custom "OK" button
3. do validation when the custom "OK" button is pressed
4. after all is done, send the "pressed" message to the standard button and handle the results.

[sasumner]

So now I'm trying more tricky ways.
When we need custom file names like the ones with a forward slash, then we'll do workarounds.

I suppose waiting on this experimentation (to see if winXP still needs to be supported) is the smart thing at the moment.

[mere-human]

@sasumner
I am still experimenting.
So far I came up with an extra button "Navigate".

It transforms a Unix-like path into a Windows path. If the name is a file path, we open the file. If the name is a directory, we go into it.
This is how it works:

cap2.mp4

Workaround with hiding the "Save" button is even trickier than I thought.
At first, I thought I'd add a custom button via IFileDialogCustomize::AddPushButton and then change its position to be the same as "Save" button's.
But turns out, the custom button is contained within a "visual group":

It restricts the button's position so it is being clipped when moved.

Now I am thinking about adding a custom child button, not through the IFileDialogCustomize.

How important is it to have that Unix-like path feature?

[mere-human]

Just for the reference:
As far as I can see, the original Unix-like path feature request was mainly for the File Open dialog.
Issues: #2438, #3840
Fixed in PR #3948
Community forum topics:
https://community.notepad-plus-plus.org/topic/10573/feature-request-support-unix-slashes-in-file-open-dialog
https://community.notepad-plus-plus.org/topic/15942/opening-unix-style-file-paths
https://community.notepad-plus-plus.org/topic/16127/support-of-unix-like-paths-and-file-names-in-file-open-dialog-possible

[sasumner]

How important is it to have that Unix-like path feature?

To me? Not important at all. :-)

However, I stated before (I think) that it would be nice to be able to get rid of the Use new style... preference setting, and the only reason I can see that it still exists relates to being able to use / in paths.

[sasumner]

"Navigate"...It transforms a Unix-like path into a Windows path. If the name is a file path, we open the file. If the name is a directory, we go into it.

The term "Navigate" isn't that intuitive for converting paths.

I'm liking the brainstorming you're doing, however; keep it up! :-)

[donho]

@mere-human

"Navigate"...It transforms a Unix-like path into a Windows path. If the name is a file path, we open the file. If the name is a directory, we go into it.

The term "Navigate" isn't that intuitive for converting paths.

+1 for @sasumner.
From my viewpoint, "Navigate" button shouldn't exist. Users should be able to provide whichever slash in the File name field like: c:/myFolder\mySubFolder/myFile.txt, then it will translate to the windows format: c:\myFolder\mySubFolder\myFile.txt.

How important is it to have that Unix-like path feature?

To me? Not important at all. :-)

It's important because it's existed since longtime ago and this feature is used by people.
If we remove this feature, then there will be a lot of complains on the community forum and opened issues on Github.
So the statement of @sasumner is not true :)

However, I stated before (I think) that it would be nice to be able to get rid of the Use new style... preference setting, and the only reason I can see that it still exists relates to being able to use / in paths.

I could not agree more.

[mere-human]

Ok, thanks for the input.
I've come up with a solution that doesn't require any new ugly buttons.

[donho]

Sorry I just modified the issue title because it's more interesting to have all the Save/Open dialog to have such capacity.
(I was not aware of the title)

[mere-human]

Sorry I just modified the issue title because it's more interesting to have all the Save/Open dialog to have such capacity.
(I was not aware of the title)

Maybe it makes sense to create a separate issue to extend the scope of CustomFileDialog to Open/Save dialogs.
Because this way we are trying 2 things at once:

1. Add support of a forward slash path to CustomFileDIalog (this issue)
2. Use CustomFileDialog for open/save

I don't mind doing it in the scope of a single issue though.

[donho]

I see your point.
But if we keep the commits separately for the reviewing, I don't see the problem.
The thing is to make sure this feature can be implemented globally, so we can avoid the situation that only some/few dialogs can have this capacity - in this case, we have to revert the PR I've merged because the behaviour is not homogeneous.