Total Commander

In the cm_EditNewFile command dialog box, swap the "Tree" and "OK" buttons according to the standard - screen

It also makes sense to add the same "Tree" button to the F7 dialog:
https://ibb.co/C6MJwMQ
The position can be either to the left of the OK button or to the right - as in the picture above.
To the Right - is more preferable of course.

I support adding the "Tree" button to the F7 dialog box to the right of the "OK" button

I prefer keeping the tree button on the left, because it is wider and would look strange like that between the two buttons.

Moderator message

ghisler(Author) wrote: ↑2023-06-28, 10:36 UTC I prefer keeping the tree button on the left, because it is wider and would look strange like that between the two buttons.

Sure. Please change these dialogs: Screenshot

Moderator message from: white » 2023-06-28, 11:27 UTC

There the tree button isn't wider...

Moved back to suggestions. It's not a bug.

ghisler(Author) wrote: ↑2023-06-28, 13:03 UTC There the tree button isn't wider...

Then make it wider there as well, so you can put it in front. That seems to be what you want.

BTW, why doesn't the + button have a tab stop?

I just checked, cm_EditNewFile doesn't even have a tree button(?).

The + button is a "speed button" which cannot be focused. The idea was that tab still goes to OK after adding this button.

I just checked, cm_EditNewFile doesn't even have a tree button(

Hmm, it looks very much like it does here: https://tcmd.madsenworld.dk/editnewfiletreebutton.png

But the cm_MkDir dialog does not have a tree button.

ghisler(Author) wrote: ↑2023-06-28, 14:37 UTC I just checked, cm_EditNewFile doesn't even have a tree button(?).

Yes, it does.

ghisler(Author) wrote: ↑2023-06-28, 14:37 UTC The + button is a "speed button" which cannot be focused. The idea was that tab still goes to OK after adding this button.

It goes to the Tree button now..

"The idea was that tab still goes to OK after adding this button" makes no sense to me. Tabbing is meant to navigate through all controls, hotkeys are meant to directly activate a control.

2ghisler(Author)

There the tree button isn't wider...

And what tool did you use when you claim the fact of the difference in size?
Moreover, as I understand it, there is a very significant difference (isn't it?), since in the above two dialogs
you refuse to place the button where it ALREADY exists in other shown dialogs - and for a long time - after the OK button ...
How accurately are these "Tree" buttons NOT wider - that they can't be made by analogy like 'the first button' on a form?
exactly 1 pixel, or maybe 5px/10/12/...?

P.S.
I venture to clarify that my drawing is a sketch of what the dialog COULD look like!
This is not the real state of affairs just in case;)

Button "OK" should be located as in the system dialogs, all else is wrong.

Ah, I get it - the tree button gets hidden when you start the name with < to use placeholders. The space is then needed to show the name preview.

ghisler(Author) wrote: ↑2023-06-29, 09:04 UTC Ah, I get it - the tree button gets hidden when you start the name with < to use placeholders. The space is then needed to show the name preview.

This seems like a weird solution to me. Wouldn't it be better to make room above the buttons?
BTW, why is there so much room above the input field?

This seems like a weird solution to me. Wouldn't it be better to make room above the buttons?

It needs up to two lines when using a counter. And the tree button doesn't work when there are placeholders, so why not?

BTW, why is there so much room above the input field?

It's a standard dialog also used in other functions, where the text can get longer.