FreeCommander Forum

I think it is a bug. Renaming a file by slow double-clicking the filename does not work smoothly at all and it takes several attempts to get it to work. Also, in Windows if you single-click a filename that is already selected it counts as slow double-click. In fact, I think this the actual convention behind slow double-clicking (the first click simply selects the file).

Confirmed on Windows 10 Enterprise x64 18362.239


At first I though it was because of this other problem of mine and that it would be against my last thoughts about it: viewtopic.php?p=30182#p30182 [i.e. that the slovenliness of FC it is the fault of Windows]


But then I thought that maybe my mouse settings in the OS somehow got changed on themselves, as I did not recall the problem with clicking files to rename them in previous days. And so I went to

Control Panel > All Control Panel Items > Mouse > Buttons > Double click-speed

changed the click speed to both maximum Fast and minimum Slow. As a result I only got a barely noticeable improvement with the Fast. But then I switched to Windows Explorer- it had no such delay [and now the clicking time in it was insane]


And then I remembered that it was only few days ago that I went from FreeCommander version XE 770 32-bit to XE 790a 32-bit. So I reversed the mouse settings to previous ones [around in the middle between Fast and Slow] and installed on top of 790 the 770a. And bingo- the clicking FC was working again fast. So I went back to 790- and the problem was there again. Now I am running again on 770 without the issue of speed [in regards to left-clicking renaming files and folders that is], becasue it is imossible for me to work wih that delay, as it is even incosistnet [and so I do not know how long do I have to wait and / or how may clicks will I have to perform in the end]



In my 790a the problem manifests itself like these: I have to left click a file and then wait before I can left click it again, so that I can rename it. Sometimes a second is enough, sometimes two seconds. And sometimes I can click for the second time almost right away; but more often even if I wait as long as 3 seconds my second click is totally ignored- and so I have the click for the third time. And during such testings I even once got into situation where I could not go into renaming mode with additional left click at all, even after selecting other files and waiting for like 10 seconds [and I had to resort to closing and reopening of FC]

Unfortunately this problem persists in Build 804 32-bit public beta of FC [on Windows 10 Enterprise x64 18362.356]

And on top of that I have just noticed that this issue manifests itself in another way. When I try to copy a Tab from one Panel to another [by simply left clicking it and then while holding the click moving the moue pointer] then I also need to wait- after clicking on the Tab I need to see first the hours glass [which happens after ~2 second] before moving the mouse pointer, in order to be able to successively copy that Tab and not just move [an "empty"] pointer

Unfortunately this problem persists in Build 810a 32-bit public on Windows 10 1903

It seems that from now on I just have to remember to double-click in FC with a forced pause in-between; and hope, that somewhere in the future a fresh FC install on fresh Windows on a new hardware will make this issue go away

A fresh install of Windows 10 on a new machine but with old FC settings imported did not help

So it seems that I have carried with them some bug, right? But running FC with default settings and no plugins does not help - the delay is still present

Forez wrote: ↑03.02.2021, 22:27 A fresh install of Windows 10 on a new machine but with old FC settings imported did not help
[...]

I forgot to mention the important factor: I am using now the fastest commercially available NVMe drives on a PCI-Express 4.0 bus line connected by a M.2 slots - theoretically faster few times than the previous SSD. And did noticed improvement in terms of speed all over my operating system and various programs

And so once again: no other software has such delay - but this issue in FreeCommander persists

Using FC 860 on Windows 11.

Please, improve the behavior of double-click to rename, making it similar to the way Windows Explorer works.

a) If a file is already selected, just one further click to rename file.

b) Even when slow double-clicking on a file that was previously unselected, FC renaming timing is not as "natural" and precise as Windows Explorer.

I often miss the slow double-clicking timing and renaming becomes almost trial and error...

Thank you!

cadudesun wrote: ↑12.12.2021, 04:28 Using FC 860 on Windows 11.

Please, improve the behavior of double-click to rename, making it similar to the way Windows Explorer works.

a) If a file is already selected, just one further click to rename file.

b) Even when slow double-clicking on a file that was previously unselected, FC renaming timing is not as "natural" and precise as Windows Explorer.

I often miss the slow double-clicking timing and renaming becomes almost trial and error...

Thank you!

That works perfect here.
I guess you have some strange mouse settings.

I have just discovered: if I use the newly added ability of e.g.

Tools > Settings > View > File / folder list > Mouse shortcuts > Click with right mouse button [...] > File: icon > Rename

then when I execute right click on a file I get immediately thrown into the mode of renaming its name. So this feature somehow defies this bug

horst.epp wrote: ↑12.12.2021, 10:12 [...]
I guess you have some strange mouse settings.

So is in my case also mouse being the culprit? If yes: then how is it by-passing now [when used for execution of Mouse Shortcuts] its hardware limitations or software inner-workings when I execute right click on icon? By first being told by FC to act in a different way? That does not make sense, right? Ergo: this new feature is receiving / interpreting mouse clicks in a different way - and as such making it plausible that more users also experience this bug