Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New folder creation issue in Windows 10 #48

Closed
dutenhnj opened this issue Feb 5, 2016 · 6 comments
Closed

New folder creation issue in Windows 10 #48

dutenhnj opened this issue Feb 5, 2016 · 6 comments
Labels

Comments

@dutenhnj
Copy link

dutenhnj commented Feb 5, 2016

When you right click to create a new folder, normally it would create "new folder", select it and jump directly to editing the name, however in Windows 10 explorer++ misses the renaming step entirely and instead just creates "New Folder" without selecting it or jumping to the rename feature.

@derceg derceg added the bug label Feb 6, 2016
@derceg
Copy link
Owner

derceg commented Feb 6, 2016

I haven't done any testing, so I can't say exactly what the issue would be, but when you create a file via the right click menu, there's a callback that's meant to be executed. That callback places the new item into rename mode. It's possible the relevant shell interface has been changed or updated in Windows 10.

@derceg
Copy link
Owner

derceg commented Feb 14, 2016

It looks like the "new menu" shell extension in Windows 10 passes a flags value of 3 to INewMenuClient::SelectAndEditItem. According to the documentation, there is no flag with that value.

The reason why Explorer++ never puts the new item into rename mode is that it expects to receive the NMCSAEI_EDIT flag (which has a value of 1). Updating the code so that it puts an item into rename mode whenever 1 or 3 is received appears to work.

@dutenhnj
Copy link
Author

So either it is a bug in windows 10 itself, or they haven't updated the documentation, interesting.

I noticed another glitch about renaming files that is probably related to this. If you rename a file, then push Tab to switch to the next file, it selects the next file but fails to go into the editing mode. But it only happens if you actually rename the first file, if you don't rename it and just hit tab, it opens the next file name for editing as it should.

@derceg
Copy link
Owner

derceg commented Feb 15, 2016

I noticed another glitch about renaming files that is probably related to this. If you rename a file, then push Tab to switch to the next file, it selects the next file but fails to go into the editing mode. But it only happens if you actually rename the first file, if you don't rename it and just hit tab, it opens the next file name for editing as it should.

Can you create a new issue for this? It looks like the rename should probably be done silently (a progress dialog currently pops up).

@jat255
Copy link

jat255 commented Dec 8, 2016

Found this issue when searching for this problem. I have nothing to contribute to the code, but in the meantime before it's fixed, I created the following AutoHotkey script to workaround the issue, using Ctrl+Shift+N as the shortcut:

; Remap new-folder shortcut
#IfWinActive ahk_class Explorer++
^+n::
   Send, ^n{f5}new{f2}
Return

@derceg derceg closed this as completed in 975238f Jun 12, 2017
@gustavotrott
Copy link

I didn't undertand if it was fixed or not?

For me it is happening yet, if I create a new folder, it is not selected and not in editing name mode.
Also, if I select the folder I can't delete! I need to select other thing and after that I can select and delete.

Is this in the issues list or I should open other issue?

Using Windows 10 Pro here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants