Rename error

[Paul Mc]

A tiny thing but probably one that should be fixed:

I clicked OK instead of Cancel after selecting Rename of a Global Spot when I then decided that it didn't need changing.

[walt.farrell]

What do you think needs to be fixed?

You tried to rename color "X" to the same name, and it correctly told you that you can't do that. How is the application expected to know that you meant to click Cancel, as opposed to having chosen the wrong color name before clicking OK?

[Sean P]

Hi Paul Mc,

Walt is correct - it is just informing you that it cannot be renamed because a fill already exists with the same name. Whilst in your instance the message isn't really valid, but in others  it is. For example if you were trying to rename a different colour to use a name of an existing one then you would want to be told that the name already exists.

[Paul Mc]

Hi @Walt, this isn't an error, yet it appears as a Rename Failure implying an error has occurred. In this instance clicking OK should have been the last of it. Renaming something with the name it currently has should be an acceptable operation. No operating system that I know complains when I rename a file to the same name it already has. I've an idea that the code is checking that you don't rename the colour to one of the other colours already in your document but it didn't eliminate the current colour name from the list for checking. This is an important test but surely should omit the current name from the validation check.

11 minutes ago, walt.farrell said:

What do you think needs to be fixed?

The error message shouldn't be displayed.

11 minutes ago, walt.farrell said:

You tried to rename color "X" to the same name, and it correctly told you that you can't do that.

Correctly? Why can't it be accepted?

[Paul Mc]

@Sean P Thanks for the reply but please see my reply to Walt. Sorry, but I can't believe this is acceptable. I'm not renaming the colour. It doesn't clash with any other colour names; the state after this operation is exactly the same as the state before it. No error has occurred. The code has been written to include the current colour name in the test for duplication. It should be omitted.

 

[Alfred]

3 minutes ago, Paul Mc said:

Why can't it be accepted?

The same name could be accepted, but the app is correctly telling you that you can’t rename the colour to the same name (just as you can’t change your name to Paul, because it already is Paul). However, I do agree that the error message is spurious, since ‘changing’ the name in this way doesn’t do any harm.

[Paul Mc]

Hey, I'm just trying to help  

To me it's an unhelpful message. It causes an interruption of the UI/UX flow requiring a bit of thinking to resolve it. Removing it (IMHO) will improve the UI and user experience. Just sayin'

[walt.farrell]

9 minutes ago, Paul Mc said:

Correctly? Why can't it be accepted?

Because maybe you're making a mistake.

Consider that you have a color named "X" and you want to rename it to "Y", but mistakenly you type X (or leave it as X). If OK just accepts the name you have, then your intent (to rename X to Y) hasn't happened.

The application cannot tell what you meant to do, other than you wanted to do a rename. And it didn't do the rename, so an error occurred.

[Alfred]

15 minutes ago, walt.farrell said:

Consider that you have a color named "X" and you want to rename it to "Y", but mistakenly you type X (or leave it as X). If OK just accepts the name you have, then your intent (to rename X to Y) hasn't happened.

Suppose you have a colour named “X” and you want to rename it to “Y” but you mistakenly type “Z”. If ‘OK’ just accepts the name you typed, as it will, then your intent (to rename X to Y) hasn’t happened.

[Paul Mc]

Hi @walt.farrell I understand what you are saying but that only applies if the name is edited and changed. I didn't make a mistake and I intentionally clicked OK expecting (incorrectly) that the name would be committed to the colour swatch and leave it effectively unaltered. There are two pathways, update the name or skip updating the name. The skip pathway should be followed for a Cancel operation; the update pathway should be followed for a Save/OK operation. The update pathway should have ensured, as it did, that I wasn't renaming the colour to a name that was already in use by another swatch. The keyword here is another. If the name was unaltered then the code could have tested for a modified name string and taken the Cancel pathway when there was no change. Clearly it didn't do that but took the full list of existing names, including the colour I'd selected Rename on, and checked against that for a duplicate. It found itself in that list and declared that the name couldn't be saved because there was already one in the list with that name.

Skipping the update path when the name is unaltered is what Windows does with filenames and nearly every other app/OS I've had the opportunity to use. I've made this mistake in code that I've written in the past which is why I reported it here.

Update: I've just tried it on a new file and this message didn't appear. I can't explain what's going on but the message did appear previously as shown above.

[Mark Ingram]

I agree with @Paul Mc here, if I click a file in Windows Explorer, hit F2 to rename it, then delete a character, then put a character back (so the filename is the same), it doesn't popup an error telling me that it can't rename the file.

[carl123]

If I try to rename an adjustment preset it lets me use the same name by clicking "OK" without any error message

If I try to rename a studio preset the OK button is greyed out if the same name is used

It's all a little inconsistent at the moment

[Jowday]

8 hours ago, Mark Ingram said:

I agree with @Paul Mc here, if I click a file in Windows Explorer, hit F2 to rename it, then delete a character, then put a character back (so the filename is the same), it doesn't popup an error telling me that it can't rename the file.

Yep - this is a rudimentary usability scenario: no input data changed in the end whatever the user actually did - no action needs to be taken. Many modern programs make this check when you change content and edit it back (not undoing). There is simply no need to save.

Otherwise:

• Unnecessary action is taken by program code
• The unnecessary action taken by program code can lead to confusing scenarios like this one (that is why you never want code to run without a reason, you can't predict everything that can and will happen either)

The terminal and computer as a machine days are over 🙂 The machines work for us now.