[TC 11.57rc4] Shift+F4: Using placeholder [C] at the beginning -> not working

[white]

If the name starts with the character '<', the same placeholders as in the multi-rename tool can be used.

1. Press Shift+F4
2. Enter:

   Code: Select all

   <[C]

3. Click OK

Nothing happens and no beep sound is played. This is a special case because the target file would have no filename, but the same things happens if you add any text after [C] in step 2.
If you add any text in front of [C], it works as designed.

When using "<[C]" in step 2, the name preview shows: "<C>". Is this on purpose, using the <..> notations similar to <Error!> to indicate no literal text?
When using "<some[C]text" in step 2, the name preview doesn't show <C> (thus the preview doesn't actually show the file that will be created if the file already exits).

[ghisler(Author)]

When using "<[C]" in step 2, the name preview shows: "<C>". Is this on purpose, using the <..> notations similar to <Error!> to indicate no literal text?

Yes, it shows <C> to indicate that there is no valid name due to using only the conditional counter. I will disable the OK button in this case.

When using "<some[C]text" in step 2, the name preview doesn't show <C> (thus the preview doesn't actually show the file that will be created if the file already exits).

This is intentional. The name is created after you press Enter or click OK, so the definitive name isn't known yet at the time of showing the preview.

[white]

Thread title:

[TC 11.57rc4] Shift+F4: Using placeholder [C] at the beginning -> not working

Further explained:

This is a special case because the target file would have no filename, but the same things happens if you add any text after [C] in step 2.
If you add any text in front of [C], it works as designed.

You have not responded to this issue. Can you confirm that using "<[C]some text" shows preview "some text" and that when you click OK, nothing happens? That no file is created and the editor is not launched? Can you confirm this is a bug?

When using "<[C]" in step 2, the name preview shows: "<C>". Is this on purpose, using the <..> notations similar to <Error!> to indicate no literal text?

Yes, it shows <C> to indicate that there is no valid name due to using only the conditional counter. I will disable the OK button in this case.

When using "<some[C]text" in step 2, the name preview doesn't show <C> (thus the preview doesn't actually show the file that will be created if the file already exits).

This is intentional. The name is created after you press Enter or click OK, so the definitive name isn't known yet at the time of showing the preview.

I fully understood that the final name isn't known at that time. That also means that the name shown by the preview of the filename might be wrong, right? In fact, by using [C] without a range (e.g. <1-4>) it is expected that the filename might not be the one shown by the preview. And there seems to be an obvious solution to that. You use the notation <C> for an indication of the counter. So why not use <C> in the name preview in the place in the name where the optional counter will be inserted?

[ghisler(Author)]

You have not responded to this issue. Can you confirm that using "<[C]some text" shows preview "some text" and that when you click OK, nothing happens? That no file is created and the editor is not launched? Can you confirm this is a bug?

No, that seems to be a different issue. You reported about <[C] which would create an empty name.

[white]

You have not responded to this issue. Can you confirm that using "<[C]some text" shows preview "some text" and that when you click OK, nothing happens? That no file is created and the editor is not launched? Can you confirm this is a bug?

No, that seems to be a different issue. You reported about <[C] which would create an empty name.

No, that is not factually correct. You may have interpreted it that way, but that's not what I actually reported. I already quoted the parts that show this but I will explain further.

Thread's subject:

[TC 11.57rc4] Shift+F4: Using placeholder [C] at the beginning -> not working

The thread's subject claims that using the placeholder [C] at the beginning is not working. This means that anything can follow [C]. If I would have said using the placeholder at the right, anything could precede the placeholder. And if I would have said using the placeholder in the middle, anything could precede and follow the placeholder. In the context of a situation where you can only have <[C], speaking of the beginning makes no sense. The beginning of what?

As quoted before, it was further explained by the following text. I'm quoting a slightly bigger part now and I emphasized the parts that make clear that the issue involves a case where anything can follow after the placeholder [C].

Nothing happens and no beep sound is played. This is a special case because the target file would have no filename, but the same things happens if you add any text after [C] in step 2.
If you add any text in front of [C], it works as designed.

So the case of "<[C]some text" is explicitly worded.

[white]

Tested TC 11.57rc4a 64-bit.

Changelog:

19.04.26 Fixed: New text file (Shift+F4): Name >[C]test didn't create any file (32/64)

Typo:
>[C]test <[C]test

Test result:
No change, still doesn't work.

[ghisler(Author)]

Sorry, the private beta I sent you only fixes the <[C] error in your example. <[C]test doesn't work because it gets converted to <C>test and TC assumes that <C> at the start is a faulty range like <1-5>. The fix you quote was made only after I saw your additional info here.

[white]

Sorry, the private beta I sent you only fixes the <[C] error in your example.

I can confirm this change:

Yes, it shows <C> to indicate that there is no valid name due to using only the conditional counter. I will disable the OK button in this case.

[ghisler(Author)]

Please re-check this bugfix with Total Commander 11.57 RC5.

[white]

19.04.26 Fixed: New text file (Shift+F4): Name <[C]test didn't create any file (32/64)

Tested OK using TC 11.57rc5 32-bit and 64-bit.

[ghisler(Author)]

Great, thanks!

Moderator message from: ghisler(Author) » 2026-04-23, 07:26 UTC

Moved to fixed bugs