Сергей ФроловAniskinImho основная проблема построения UI на Delphi происходит от изначально выбранной Борландом парадигмы - фиксированный DPI 96 и контролы, прибитые гвоздями к форме по фиксированным позициям (всякие алигны и маргины погоды не далают). В эпоху Win95 это имело смысл, сейчас же, в эпоху High DPI и возможности смены DPI на лету, уже нет. Без смены парадигмы, т.е. без ухода от dfm, особо ничего не сделаешь, только хардкор расчет размеров и позиций контролов на лету в соответствии с выбранным шрифтом, точнее его DLU, который в свою очередь зависит от текущего DPI окна (оно может быть разным в разные моменты времени), и в соответствии с Windows User Experience Interaction Guidelines. Это относительно геморно, но не рокет саенс, много времени разработчика не занимает. Я практически с самого начала делал это и это помогло мне без проблем перейти на High DPI, и формочки отображаются корректно без виндового размытия, и при перетаскивании окна с одного монитора на другой, имеющий иной DPI, окно автоматически изменяет свои размеры, и т.п.
Коллега, вынужден вас разочаровать: Delphi Tokyo вполне себе хорошо работает с разными DPI. Не сама среда, хотя она тоже очень улучшилась, а приложения, разрабатываемые в ней. У меня проблема только с ресурсами (иконками) возникла при переводе сортов на работу с HighDPI, потому и создал тему, чтобы посмотреть как народ выкручивается.

это ты про FMX? тогда не интересно.

или в VCL что-то новое привинтили? что именно?

AniskinСергей Фроловвынужден вас разочароватьОк, я только рад, что ситуация изменилась. Сам я не пробовал последние версии, сижу на XE3.

не изменилась, они лишь в очередной раз попытались починить TForm.Scaled и иже

http://zarko-gajic.iz.hr/delphi-high-dpi-road-ensuring-your-ui-looks-correctly/

починили не всё и не везде.

опять в треш

Сергей Фроловdbpatchне изменилась, они лишь в очередной раз попытались починить TForm.Scaled и иже

http://zarko-gajic.iz.hr/delphi-high-dpi-road-ensuring-your-ui-looks-correctly/

починили не всё и не везде.

опять в треш
Да что же ты какой упоротый-то ))))
Статья, которую ты привел в пример, написана в феврале, еще до выхода Токио.
Не понимаю, что мешает взять, да попробовать?!?

У меня все нормально работает. Кроме, повторюсь, ресурсов.

работа в абсолютных координатах - это в любом случае треш и угар. кроме, конечно, случаев кратного масштабирования - 2x, 4x и так далее, но к винде это не применимо.

сколько не чини костыль - это будет лишь костыль. костыль, приложенный к изначально кривому костылю - это лишь два костыля на выходе, сколько не утверждай, что это нормальное решение.

работать нужно в не в пикселях, а логических единицах, тогда будет все ок. но VCL не умеет как либо еще, кроме как в пикселях.

Докdbpatchработать нужно в не в пикселях, а логических единицах
ты, я смотрю, уже познал дзэн. Весь в белом, чо...

я? нет, не познал. счастья нет, везде они недоработки - я же говорил об этом вон выше в плаче Ярославны про WebComponents

Kazantsev Alexeydbpatchработать нужно в не в пикселях, а логических единицах, тогда будет все ок
Вот ты говорил:
dbpatchвсе что более менее годное - это HTML5 (встраиваемые движки WebKit и Trident)
А в чём задают размеры в вебе? В em, mm, pt? Нет, почти все размеры в пикселях. Просто пиксели относительны, а браузеры научились нормально зумить. Ну так и в дельфе пиксели относительны.

в HTML Layout допустимо использование пикселей, факт. к примеру 0 (ноль) пикселей - очень даже допустимо.
а так меряем в em-ках.

иногда допустимы и указания в px, к примеру если линии рисовать какие надо. но как ты верно заметил, в случае HTML движков
px это не совсем пиксель, собственно он крайне редко бывает именно экранным пикселем в итоге.

но я говорил скорее про то, что недопустимо работать в пикселях в абсолютных координатах, а не в относительных,
писал просто "по-диагонали", подразумевал одно, а барабанил на автомате про другое.

не стоит думать, что все настолько уже запущено :) чай не про искруфм говорим.