[TC 11.57rc6] New file/new folder: Using '<[F][C") "]This is a test' gives unexpected results

[white]

(Issue also present in earlier beta versions)

• Press Shift+F4
• Enter:

  Code: Select all

  <[F][C") "]This is a test

• Click OK

The files being created are named:

Code: Select all

this Is A Test
2) this Is A Test
3) this Is A Test
..

Expected: The files being created are named:

Code: Select all

This Is A Test
2) This Is A Test
3) This Is A Test
..

A similar thing happens for the New folder dialog.
One can debate what's supposed to happen here. Perhaps it's best to consider the counter not part of the filename when changing capitalization.

[ghisler(Author)]

Thanks, I will check it.

[ghisler(Author)]

I have analyzed this now - there isn't a simple solution. The string

Code: Select all

<[F][C") "]This is a test

first gets converted to

Code: Select all

<C") ">this Is A Test

where the counter is kept in angle brackets for later processing (separately for each file).
I think I will just skip the counter when doing the conversion. This would result in

Code: Select all

<C") ">This Is A Test

and therefore the names

Code: Select all

This Is A Test
2) This Is A Test

When using a conditional counter, I would prefer the same uppercasing for the name without the counter and the name with the counter. e.g.

Code: Select all

<[F][C""]This is a test

should become

Code: Select all

This Is A Test
2This Is A Test

But this would go against the uppercasing rules of the multi-rename tool, which would create

Code: Select all

1this Is A Test

with lowercase "t".

There could also be an inconsistency with non-conditional counters, e.g.

Code: Select all

<1-2>[F][C]This is a test

could become (consistent with conditional counters)

Code: Select all

1This Is A Test
2This Is A Test

or (consistent with multi-rename tool)

Code: Select all

1this Is A Test
2this Is A Test

[white]

I think I will just skip the counter when doing the conversion.

I thought the same as you. That's why I said:

One can debate what's supposed to happen here. Perhaps it's best to consider the counter not part of the filename when changing capitalization.

---

When using a conditional counter, I would prefer the same uppercasing for the name without the counter and the name with the counter. e.g.

I thought so too.

---

But this would go against the uppercasing rules of the multi-rename tool, which would create

There could also be an inconsistency with non-conditional counters, e.g.

I think a "conditional counter", as you call it, is entirely different from a counter. I think it is wrong to compare the two. As the help says, using the placeholder [C] without a counter like <1-10>, creates a name with optional digit if the target file already exist. So it's not a counter, but always creates a single file. It has a greater similarity with auto-rename function in the multi-rename tool when a target file already exists.

I think when using a counter (e.g. "<1-2>[F][C]This is a test"), the counter should ideally be considered part of the filename and work similar to the multi-rename tool.

[ghisler(Author)]

I come to the same conclusions now: When the counter isn't added to the first file of the range, the counter field must be skipped for the upper-/lowercase function, otherwise it is part of the name. This gives 4 cases:
1. no range, no quotes in [C]: skip field, e.g. <[F][C]This is a test
2. no range, with quotes in [C]: skip field, e.g. <[F]["("C")"]This is a test
3. range, no quotes in [C]: do not skip field, e.g. <1-3>[F][C]This is a test
4. range, with quotes in [C]: skip field, e.g. <1-3>[F]["("C")"]This is a test

The 4 cases would lead to names:
1. "This Is A Test", "2This Is A Test", "3This Is A Test" etc.
2. "This Is A Test", "(2)This Is A Test", "(3)This Is A Test" etc.
3. "1this Is A Test", "2this Is A Test", "3this Is A Test"
4. "This Is A Test", "(2)This Is A Test", "(3)This Is A Test"

In short, the first name determines whether the counter is part of the name or not.
Do you agree?

[white]

3. range, no quotes in [C]: do not skip field, e.g. <1-3>[F][C]This is a test
3. "1this Is A Test", "2this Is A Test", "3this Is A Test"

Yes, or an example where the counter is a letter:
3. range, no quotes in [C]: do not skip field, e.g. <1-3>[F][Ca]This is a test
3. "Athis Is A Test", "Bthis Is A Test", "Cthis Is A Test"

In short, the first name determines whether the counter is part of the name or not.
Do you agree?

