Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Если статические, попробуйте, например, Static Text слева от Edit/Combo Box, чтоб при масштабе 100% текст отображался полностью, и заканчивался где-то в 6-7 точках от следующего элемента. При масштабе 125% такой текст обрезается и в Win7, и в Win8, и в Win10/11, независимо от наличия/отсутствия манифестов поддержки DPI. Если увеличивать интервал до 8-10 точек, то в масштабе 100% образуется слишком широкий зазор.

ЕМ>Я так понимаю, это все от кривого пересчета DLU в точки.

В DLU задается размер элемента, а GDI рендерит текст по размеру в логических пикселях.
Т.е. не "вписывает" каждую буковку в DLU-шную сетку диалога.
Из-за растризации каждой буквы и связанного с ней округления накапливается разница в длине.
Растризация выполняется в физические пиксели монитора, а не в логические.
Например, линия в 1 логический пиксель при масштабе 200% растризуется в 2 физических пикселя, а при 125% — в один.
Эта проблема GDI особенно сильно вылазила для печати и предварительного просмотра, где масштаб меняется в широких пределах, а также DPI принтера может быть очень разным.

И второй эффект, который может влиять даже сильнее округления при растризации.
Размер шрифта диалога задается в поинтах, которые также привязаны к логическим пикселям в условиях фиксированного DPI.
В структуре LOGFONT за размер отвечает поле lfHeight, где как раз логические пиксели.
И тут просто не хватает точности указания этой высоты. Например, -10 и -12 (в норме она отрицательная).
Если бы они использовали логические пиксели умноженные на 10 хотя бы, то можно было бы задавать -105, например.
Допустим шрифт у нас с высотой -10 на 100%, на 125% он будет -12, а не -12.5 (а это уже 4% разницы).