Масштаб основного дисплея равен 125 visual studio

Обновлено: 05.07.2024

Большинство приложений Windows 8 строится на основе экземпляров класса Page. Конечно, это не является обязательным требованием, но предоставляет некоторые удобства, например упрощенную интеграцию строк приложений. До этой статьи рассматривались только программы, имеющие единственный экземпляр класса, производного от Page, с именем MainPage. Пора заняться программами, поддерживающими многостраничную навигацию в стиле веб-приложений.

В Visual Studio входят два шаблона проектов многостраничных приложений - Grid App и Split App. Эти шаблоны строятся на базе мощных элементов управления ListView и GridView и используют их в моделях представлений. Эти шаблоны также реагируют на изменения ориентации экрана и режима Snap View, так что эта и последующие статьи станут хорошей отправной точкой для изучения проблем, связанных с изменением размеров окна.

Обработка изменения размеров окна - задача, хорошо знакомая Windows-программистам. В большинстве традиционных настольных Windows-программ имеется рамка изменения размеров, при помощи которой пользователь может управлять размером и пропорциями окна приложения. Windows-программистов 25 лет учили писать программы, адаптирующиеся к размеру окна, выбранному пользователем. Конечно, это возможно не всегда: что должна делать электронная таблица, если пользователь уменьшит окно так, что не останется ни одной видимой ячейки? Некоторые программы - например, Калькулятор - просто устанавливают фиксированный размер окна, достаточный для отображения всего содержимого программы. Для традиционных настольных приложений такое решение приемлемо только в том случае, если окно заведомо меньше экрана.

Приложения Windows 8 в основном работают в полноэкранном режиме, и проблема минимального размера экрана для них менее актуальна. Однако приложения Windows 8 также подвержены изменениям ориентации экрана и включению Snap View, и многие приложения должны обрабатывать такие изменения.

Проблемы разрешения экрана

Экран компьютера имеет фиксированный горизонтальный и вертикальный размер в пикселах, а также физический размер, который обычно задается как величина диагонали в дюймах. Зная эти размеры, по теореме Пифагора можно вычислить разрешение в пикселах на дюйм (эта единица также обозначается сокращением ).

Например, диагональ экрана с размерами 1024 x 768 пикселов равна 1280 пикселам. Если физический размер диагонали составляет 12 дюймов, то разрешение составляет 106 DPI. Диагональ 23-дюймового настольного монитора со стандартным режимом высокого разрешения 1920 x 1080 пикселов содержит около 2203 пикселов с разрешением 96 DPI. У 27-дюймового монитора с экраном 2560 x 1440 пикселов разрешение около 109 DPI.

Ранее я говорил, что разрешение экрана можно считать равным 96 пикселам на дюйм. Как видите, эта оценка неплохо подходит для трех мониторов из приведенного примера, хотя вам могут встретиться мониторы, для которых это правило заметно искажено: при работе я использовал планшет Samsung с размером экрана 1366 x 768 и диагональю 11,6 дюйма с разрешением 135 DPI. Если нарисовать на этом экране квадрат со стороной 96 пикселов, то вместо дюйма длина стороны составит около 0,7 дюйма.

Предположение о разрешении 96 DPI чаще всего нарушается для малых экранов с большим количеством пикселов. Для примера возьмем экран с диагональю 10,6 дюйма и размером 1920 x 1080 пикселов. Разрешение такого экрана составляет 208 DPI; соответственно дюймовый (по мнению программиста) объект будет занимать на нем менее половины дюйма. Текст уменьшается, и хотя его все еще можно прочитать из-за высокой плотности пикселов, выполнять с ним операции на сенсорном экране уже неудобно.

По этой причине Windows 8 пытается компенсировать высокое разрешение экрана способом, относительно прозрачным для приложений: если размер экрана в пикселах составляет 2560 x 1440 и выше, а физический размер, допустим, равен 12 дюймам (что дает разрешение 240 DPI и выше), Windows изменяет координаты в пикселах и размеры, используемые в приложении, на 180 %. С точки зрения приложения экран 2560 x 1440 имеет размер 1422 x 800 пикселов.

Если экран не обладает такой высокой плотностью пикселов, но обладает размером не менее 1920 x 1080, а физический размер достаточно мал для обеспечения разрешения 174 DPI и выше, Windows 8 изменяет все размеры в пикселах на 140 %; таким образом, экран 1920 x 1080 с точки зрения приложения имеет размер 1371 x 771 пикселов.

Помните, что все эти автоматические корректировки применяются только для физически малых экранов с большим количеством пикселов. Физически большой экран с фактическим разрешением ниже 174 DPI изменяться не будет, а следовательно, приложение будет «видеть» его полный размер.

В Windows Runtime предполагаемое разрешение экрана называется . Обычно логическое разрешение равно 96, но для экранов с большой плотностью пикселов оно может составлять 134,4 (96 DPI, умноженное на 140 %) или 172,8 (96 DPI, умноженное на 180 %).

Давайте посмотрим, как работает эта система. Программа WhatRes похожа на программу WhatSize, представленную в статье События изменения размера и ориентации в WinRT, но помимо размера окна (который совпадает с размером страницы) она получает информацию о разрешении экрана.

Файл XAML в проекте WhatRes просто создает экземпляр TextBlock:

Файл фонового кода назначает обработчики для события SizeChanged страницы, а также для статического события LogicalDpiChanged класса DisplayProperties, определенного в пространстве имен Windows.Graphics.Display:

В реальном приложении событие DisplayProperties.LogicalDpiChanged будет инициироваться довольно редко, потому что размер экрана в пикселах или его физический размер обычно не изменяются во время выполнения программы. Впрочем, событие может быть инициировано при подключении к компьютеру с Windows 8 второго монитора, имеющего другое логическое разрешение, и перемещении программы с одного монитора на другой.

Программа WhatRes сначала получает размер окна из свойств ActualWidth и ActualHeight страницы, а затем вычисляет фактический размер в пикселах по данным DisplayProperties.LogicalDpi.

Программа WhatRes хорошо подходит для запуска в эмуляторе Windows 8, который можно выбрать на стандартной панели инструментов Visual Studio. Эмулятор позволяет запускать приложение с некоторыми распространенными размерами экранов. Например вот как выглядит WhatRes на эмулируемом экране 1920 х 1080 с диагональю 10,6 дюйма:

Для приложения Windows 8 окно имеет размер 1371 х 771, и весь отображаемый в нем текст и графика базируются на этом размере. Вычисленный размер в пикселах совпадает с размером экрана в пикселах. Как видите, шрифт с размером 18 пунктов занимает ту же относительную площадь, как и на экране 1366 х 768.

Проблемы масштабирования

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

Итак, правильнее будет сказать, что графический вывод или задание размеров осуществляются не в пикселах, а в , или просто в единицах (units). Некоторые авторы называют эти единицы «аппаратно-независимыми пикселами», но этот термин слишком сильно отдает оксюмороном.

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

Масштаб разрешения, %
DIU	100	140	180
5	5	7	9
10	10	14	18
15	15	21	27
20	20	28	36

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

Когда Windows вносит эти изменения, текст и векторная графика масштабируются без потери разрешения. Например, если задать свойству FontSize значение 20, а ваша программа выполняется на экране с масштабом разрешения 180%, вы не получите шрифт с размером 20 пикселов, увеличенный на 180% с соответствующей потерей четкости и неровностями. Вместо этого используется сглаженный, полноценный шрифт с размером 36 пикселов.

С растровыми изображениями дело обстоит иначе. Растровое изображение имеет конкретный размер в пикселах, а при выводе 200-пиксельного квадратного изображения с фактическим размером у Windows не остается другого выбора, кроме как масштабировать изображение на 140 или 180% с потерей четкости. Чтобы этого не произошло, вы можете создать для своего приложения растровые изображения трех разных размеров (например, 200, 280 и 360 пикселов). Их можно даже сохранить в ресурсах программы, чтобы система Windows автоматически выбрала правильную версию!

