I was trying to rename a folder, and what became highlighted and editable for renaming was a file about 10 positions away from the folder I was trying to rename. I could not rename the folder. I moved the folder to another folder and then was able to rename it. This was a one time occurance and I could not reproduce it, but it did happen.
Was that in Opus 12.2 or an earlier version?
How was the rename started?
Version 12.2 x64. Right-clicking on the folder name and selecting 'Rename' from the popup menu.
If the original folder (with its original name) was there again and you right-clicked it, would the "Rename" command roughly line up with the filename that was about 10 positions away? On my example screenshot below, the red box inline with the Rename option happens to be 10 positions away from what I was right-clicking.
In other words, I suspect you accidentally "missed" clicking on rename and single-clicked the 10-positions-away filename instead which put it in rename mode.
Since I'm about to type anyway (for the new name), I just highlight the folder or file name and hit F2 to go into Rename mode, but I know some prefer mousing around.
That is possible.
No, that is not possible. I tried it a number of times and studied it a little bit before giving up.
I can't reproduce this on two machines so far.
Could you make a screenshot showing the full window just before Rename is clicked, in case any details stand out?
I noted in my original post that I only encountered the situation once (but tried to rename a number of times with the same result) and could not reproduce it after I moved the folder I was trying to rename. I was just making a note of it here in case anyone else had encountered the same thing before, or may in the future. The folder has since been rearranged and I can't post details (i.e., screenshot) of my system, but I'll keep an eye out for the issue when renaming folders.
Before posting the above, I went and tried to rename a folder and got the result I noted in my original post. Sometimes it happens, and sometimes it doesn't. I'm playing with it now trying to figure out what is different/what I'm doing different, when it does that. I'll try to create a dummy folder/file hierarchy to test with and get back to you. It's happening in the same folder/subfolder hiearchy as the first time, so I'll do some limited/quick testing in other folders.
I have a folder where I can reproduce the behavior consistently. I only happens (now) when I right-click on a folder's folder-icon (any folder icon in the lister, but doesn't happen consistently for first folder) and then try to rename it. It then makes editable, the name of the file inline with the 'Rename' popup menu choice, instead of the folder I right-clicked on. Sort order in th list-view lister does not make a difference.
I quickly made a dummy folder hierarchy trying to get it to misbehave, but that didn't work. The folder I am working with now is an existing folder on my hard drive. I still don't want to post a screenshot though.
I have modified the context menus to rearrange/add/delete the options, so I'm not working with a default install of DOpus.
Update
It's happening in all my folders (I guess I don't rename folders that often, or the behavior just started recently). Lister view type doesn't matter: it happens in list view, details view, and large icons view. The last folder I tried was C:\Windows and it occurs there too.
Update
It doesn't happen exclusively when right-clicking on the folder icon. It happens also when right-clicking on the folder name, but not as consistently as when right-clicking on the folder glyph.
Update
When left-clicking on the 'Rename' popup menu choice, what becomes editable is the file or folder that is under the mouse pointer--even if that file/folder is in the adjacent column.
Update
So, restating simply: the target of the 'Rename' shifts from that which was originally right-clicked on to bring up the context menu, to that which is below the mouse pointer under the context menu.
Update
The dummy folder I created where I didn't receive the strange behavior, didn't ellicit the behavior because I didn't create enough items to where the 'Rename' context menu choice was above an item. Adding more items (folders or files) corrected that and gave the strange behavior upon renaming.
A screenshot could be really useful here, if you can now reproduce it in a dummy folder that doesn't have any details you need to keep secret.
I uninstalled my customized version and reinstalled DOpus and did some testing on the pristine installation to see if it was my customizations that were causing the problem--they aren't. Turning-on "Single click to open an item" introduces the behavior. Renaming works fine if "single click.." is not checked. The 'Rename' context menu item must be over a lister file or folder to get the wrong result. I think you'll be able to reproduce it now, unless there's something really weird going on with my machine.
I turned on Preferences / File Displays / Mouse / Single click to open an item (point to select - does not apply to Power mode) and I still couldn't get it to misbehave. Strange.
I still can't reproduce it either. Please make a screenshot so we can see exactly where to click.
Also, is it possible an extra click is happening after the menu is selected? If you click in the same place that the "Rename" menu item would appear, but without opening the menu, does it initiate the same rename? If so, I might suspect the mouse button is sending extra clicks, which is common with an old mouse which is starting to fail. (Happens all the time here when they wear out.)
OK then. If you had single-click turned on and a file or folder under the 'Rename' context menu choice (mouse pointer over either the glyph or the text of the file/folder, and not over lister empty area, with the context menu in-between) when you left-clicked 'Rename' and you didn't get the strange behavior, then it looks like it may be peculiar to my machine or the way that DOpus runs on my machine. I will be installing a newer build of Windows 10 in the next week or so, so the the problem may "fix itself". In the mean time, if you guys think of something that may fix the problem, please let me know. I will post updates here if I discover any new details about the issue.
Thinking out loud: At right-click time, when the context menu is displayed, is the target of the action not already solidified? Apparently not! It's either being changed or gotten at left-click-on-'Rename' time.
Note: The other items in the context menu don't cause any problem. E.g., 'Cut' properly dims the gyph for the file/folder upon which 'Cut' was being performed and 'Delete' deletes the correct file/folder. Only 'Rename' changes it's target when another file/folder is under the mouse pointer when clicking on 'Rename'.
Note: Windows Explorer does not exhibit the strange behavior.
Navigation through folders and opening of files when using the left mouse button performs flawlessly.
I have a Spy++ (Visual Studio 2015) log of the messages sent to the lister window during the entire process. I can send it to you if you tell me where to send it.
I've captured two message traces: The scenario when renaming works correctly, and the scenario where it doesn't. Let me know if you want them for analysis.