Auto-refresh only works if you press enter key

[platanos]

Hi,

In windows explorer, if you edit the name of a file/folder, you can accept the change in two ways: one is to press enter key. The other one is to clic with the mouse outside of the file/folder. I mean, when you clic outside, windows accepts the change made in the name of the file/folder and works the same like pressing enter key.

In XYplorer the trick of the mouse doesn't work well with Auto-refresh feature. Files/folders don't auto-refresh if you clic the mouse when changing their name. The Auto-refresh only works if you confirm the changes pressing the enter key.

So my question is if it possible to change the behaviour of this matter.

Thanks for your help.

[admin]

This is a feature. It gives you an easy on the fly choice between having your renamed items resorted or not.

[TheQwerty]

There's a bit of an in depth discussion on this here: http://www.xyplorer.com/xyfc/viewtopic.php?f=2&t=3007

[platanos]

This is a feature. It gives you an easy on the fly choice between having your renamed items resorted or not.

Thanks for your replies.

In my case this is more a problem than a "feature", as I usually don't use enter key.

Is it possible to disable that "feature" in the ini? It would be nice if you could enable/disable it.

[admin]

This is a feature. It gives you an easy on the fly choice between having your renamed items resorted or not.

Thanks for your replies.

In my case this is more a problem than a "feature", as I usually don't use enter key.

Is it possible to disable that "feature" in the ini? It would be nice if you could enable/disable it.

No, sorry.

[zer0]

This is a feature. It gives you an easy on the fly choice between having your renamed items resorted or not.

Is this not already provided via Tools > Config > General > Resort List Immediately After Rename?

It's a double-ended sword. Not enabling resort to be triggered when an item becomes unselected is as much of a downside for those (myself included) who are used to WE's behaviour in such situation as it is of an upside for those who want to have a choice whether to resort immediately upon removing focus or not.

Let's take a literal stance here. Is a file's rename committed once it looses its focus? Yes. Therefore, resort list should be triggered. If people do not wish for immediate resort (ala Enter key) then they should not have aforementioned tickbox ticked. As it stands, the functionality of this option has been limited on purpose.

[admin]

It's a double-ended sword. Not enabling resort to be triggered when an item becomes unselected is as much of a downside for those (myself included) who are used to WE's behaviour in such situation ...

My WE does not auto-resort at all after renaming. Never. Is this Vista what you are talking about?

[zer0]

My WE does not auto-resort at all after renaming. Never. Is this Vista what you are talking about?

I think the following link will answer your question perfectly:
http://forum.soft32.com/win3/Disabling- ... 24829.html
Your reply (4th reply from the top) made me smile

[admin]

My WE does not auto-resort at all after renaming. Never. Is this Vista what you are talking about?

I think the following link will answer your question perfectly:
http://forum.soft32.com/win3/Disabling- ... 24829.html
Your reply (4th reply from the top) made me smile

Oh yes, thanks, master!

So you "usually don't use enter key." Well, use it! You are pressing keys anyway when doing an inline rename, or? What's the point in "entering" it with the mouse?

[zer0]

So you "usually don't use enter key." Well, use it! You are pressing keys anyway when doing an inline rename, or? What's the point in "entering" it with the mouse?

Believe it or not, but I try to minimise the need to use Enter key. When doing renaming, all I need is a mouse and sometimes combos of Ctrl+C/V. Since both commit rename via mouse and Enter key finalise the process of renaming, I don't see any reason why either of those should be any less of a commit than another. I'm leaning towards the opinion that people who don't want their list resorted after rename simply won't tick that box and that's exactly what that woman, to whom you replied in the thread that I linked to, did. So please tweak XY so it resorts after a user "enters" it with their mouse.

[admin]

So you "usually don't use enter key." Well, use it! You are pressing keys anyway when doing an inline rename, or? What's the point in "entering" it with the mouse?

