Renaming torrents saves the name change to wrong torrents

[lovetour]

Hi,

uTorrent 3.2

I just went to undertake a tidying up of my torrent list to make it more manageable, renaming torrents to a more or less standard naming convention. But, what appears to happen is this:

You click or hit F2 to edit the name, you type your changes and hit enter, and the name change is saved not just to the original torrent but ALSO to whatever torrent is on the line that the original torrent was on when you started.

This problem occurs if the list of torrents is sorted on any field that might change while you are typing, reordering the list of torrents.

I now have dozens of torrents whose names have been entirely overwritten with the name of other torrents... -- now duplicate names -- for quite different torrents.

Is this a known bug fixed in later versions? (I know a tracker I use limits versions, but I don't know the latest they support).

Thanks! --Off to try to makes sense of and clean up this mess.

Lovetour

[ciaobaby]

It is not a bug. It is caused by the normal behaviour of "listbox" objects and you having the list sorted by a volatile column.

[lovetour]

Thanks for the response ciaobaby!

I strongly disagree that "the normal behavior of" <insert name here> "objects" defines correct or expected behavior for a program! One can always set their own rules for what they consider a bug. It is a soft term. But reasonable user expectations of program behavior -- expected behavior -- is one fairly minimal standard. When common expectations aren't met, the software has failed the user (whether or not it has failed the developer's expectations).

In Windows Explorer, you can edit a filename for example, and even if other files in the folder change while your are doing that - causing the sort order to change, your edits will NEVER be applied to multiple files or files you didn't specify. Under some conditions (e.g. another window taking the focus), edit mode will automatically be cancelled (with whatever you had typed so far saved as the name).. not ideal, but at least clear.

One solution to the problem I described would be to defer sorting of the list during editing, much like MS Excel defers most background activity, events and macros while the user is in edit mode.

Another solution would be to scroll the list, keeping the item being edited at a fixed position in the window, and then applying the edit to the correct item.

A minimal solution would be to, no matter what, only apply the edit to the item that the user has started editing, no matter what the view looks like. Not ideal in all respects, but it is still what I believe most users would expect -- they start typing a new name for item "A" and when they hit enter, the name will be applied to item "A".... (Not Item "A" and Item X both [next item at that position]) as occurs now.

Lovetour

[ciaobaby]

In Windows Explorer, you can edit a filename for example, and even if other files in the folder change while your are doing that

Sure but a file list in Windows Explorer pane is not referenced in the same way. In an Explorer pane items are referenced by a GUID (Globally Unique IDentifier), in a standard list box items are referenced as an array by their position in the list, ListObject(index) in simple terms. So if a DIFERENT entry moves into that index location IT becomes the target of the edit.

Yes, it COULD/SHOULD be avoided by having a check for the list being re-ordered during edits, which is why I logged a bug report about it.

[lovetour]

Glad to hear the devs have been notified about the issue.

I work around the issue now by sorting the list by name whenever editing a name, and then changing the sort order back to my desired order. Cumbersome, but effective.

Thanks