[TC 11.57rc6a] New file/new folder dialog: The preview does not always show an error when there is one

[white]

When using the New file dialog (Shift+F4) or new folder dialog (F4), the preview does not always show an error when there is one.

Erroneous inputs examples:
<1-2>[Ca a] test
<1-2>[C10a] test

The preview shows only the counter and the OK button is disabled.
Expected: The preview to show some kind of error.

[ghisler(Author)]

You are right, I should show <Error> in this case too. Currently the counter field is parsed separately from the rest of the rename string:
First step: <1-2>[Ca a] test becomes
from=1, to=2, rename string=<Ca a> test

Second step: The result from the first step is then evaluated in a second step for values from and to:
<Ca a> test -> error.

Only the first step sets the error string now. I will also set it for the second step. Maybe I should show
<Error> [C]
similar to
<Error> (Exif),
what do you think?

[white]

Only the first step sets the error string now. I will also set it for the second step. Maybe I should show
<Error> [C]
similar to
<Error> (Exif),
what do you think?

I'm thinking, why reinvent the wheel? Why do something different than in the multi-rename tool and create inconsistencies?

It mostly works as in multi-rename tool. Placeholders can be combined and you can add spaces. But spaces are not always separators here? And C is always the last placeholder between brackets [ ] ?

This both works in the multi-rename tool:

Code: Select all

[   U    C   ] test
[   C    U   ] test

But in the new file dialog or new folder dialog, the latter doesn't work:

Code: Select all

<1-2>[   U    C   ] test
<1-2>[   C    U   ] test

In the multi-rename tool, these are the same erroneous inputs:

Code: Select all

[C Q] test
[C][Q] test

But in the new file dialog or new folder dialog, the first contains an erroneous counter and not an erroneous placeholder:

Code: Select all

<1-2>[C Q] test
<1-2>[C][Q] test

But space is a separator for other placeholders. For example, these are the same:

Code: Select all

<1-2>[C][N1 1]
<1-2>[C][N1][1]

[ghisler(Author)]

Why do something different than in the multi-rename tool

I can't use the same code because the two work in a completely different way, especially when using conditional counters - then the function to create new names may have to be called thousands of times until a free name is found. This would potentially call a plugin thousands of times per name. That's why I need to pre-calculate the name without the counter. Something similar happens in the multi-rename tool when adding (2), (3) etc - the name is then also pre-calculated.

Placeholders can be combined and you can add spaces.

Currently when encountering the C placeholder it's assumed that it goes until the next ] character. So for now put each C placeholder in its own brackets. I will check whether I can handle multiple placeholders together with C in the same brackets.

[white]

- Allow spaces after the counter field to separate from other fields, e.g. <1-5>[C U] test (32/64)
- Show <Error!> also when there is an error in the counter field (32/64)

Tested OK to a certain extent with TC 11.57rc6c.

In rc6a, this was allowed:

Code: Select all

<1-2>["prefix-" C "-postfix"]--Test

Now the postfix must be connected wit the C placeholder without any spaces in between. I think this is OK, but there is no error and I expect the same for the prefix. This example is not very intuitive:

Code: Select all

<1-2>["prefix-"UYMDC "-postfix"]--Test

Result:
20260506--TEST
20260506PREFIX-2--TEST

And it is probably better for quoted text within brackets that do not belong to a placeholder to generate an error. For example:

Code: Select all

<1-2>["error"]a[C "error"]

Result:
a1
a2

[ghisler(Author)]

Now the postfix must be connected wit the C placeholder without any spaces in between.

Yes, this is a direct consequence of spaces acting as field separators, e.g.

[ U C ] test

For this reason, your example

<1-2>["prefix-" C "-postfix"]--Test

works like this: The first double quotes don't get erased by the space and act as a prefix for the C placeholder.
However, that C placeholder ends at the space behind it, so what you write as "-postfix" is actually a prefix to a (never coming) second C placeholder. Try this:

<1-2>["prefix-" C "-postfix"C]--Test

and you will see the "-postfix" string before the second number.

And it is probably better for quoted text within brackets that do not belong to a placeholder to generate an error. For example:

They just get discarded at the "]" character (end of the placeholder). In this case, I think it's more useful for the user to see the preview without the prefix than just <Error>.

[ghisler(Author)]

I have kept this behaviour in Total Commander 11.57 final, please confirm!

[white]

And it is probably better for quoted text within brackets that do not belong to a placeholder to generate an error. For example:

They just get discarded at the "]" character (end of the placeholder). In this case, I think it's more useful for the user to see the preview without the prefix than just <Error>.

Why is that more useful? It is a syntax error, isn't it?
If you don't show an error, that can create problems if you later want to use a similar syntax for another placeholder too.

People may make errors when creating buttons and the buttons will still work. A simple example (people's button commands may be far more complex than this):
cm_Edit /CGN=<<1-2>["error"]a[C "error"]>

Or people may use it to include a comment:
cm_Edit /CGN=<<1-2>["comment"]a[C "comment"]>

If at a later time you decide to expand TC's functionality and use a similar syntax for another placeholder too, then their buttons may suddenly stop working correctly.

I have kept this behaviour in Total Commander 11.57 final, please confirm!

Confirmed.

[ghisler(Author)]

Sorry but I prefer to keep it this way.

Moderator message from: ghisler(Author) » 2026-05-08, 07:48 UTC

Moved to will not be changed