Believe it or not, but I try to minimise the need to use Enter key. When doing renaming, all I need is a mouse and sometimes combos of Ctrl+C/V. Since both commit rename via mouse and Enter key finalise the process of renaming, I don't see any reason why either of those should be any less of a commit than another. I'm leaning towards the opinion that people who don't want their list resorted after rename simply won't tick that box and that's exactly what that woman, to whom you replied in the thread that I linked to, did. So please tweak XY so it resorts after a user "enters" it with their mouse.

I cannot find the discussion now, but I remember that users perceived a resort on focus loss (of which mouse click outside rename box is a subcase) as confusing. That's the reason I actively did something to prevent it: On 2007-11-12 I wrote additional code to achieve the behavior we are seeing now.

Apart from you nobody seems to have problems with it.

[zer0]

I cannot find the discussion now, but I remember that users perceived a resort on focus loss (of which mouse click outside rename box is a subcase) as confusing. That's the reason I actively did something to prevent it: On 2007-11-12 I wrote additional code to achieve the behavior we are seeing now.

Apart from you nobody seems to have problems with it.

Perhaps those users, who were confused, were unaware that focus loss by mouseclicking outside of the rename box commits the rename operation. If they knew that it does then I don't see how they could have any complaints.

Me and platanos simply wish for there to be no hair-splitting - a commit of a rename is a commit of a rename, let's please not discriminate here. Also, I discovered that if you are downloading a file into the same folder as the file that you are renaming and committed the rename via mouse then there is a chance that a list will resort before you navigate away due to refresh to update the amount downloaded so far. I wonder if people would perceive that as confusing.

[platanos]

Apart from you nobody seems to have problems with it.

I too have the same problem.

In my opinion you should add an option to enable/disable it instead of telling us how to work in our computers.

Just my two cents

[TheQwerty]

Don, could you determine when the rename control loses focus, but to another XY control, or rather the control loses focus but XY doesn't?

If so then I'd say we should have the following (with resort on rename enabled).
Rename mode is exited via:
1) Enter - Rename & Resort list.
2) Tab - Rename but don't resort yet (rename mode hasn't actually been exited).
3) Edit Lost focus, but XY did not - Rename and resort.
4) XY lost focus - Nothing. It's not clear that the user chose to exit rename mode, so the name shouldn't be changed. I'm not sure whether a resort should occur if the user was performing a serial rename. I'm leaning towards yes as they've committed the previous names, but it means when they get to return focus to XY it won't be exactly as it was before focus was stolen. (Ideally it would be leave the user in rename mode, but blah blah unicode controls broke that )


From there a tweak could be introduced for number 4 for any users who wish to throw caution to the wind and use WE's dangerous behavior.

[zer0]

4) XY lost focus - Nothing. It's not clear that the user chose to exit rename mode, so the name shouldn't be changed. I'm not sure whether a resort should occur if the user was performing a serial rename. I'm leaning towards yes as they've committed the previous names, but it means when they get to return focus to XY it won't be exactly as it was before focus was stolen. (Ideally it would be leave the user in rename mode, but blah blah unicode controls broke that )
From there a tweak could be introduced for number 4 for any users who wish to throw caution to the wind and use WE's dangerous behavior.

This is an interesting one. First of all, I don't see WE's behaviour is dangerous. It maybe the case that those unfamiliar with it, such as those moving from XP to Vista, may find the behaviour unnatural but I can only foresee that happening if some glitch caused their rename to be committed. If they did in fact commit a rename then I see a resort to be a natural consequence. The way I envision this, if sorted by filename, is that you "take a file out" when you wish to rename, do the renaming and put it back into the list of files. Since the list is already "under the watch" of "sort by filename" then it takes that file and puts it in the right place according to its name. If you prefer, think of it as going to a library, taking a book to read from a shelf, changing the author's name and trying to put the book back in the same place where you took it from. If that was acceptable behaviour then every library would be a mess. Same when it comes to file management, once a rename has been committed it is released back into the file system and if that system is sorted by a certain criteria then this newly-renamed file should obey this criteria immediately.

I assume that it would not be too difficult to distinguish between loosing focus due to a mouse click and a glitch (if XY keeps a record of every mouse-click that is). Therefore, one should not be worried in terms of clarity whether a user chose to exit rename mode or the computer made that choice for him