В этой статье рассматриваются ограничения конструктора Windows Forms на HDPI-мониторах и описывается запуск Visual Studio без поддержки DPI.

Visual Studio — это приложение с поддержкой DPI, что означает автоматическое масштабирование монитора. Если в приложении указано, что оно не поддерживает DPI, операционная система масштабирует приложение в виде точечного рисунка. Такое поведение также называется виртуализацией DPI. Приложение по-прежнему считает, что работает в полном масштабе (100 % соответствует 96 точкам на дюйм).

Масштабирование: конструктор Windows Forms на HDPI-мониторах

Конструктор Windows Forms в Visual Studio не поддерживает масштабирование. Поэтому при открытии некоторых форм в конструкторе Windows Forms возникают проблемы с отображением на HDPI-мониторах. Например, элементы управления могут перекрываться, как показано на следующем рисунке:

Когда вы открываете форму в конструкторе Windows Forms в Visual Studio на HDPI-мониторе, в верхней части конструктора отображается желтая информационная панель.

Эта информационная панель появилась в Visual Studio 2017 версии 15.8.

Если вы не работаете в конструкторе и вам не нужно настраивать макет формы, игнорируйте информационную панель и продолжайте использовать редактор кода или конструкторы других типов. (Можно также отключить уведомления, чтобы информационная панель больше не появлялась.) Затрагивается только конструктор Windows Forms. Чтобы продолжить работу в конструкторе Windows Forms, выполните приведенные в следующем разделе действия по устранению этой проблемы.

Устранение проблем с HDPI-дисплеем

Существует три варианта устранения проблемы с отображением.

Если вы предпочитаете управлять параметрами из командной строки, devenv.exe принимает /noscale в качестве параметра командной строки для выполнения в режиме с масштабом 100 %.

Перезапуск Visual Studio без поддержки DPI

Чтобы перезапустить Visual Studio без поддержки DPI, выберите соответствующий параметр на желтой информационной панели. Это предпочтительный способ решения проблемы.

Если при выборе параметра перезапуска без поддержки DPI в Visual Studio были незакрепленные окна инструментов, положение этих окон инструментов может измениться.
Если используется профиль Visual Basic по умолчанию или в меню Сервис > Параметры > Проекты и решения не выбран параметр Сохранять новые проекты в момент создания, Visual Studio не сможет повторно открыть проект, перезапускаемый без поддержки DPI. Однако проект можно открыть, выбрав его в разделе Файл > Последние проекты и решения.

По завершении работы в конструкторе Windows Forms необходимо обязательно перезапустить Visual Studio с поддержкой DPI. При запуске без поддержки DPI шрифты могут выглядеть размытыми, а в других конструкторах, таких как конструктор XAML, могут возникать проблемы. Если закрыть и повторно открыть среду Visual Studio, запущенную без поддержки DPI, она снова будет поддерживать DPI. Можно также выбрать параметр Перезапустить Visual Studio как процесс с поддержкой DPI на информационной панели.

Добавление записи реестра

Вы можете пометить Visual Studio без поддержки DPI, изменив реестр. Откройте редактор реестра и добавьте запись в подраздел HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers:

Запись: в зависимости от версии Visual Studio (2017, 2019 или 2022) используйте одно из следующих значений:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\devenv.exe
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\devenv.exe
C:\Program Files\Microsoft Visual Studio\2022\Community\Common7\IDE\devenv.exe

Если вы используете выпуск Professional или Enterprise, в записи замените Community на Professional или Enterprise. При необходимости замените букву диска.

Тип: REG_SZ
Значение. DPIUNAWARE

Visual Studio останется в режиме без поддержки DPI до удаления записи реестра.

Установка параметра масштаба дисплея равным 100 %

Чтобы в Windows 10 задать параметр масштаба дисплея равным 100 %, в поле поиска на панели задач введите параметры дисплея, а затем выберите Изменить параметры дисплея. В окне Параметры задайте параметру Изменить размер текста, приложений и других элементов значение 100 % .

