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 · 5 comments

Comments

Projects
None yet
3 participants
@dutenhnj

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

dutenhnj commented Feb 14, 2016

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

This comment has been minimized.

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

This comment has been minimized.

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 in 975238f Jun 12, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment