Since the major update for DPI awareness the column width calculation is slightly off; if you double-click a cloumn separator it shd widen the col to show all contents, but very often the right side ends in an elipse. Same for cntl-keypad_asterisk [does all columns].
Prior to this DPI update it always worked right.
Minor, but worth a look! Thanks.
Could you narrow that down?
I think there is a maximum column width and if that is reached then the column does not become any wider.
Or, as far as I have experienced it, the column width goes as wide as the longest text in a visible field except those that would exceed the maximum width.
How long is long?
On both Windows and Linux, the field expands to show this complete text.
Waltraud Meier, Mitì Truccato Pace, Etc.; Riccardo Muti: Berlin Philharmonic Orchestra, Swedish Radio Chorus, Stockholm Chamber Choir
I can't reproduce this, also not with various DPI settings.
It would be helpful if you could be more specific about the situations in which you observe the described behaviour.
Florian,
sorry for the long delay in providing some more info to chase bug.
my MESSAGE BOX font is: Segoe UI Semibold 10pt
so are ICON and STATUS BAR fonts
MENU and TITLE BAR fonts are same but 11 pt.
these are slightly larger than default, but when using default the issue is the same,
I reverted the above choices and it didn't fix it.
Win 10 22H2 fully updated. vcredist's fully updated. .Net thru 4.8.1 fully updated.
my screen is std 96 dpi, no hi dpi at all, no HDR. running at 1920x1080, 100% scale.
included in attachment are two folders w/ sample files, m4a's, with tags that do not display "full width"
when pressing ctl-keypad-plus, or double-clicking the column divider bar. [tried them as mp3, same results]
look at each folder loaded into mp3tag independently and then together, they display the bug slightly
differently when there is just the one, or both [as you would expect].
bug can be seen in path name, artist, filename and title columns. [as you would expect, column independent]
It's been a while since I wrote code myself for this but as i recall my solution was just to "add one"
to whatever the width calc came up with and it looked alright!
Anyway, issue still there in v3.28k.
Happy Bug hunting!
TestCases.zip (722.0 KB)
This is what the columns look like after the column divider of the important columns has been double-clicked to get the optimum width:
These were screenshots from W10
The following screenshot is from W11 and shows the 2 test cases and another one with truncated data as the column was not wide enough
TBH: that looks perfectly OK to me.
When you write "the right side ends in an ellipse", do you refer to the data in the column or to the column header text?
On my system your test M4a file data never shows an ellipse after the double click, but the column headers sometimes do. That is normal. Headers always shrink when their text is wider than the widest data string below them. In that case, the header text will show the ellipse dots. As far as I know, Mp3tag columns have always worked this way.
ok, here's some pics too. W10 x64 mp3tagx64 too.
all col headers dbl-clicked [ or ctl-numpad+].
note the ellipses [in data field, not header] because col isn't wide enough.
on my machine, drag divider SLIGHTLY to right and elipse goes away; dbl-click divider and it comes back - too narrow! by just a pixel or two I'd guess 
just a gnat buzzing in the ear...
Thanks for playing...
FWIW, pics don't show that this window scrolls to right, you cant see the lower scroll bar. ie, normal.
I can only repeat that it does not happen on my laptop. So it could be something local like the interaction of graphics card and display...
Or I tried, starting from ludicrously narrow columns and tried the double-click on the columns divider and the ctrl-numpad+ and always got ideally widened columns.
Sorry, I am no help to find the problem.
What is the maximum column width?
I don't know if that is the same on every machine.
I filled a field (here: Lyrics) with a long text and double-clicked on the column divider:
and that seems to be 251 characters
Even though it is possible to grab the divider and widen the column, the displayed text remains the same.
It seems to be content related in multiline-fields because I get different maximum lengths if I define a column for Unsyncedlyrics. The ellipse shows up at the end of these columns at different places.
But I think this has nothing to do with this topic and we should not discuss it further here.
I removed all line breaks from the text - if that helps
Yes, that's what I meant with "content related". LF and CR don't show up in a column.
TBH I did not count the characters myself but used $len().
251 characters looks like one of these magic computer numbers. If you add the 3 dots, it sums up to 254 which is even closer to the whole byte.
It still does not explain why (locally) the same text sometimes gets displayed with 3 dots and sometimes it does not.
There was once this case of a docked window from another application that caused a miscalculation of window sizes
so perhaps something similar is the case here.
I'm moving this to Support as I don't find a way to reproduce this. I've tested various versions of Windows now, using custom font settings (even bold fonts), and all work as expected.
The feature of adjusting the column width is something that's provided by the system, when using a standard list control (which Mp3tag does), so it might "repair" itself in the future via a Windows update.