Yes.

[white]

30.04.26 Fixed: New text file (Shift+F4), new folder (F7): skip counter fields when converting to upper/lowercase, e.g. for name <[F][C") "]This is a test (32/64)

Tested using TC 11.57rc6a.
Counter field are skipped as designed.
But when they are not skipped, there are issues. I thought you wanted consistency with the multi-rename tool and I gave you this example:

Yes, or an example where the counter is a letter:
3. range, no quotes in [C]: do not skip field, e.g. <1-3>[F][Ca]This is a test
3. "Athis Is A Test", "Bthis Is A Test", "Cthis Is A Test"

But the result is now:

3. "athis Is A Test", "bthis Is A Test", "cthis Is A Test"

Compare that to the multi-rename too when using: [F][Ca]This is a test

And when there is an error in the specification of the counter and this error is displayed in the preview with a variant of <C>, the capitalization is also done on this error. For example (accidental quote character):

Code: Select all

<1-50>[L][CAA"] TEST

Results in a preview of:

<caa"> test

Expected:

<CAA"> test

or:

<Error!>

[ghisler(Author)]

No, I didn't want 100% consistency with the multi-rename tool. Currently the [F] doesn't affect the counter itself, so use [CA] instead of [Ca].

[white]

No, I didn't want 100% consistency with the multi-rename tool. Currently the [F] doesn't affect the counter itself, so use [CA] instead of [Ca].

Yes, it does affect the counter. It coverts it to lowercase. So you cannot use [F][CA] instead of [F][Ca].
It's not only a inconsistency with the multi-rename tool, but also an inconsistency with [F] itself.
And [F] working with other placeholders like [N] and [X], but not working correctly with [C] is an inconsistency too.

Examples:

Code: Select all

<1-2>[U]["preFIX "CaA" postFIX "]testTEST

Resulting filenames:

TESTTEST
PREFIX AB POSTFIX TESTTEST

Code: Select all

<1-2>[L]["preFIX "CaA" postFIX "]testTEST

Resulting filenames:

testtest
prefix ab postfix testtest

Code: Select all

<1-2>[F]["preFIX "CaA" postFIX "]testTEST

Resulting filenames:

Testtest
prefix ab postfix Testtest

[ghisler(Author)]

Sorry, this is not feasible. [F] is applied before [C] is evaluated, so it's not possible to apply it to the inner part of the [C] correctly.
But I will skip the entire [C] parameter when applying lowercase via [F], not just when applying uppercase. This will also leave conditional strings untouched.

For clarification, I will add the following to the help:

The placeholders [F] and [f] (first letter of each word uppercase) leave the [C] field unchanged when using alphanumeric counters.

[white]

But I will skip the entire [C] parameter when applying lowercase via [F], not just when applying uppercase. This will also leave conditional strings untouched.

For clarification, I will add the following to the help:

The placeholders [F] and [f] (first letter of each word uppercase) leave the [C] field unchanged when using alphanumeric counters.

Tested using TC 11.57rc6c 32-bit and 64-bit.
Placeholders [F] and [f] leave the C field unchanged (including prefix and postfix, if used).
Why include "when using alphanumeric counters" in the help? It's with any kind of counter?

[ghisler(Author)]

That's because numbers don't have upper-/lowercase.

[ghisler(Author)]

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

[white]

For clarification, I will add the following to the help:

The placeholders [F] and [f] (first letter of each word uppercase) leave the [C] field unchanged when using alphanumeric counters.

...
Placeholders [F] and [f] leave the C field unchanged (including prefix and postfix, if used).
Why include "when using alphanumeric counters" in the help? It's with any kind of counter?

That's because numbers don't have upper-/lowercase.

But the prefix and postfix might have. Now you seem to suggest that these are changed when the [C] field is numeric. Perhaps something like this is better:

The placeholders [F] and [f] (capitalize first letter of each word) do not affect the [C] counter field (alphanumeric counters, prefixes and postfixes remain unchanged).

---

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

Confirmed.

[ghisler(Author)]

But the prefix and postfix might have.

Well actually alphanumeric means characters and/or digits, so it's not really wrong.

Thanks for confirming the bugfix!

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

Moved to fixed bugs