Масштаб дисплея, равный 100 %, может быть нежелателен, так как пользовательский интерфейс может отображаться слишком мелко.

Отключение уведомлений

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

Чтобы отключить уведомления:

Выберите Сервис > Параметры, чтобы открыть диалоговое окно Параметры.
Выберите Конструктор Windows Forms > Общие и задайте параметру Уведомления о масштабировании DPI значение False.

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

Как сбросить "масштаб" в VS 2010/2012/2013/2015/2017 обратно в нормальное состояние?

CTRL+SCROLL WHEEL позволяет увеличить / уменьшить масштаб с помощью Visual Studio 2010/2012/2013/2015/2017, но я хотел бы вернуться к первоначальному 100%.

для этого в левом нижнем углу окна редактора есть окно выбора-выберите 100%;)

Я не смог найти комбинацию клавиш для него, хотя увеличение и уменьшение масштаба можно сделать с помощью Ctrl +> и Ctrl + .

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

Инструменты / Параметры / Текстовый Редактор / Все Языки / Полосы Прокрутки

другой опция (Visual Studio 2013/2015) - использовать Ctrl с колесиком мыши (до увеличения, вниз, чтобы уменьшить).

в левом нижнем углу редактора кода есть элемент управления масштабированием. Вы можете выбрать 100% оттуда или ввести его вручную.

вы можете попробовать расширение VSCommands из галереи Visual Studio, Он добавляет несколько новых функций вокруг масштабирования в VS2010

на Visual Studio 2015/2017 (легко пропустить, если использовать темную тему):

по умолчанию сочетание клавиш Ctrl+0, Ctrl+0, но может быть изменено, чтобы быть тем, что вам нравится.

перейти к инструментам - > параметры - > Окружающая среда - > клавиатура и найдите представление команды.ZoomReset для изменения сочетания клавиш.

на Visual Studio Ultimate 2013, внизу-слева от экрана:

Если вы используете последнюю версию, вы также можете изменить размер содержимого в visual studio, выбрав

сделать вручную goto

и UserSetting файл будет открыт при изменении редактора.Для увеличения по умолчанию

Вопросы:

Что в WinForms НЕ автоматическое масштабирование должным образом и поэтому следует избегать?

Какие руководящие принципы проектирования должны следовать программистам при написании кода WinForms, чтобы он автоматически масштабировался?

Элементы управления, которые не поддерживают масштабирование должным образом:

ToolStripButton изображение. В конструкторе формы:

Установить ToolStrip.AutoSize = False
Установите ToolStrip.ImageScalingSize в соответствии с CreateGraphics.DpiX и .DpiY
При необходимости установите ToolStrip.AutoSize = True .

Рекомендации по дизайну:

Все контейнеры ContainerControls должны быть установлены на один и тот же AutoScaleMode = Font .
(Шрифт будет обрабатывать как изменения DPI, так и изменения в системном шрифте
настройка размера; DPI будет обрабатывать только изменения DPI, а не изменения в
системный размер шрифта.)

Все элементы управления на конкретном Panel или Container должны либо использовать привязку, либо докинг. Если вы их смешиваете, автомасштабирование, выполняемое этим Panel , будет часто ошибочным в тонких причудливых путях.

Если вы создаете макет должным образом reflowable/auto-size, то почти все работает точно так же, как и автоматически, с настройками по умолчанию, используемыми Visual Studio (а именно, AutoSizeMode = Font в родительской форме и Inherit на все остальное).

Единственная проблема заключается в том, что вы задали свойство Font в форме в дизайнере. Сгенерированный код сортирует задания по алфавиту, что означает, что AutoScaleDimensions будет назначаться до Font . К сожалению, это полностью нарушает логику автоматического масштабирования WinForms.

Исправление просто. Либо не устанавливайте свойство Font в конструкторе вообще (установите его в конструкторе формы), либо вручную измените порядок этих назначений (но тогда вы должны продолжать делать это каждый раз, когда вы редактируете форму в дизайнере). Voila, почти идеальное и полностью автоматическое масштабирование с минимальными хлопотами. Даже размеры формы масштабируются правильно.

