Layout column 'Size'
Moderators: Hacker, petermad, Stefan2, white
Layout column 'Size'
I guess the layout of the column 'Size' is not correct: The size-values should not be out of the bounds of the field 'Size'. If the size is too big for the field, it should be displayed with points at the beginning, e.g. '...99999'.
Anyway the size-values should be right-justified (like it is) and they should start on the right border of the field.
As you can see in the screenshot, the length of the column 'Size' should be quite big enough, but the values don't start on the right border.
I'm not sure if this is a bug of release 7.5. It's possible that this bug is already in earlier version.
P.S.: Screenshot ... Isn't it possible to add attachments here?
Anyway the size-values should be right-justified (like it is) and they should start on the right border of the field.
As you can see in the screenshot, the length of the column 'Size' should be quite big enough, but the values don't start on the right border.
I'm not sure if this is a bug of release 7.5. It's possible that this bug is already in earlier version.
P.S.: Screenshot ... Isn't it possible to add attachments here?
- Balderstrom
- Power Member
- Posts: 2148
- Joined: 2005-10-11, 10:10 UTC
No attachments, use: ["url=http://address.com ]Name of link["/url"]
Without quotes.
I'm not sure what you mean, size is right justified, and I (at least) wouldn't want leading "." dots instad of spaces.
Without quotes.
I'm not sure what you mean, size is right justified, and I (at least) wouldn't want leading "." dots instad of spaces.
Configure…
2rsa
Hello !
• What about Configuration >> Options >> Tabs-top >>Size display [Dynamic…] ?
- With the items sizes we have nowadays, displaying them as Bytes is of course getting an issue…
…pratically insolvable easily in the current GUI…
- With also the new hard disks in the TiB range, a problem is coming, even with the [Dynamic…] choices.
- But that's another song.
KR
Claude
Clo

• What about Configuration >> Options >> Tabs-top >>Size display [Dynamic…] ?
- With the items sizes we have nowadays, displaying them as Bytes is of course getting an issue…
…pratically insolvable easily in the current GUI…
- With also the new hard disks in the TiB range, a problem is coming, even with the [Dynamic…] choices.
- But that's another song.

Claude
Clo
#31505 Traducteur Français de T•C French translator Aide en Français Tutoriels Français English Tutorials
- ghisler(Author)
- Site Admin
- Posts: 50505
- Joined: 2003-02-04, 09:46 UTC
- Location: Switzerland
- Contact:
The reason why it's done this way is because you can set the distance between size and date field! You couldn't do this if it were right-aligned. You can use a custom columns view if you don't like it, there it is right-aligned.
Author of Total Commander
https://www.ghisler.com
https://www.ghisler.com
Yes, on a custom columns view the size is right-justified by default and it's starting on the right border of the column. This is basically what I expect.
Nevertheless it's unordinary to me that the size-values mutate to "left-justified" in this view if the size-value is bigger than the column size.
See what I mean!
If the column-size is big enough, everything looks OK:
If you make the column smaller, the bigger size-values will mutate to left-justified and get "..." at the end. IMHO this is OK for left-justified values, but not for right-justified values.
For right-justified values, I think it should be displays like this:
To use the size left-justified makes no sense for me.
Anyway, now I know why you didn't have the column size linked to the right border, even if it would be no problem for me.
Maybe it would be the best way - at least for right-justified columns - if you can have spacing between the border of the column and the starting of the data. Than you can set the distance between the size and date field and you can also have the values linked to the right border. In any case I would not make any field overflowing (like it is now in the default view on the columns size which is running into the column extension).
Nevertheless it's unordinary to me that the size-values mutate to "left-justified" in this view if the size-value is bigger than the column size.
See what I mean!
If the column-size is big enough, everything looks OK:
Code: Select all
|---size---|
1
12
123
1.234
12.345
123.456
1.234.567
12.345.678
Code: Select all
|-size-|
1
12
123
1.234
12.345
123...
1.23..
12.3..
Code: Select all
|-size-|
1
12
123
1.234
12.345
...456
...567
...678
To use the size left-justified makes no sense for me.
Anyway, now I know why you didn't have the column size linked to the right border, even if it would be no problem for me.
Maybe it would be the best way - at least for right-justified columns - if you can have spacing between the border of the column and the starting of the data. Than you can set the distance between the size and date field and you can also have the values linked to the right border. In any case I would not make any field overflowing (like it is now in the default view on the columns size which is running into the column extension).
- Balderstrom
- Power Member
- Posts: 2148
- Joined: 2005-10-11, 10:10 UTC
I think his problem, primarily is that
EXT and SIZE will display into each other's horizontal space, if they exceed their defined (left/right) space limits.
They only seem to do this for the default "Details View", Generally I prefer this behaviour and am used to it.
It would actually be interesting to have a setting that would allow this behaviour for individual Custom Columns -- as this only occurs (as I said) for Details (Full) View.
EXT and SIZE will display into each other's horizontal space, if they exceed their defined (left/right) space limits.
They only seem to do this for the default "Details View", Generally I prefer this behaviour and am used to it.
It would actually be interesting to have a setting that would allow this behaviour for individual Custom Columns -- as this only occurs (as I said) for Details (Full) View.
*BLINK* TC9 Added WM_COPYDATA and WM_USER queries for scripting.