I don't believe Ctrl+Z should undo saving tag while I edit tags in Tag panel

Bug Reports Fixed Bugs
#1

In my mind, Ctrl+C, Ctrl+V, Ctrl+X and Ctrl+Z are a standard bunch of shortcuts associated with editing and their behaviour should be the same. Now (in Mp3tag 2.58) we have that Ctrl+C, Ctrl+V and Ctrl+X act differently in Tag panel versus file list, but Ctrl+Z acts the same (which is "undo saving tag").

This could be unimportant, but several times I had a situation when I wanted to undo typing or editing a field in Tag panel, but instead I lost all whe work done in several Tag panel fields! This can be pretty upsetting. The reason is a strong habit that Ctrl+Z is used to undo editing an edit field across all the applications (though, some of them don't have a shortcut for that). I think there are other users with such "mechanical" habit. And I never use "undo saving tag" command, but undoing typing is important for me.

As for now the solution will be disabling Ctrl+Z shortcut: either by means of AutoHotkey or by editing "English.lng". Ok, I've edited "English.lng", it's easier.

Thank you for considering this thing!

3 Likes
Mp3tag v3.06a released
#2

Information typed in the tag panel is stored only if you explicidly save that information. So before you have used the save function, there is no reference to which an undo can roll back to.

If you edit in the files list and have entered something you do not want but have not yet moved to the next field, then press Escape to revert to the previous version.
As soon as you leave the field, the information is saved and you can undo this saving with Ctrl-Z.

So I would say that the behaviour of Mp3tag is consistent - so where is the bug?

#3

I would agree there but add the rider of "with similar applications"

I use and have tested several retagging or renaming applications and they all have the behaviour of Ctrl+Z being the "Undo last save", though to be fair, they do have a modal alert that warns of this and require confirmation before performing the action.

#4

The behavior is not consistent and that is well explained in the first post.

1 Like
#5

I just had a similar experience as the OP. This is part of Windows UI expected consistency that while user is in the edit box, hitting Ctrl+Z should only undo actions done in this edit box, not execute global Undo.

In my case I just finished editing a tag for an mp3, saved it, moved the file to another folder via "Move To...", then started working on the next file. Midway through typing I realized I was in the wrong field so I hit Ctrl+Z . To my surprise, not only text in the edit box got reverted but my previous file was moved back to original folder.

1 Like
#6

Ouch! Didn't realize "Jan 14" meant Jan 2014, not Jan 14 of this year :joy:

The bug is till relevant though!

1 Like
#7

... which also means that for more than 6 years (I would assume that it has been implemented in one of the first versions back in 2004) the shortcut has been part of the UI, so apparently users got used to it.
Assigning a different function to this shortcut would probably lead to just as much irritation as by now the longer-term users are accustomed to revert to the last version with Ctrl-Z.

#8

Thanks for reporting and no problem to resurrect the old topic :slight_smile:

I've made a note to look into it again. I'm still not sure if and how to tackle this, but I'll keep you posted.

2 Likes
#9

That’s a false assumption. I’ve been annoyed by this behavior before, but I never bothered reporting it.

#10

Hi Florian, I'm not sure what framework you are using, from lack of dependencies looks like it might be pure Win32 APIs.

Can you not do in your command handler something like this?

   HWND hFocus = ::GetFocus();
   TCHAR szClassName [556];
   ::GetClassName (hFocus, szClassName, sizeof(szClassName)/sizeof(TCHAR));
   if (_tcscmp (szClassName, _T("Edit")) == 0){
      // let default proc handle this
      // .....
   }
1 Like
#11

I agree with the OP. This implementation of Ctrl+Z really frustrates me too. I am constantly using Ctrl+Z to undo the last typed change (because that's how it works everywhere else when an edit field has focus) and instead I lose the entire new contents of the tag that I have just entered into numerous different fields.

Perhaps use Shift+Ctrl+ Z to undo the entire tag, and let Ctrl+Z only undo changes to the currently focussed field.

#12

Thanks for the pointer! I'm already using something similar for Cut, Copy, and Paste (do distinguish between tag copy and text copy).

The problem is more with my self-baked auto-complete combo box, which uses SetWindowText internally to set the suggested completion. This resets the undo stack of the edit control. I'm looking into EM_REPLACESEL next, which has the option to allow for undoing the replacement operation. It really tricky and this code has a fairly ancient touch to it...

#13

I've implemented this with Mp3tag v3.05d and it would be great if you all could test the new behavior.

Thanks for your patience with this!

3 Likes
Occasional problem with Letter case edit
#14

Awesome, works great. Thanks!

1 Like