Ниже перечислены известные проблемы, с которыми я сталкиваюсь:

Руководство, которое я написал на работе:

Чтобы поддержать его, добавьте манифест приложения в приложение и сообщите, что ваше приложение поддерживает Windows 10:

Затем добавьте app.config и объявите приложение Per Monitor Aware. Это выполняется сейчас в app.config и NOT в манифесте, как раньше!

Этот PerMonitorV2 является новым, поскольку обновление для разработчиков Windows 10:

DPI_AWARENESS_CONTEXT_PER_MONITOR_AWARE_V2

Уведомления об изменении DPI дочернего окна. В контексте Per2 v2 все дерево окон уведомляется о любых изменениях DPI, которые происходят.
Масштабирование неклиентской области. Все окна автоматически будут иметь свою неклиентскую область, нарисованную чувствительным способом DPI. Звонки на EnableNonClientDpiScaling не требуется.
S настройка меню Win32. Все меню NTUSER, созданные в контекстах Per Monitor v2, будут масштабироваться для каждого монитора.
Диалоговое масштабирование. Диалоги Win32, созданные в контекстах Per Monitor v2, автоматически будут реагировать на изменения DPI.
Улучшено масштабирование элементов управления comctl32. Различные элементы управления comctl32 улучшили поведение масштабирования DPI в Per Monitor v2 контексты.
Улучшенное поведение в темах. Ручки UxTheme, открытые в контексте окна Per Monitor v2, будут работать с точки зрения DPI связанные с этим окном.

Теперь вы можете подписаться на 3 новых события, чтобы получать уведомления о изменениях DPI:

Control.DpiChangedAfterParent, который запускается. Происходит, когда параметр DPI для элемента управления изменяется программно после DPI изменить событие для его родительского элемента управления или формы.
Control.DpiChangedBeforeParent, который запускается, когда параметр DPI для элемента управления изменяется программно до изменения DPI событие для его родительского элемента управления или формы.
Form.DpiChanged, который запускается, когда параметр DPI изменяется на устройстве отображения, где отображается форма.

У вас также есть 3 вспомогательных метода обработки/масштабирования DPI:

Control.LogicalToDeviceUnits, который преобразует значение из логического в пиксели устройства.

Control.ScaleBitmapLogicalToDevice, который масштабирует растровое изображение для логического DPI для устройства.

Control.DeviceDpi, который возвращает DPI для текущего устройства.

Если у вас нет доступа к исходному коду, вы можете перейти к свойствам приложения в проводнике Windows, перейти к совместимости и выбрать System (Enhanced)

который активирует масштабирование GDI, чтобы улучшить обработку DPI:

Для приложений, основанных на GDI, Windows теперь может масштабировать DPI для каждого монитора. Это означает, что эти приложения будут, волшебным образом, чтобы распознать DPI на мониторе.

В дополнение к якорям, которые не работают очень хорошо: я бы сделал шаг дальше и сказал, что точное позиционирование (иначе, используя свойство Location) не очень хорошо работает с масштабированием шрифта. Мне пришлось решить эту проблему в двух разных проектах. В обоих случаях нам пришлось преобразовать расположение всех элементов управления WinForms в использование TableLayoutPanel и FlowLayoutPanel. Использование свойства Dock (обычно устанавливается для Fill) внутри TableLayoutPanel работает очень хорошо и отлично масштабируется с помощью системного шрифта DPI.

Недавно я столкнулся с этой проблемой, особенно в сочетании с масштабированием Visual Studio при открытии редактора в системе с высоким разрешением. Мне было лучше сохранить AutoScaleMode = Font , но установить шрифт шрифт по умолчанию, но указать размер в пикселе, а не то есть: Font = MS Sans; 11px . В коде я , затем reset шрифт по умолчанию: Font = SystemFonts.DefaultFont и все в порядке.

Читайте также: