Tiny delay before 'Cannot Rename' dialog would be helpful

[grindax]

.

[admin]

Is it that step 4) triggers the rename?

[grindax]

.

[admin]

Is it that step 4) triggers the rename?

Yes, in the past step 4 would achieve 2 things: it would close the document, and also cause the rename to take place successfully (as focus would move away from XYplorer). I guess that Windows itself has a small grace period before giving up on the rename operation.

I see, pretty wild style but if it works...

Just to make sure, you are talking about this message?

Cannot Rename
The item is currently opened by another application.

[grindax]

.

[admin]

OK, next version will give 500 msecs. Let me know if this helps.

[grindax]

.

[admin]

OK, next version will give 500 msecs. Let me know if this helps.

Works much better in 9.40.0108, but a side-effect is that the list now auto-sorts even though I have the option 'Resort list immediately after rename' turned off.

EDIT: The auto-sorting issue may be something separate. I'm finding that renaming files in certain locations (network drives?) is causing the list to immediately sort, while doing the same thing in other places doesn't. I'll try to find a pattern...

EDIT #2: I think this is happening in locations watched by other programs. I know some time back you solved a problem where in-line rename was auto-committing without the user pressing Enter -- I wonder if this list auto-sorting issue is similar/related?

I don't think this is a new issue, and it will be hard to fix. I'll watch it...