Независимый пользовательский интерфейс от размера шрифта: все сломалось, когда я переключился на 120 точек на дюйм?

Итак, я читал те рекомендации по пользовательскому интерфейсу Windows Vista, на которые кто-то ссылался в другом вопросе, и они упомянули, что вы сможете пережить переключение на 120 точек на дюйм. Ну, я запускаю свою удобную виртуальную машину с установленным приложением, и что мы получаем ... АААААА !!! МАССИВНАЯ НЕИСПРАВНОСТЬ UI!

Все перемешано: некоторые контейнеры не достаточно велики для своего текста; некоторые элементы управления, которые были расположены «рядом друг с другом», теперь сдвинуты вместе / раздвинуты; некоторые пуговицы недостаточно высокие; мои ListView столбцы недостаточно широки ... эй.

Похоже, здесь нужен совершенно другой подход. Мой предыдущий в основном использовал конструктор Windows Forms VS2008 для создания, я полагаю, макета на основе пикселей. Я вижу, что если бы я придерживался Windows Forms, FlowLayoutPanels были бы мне полезны, хотя в прошлом я считал их довольно негибкими. Они также не решают проблему, когда контейнеры (например, сама форма) недостаточно велики; по-видимому, есть способ сделать это? Может, это AutoSize свойство?

Это также может быть признаком того, что пора перейти на WPF; У меня сложилось впечатление, что он специально разработан для такого рода вещей.

Основная проблема, кажется, сводится к следующему:

  • Если бы я придерживался Windows Forms, каковы были бы все уловки для достижения независимого от размера шрифта макета, который мог бы выжить, если бы пользователь установил свои шрифты большими или установил отображение на 120 точек на дюйм?
  • Есть ли здесь у WPF значительные преимущества, и если да, то можете ли вы убедить меня, что это стоит перехода?
  • Существуют ли какие-либо общие «лучшие практики» для макетов, не зависящих от размера шрифта, в стеке .NET или вообще?

user-interface .net fonts wpf winforms
person Domenic    schedule 08.09.2008    source источник

Ответы (3)


arrow_upward
11
arrow_downward

Узнайте, как свойства Anchor и Dock работают с вашими элементами управления, оставьте все, что поддерживает AutoSize, и используйте TableLayoutPanel, когда можете.

Если вы сделаете эти три вещи, вы получите много возможностей дизайна WPF в Windows Forms. Хорошо спроектированный TableLayoutPanel сделает все возможное, чтобы размер элементов управления соответствовал форме. В сочетании с элементами управления AutoSize, стыковкой и AutoScaleMode, упомянутым Сереном Куклау, вы сможете создать что-то, что хорошо масштабируется. В противном случае на вашей форме может быть слишком много элементов управления; рассмотрите возможность разделения его на вкладки, плавающие панели инструментов или другое пространство.

В WPF это намного проще, потому что встроена концепция автоматического изменения размера; в большинстве случаев, если вы размещаете элемент WPF с помощью пары координат, вы делаете это неправильно. Тем не менее, вы не можете изменить тот факт, что при более низких разрешениях для заполнения экрана не требуется много текста с разрешением 120 dpi. Иногда проблема не в макете, а в попытке разместить слишком много на небольшом пространстве.

person OwenP    schedule 08.09.2008
comment
Я всегда использовал Anchor, Dock, AutoSize и TableLayoutPanels для создания переводимых пользовательских интерфейсов и создания форм с изменяемым размером. Однако при высоких настройках DPI с отключенным флажком масштабирования DPI в стиле XP я обнаружил, что все мои приложения имеют размытые шрифты. Есть какие-нибудь советы по исправлению этого? - person Roman Starkov; 24.10.2009
comment
@romkyns: если ваше приложение специально не заявляет, что оно поддерживает высокое разрешение, ваше приложение получит такое же исправление kludge, что и все другие приложения с ошибками. Когда вы запрашиваете текущее значение dpi, вашему приложению лгут (говорят, что это 96), и графическая карта масштабирует вашу форму за вас, делая ее размытой. Microsoft отказалась от попыток заставить разработчиков делать то, что они должны делать, - поэтому каждый должен отказаться от масштабирования. Google: dpiAware манифест. - person Ian Boyd; 19.06.2011

arrow_upward
4
arrow_downward

Если бы я придерживался Windows Forms, каковы были бы все уловки для достижения независимого от размера шрифта макета, который мог бы выжить, если бы пользователь установил свои шрифты большими или установил отображение на 120 точек на дюйм?

Например, AutoScaleMode может быть вашим другом. .

person Sören Kuklau    schedule 08.09.2008

arrow_upward
4
arrow_downward

В общем, проблема заключается в использовании двух разных «констант» для макета формы и последующем изменении одной из этих констант без изменения другой.

Вы используете пиксели для объектов формы и точки (в основном дюймы), чтобы указать размер шрифта. Пиксели и точки связаны с помощью DPI, поэтому вы меняете DPI, и внезапно фиксированные значения пикселей не совпадают с фиксированными значениями точек.

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

Лично я бы изменил объекты на форме на дюймы. Я не специалист по C #, поэтому не знаю, поддерживается ли это изначально или вам нужно выполнить динамическое изменение размера формы при запуске приложения.

Если вам нужно сделать это в своем программном обеспечении, тогда продолжайте и настройте все как обычно (скажем, до вашего обычного 96 DPI).

Когда ваше приложение запускается, убедитесь, что система установлена ​​на 96 точек на дюйм, прежде чем показывать формы. Если это так, отлично. В противном случае установите переменную с поправочным коэффициентом, а также масштабируйте и перемещайте (изменяйте расположение и размер) каждого объекта перед отображением формы.

В конечном итоге, однако, можно было бы указать все в дюймах или точках (точка составляет 1/72 дюйма) и позволить ОС заниматься этим. Возможно, вам придется иметь дело с угловыми случаями (уличный экран с правильно настроенным DPI будет отображать ваше приложение в нескольких пикселях ...)

person Adam Davis    schedule 08.09.2008