Fermer

octobre 14, 2020

Mise à l'échelle de WinForms à des paramètres PPP larges – Est-ce même possible?


Qu'est-ce que DPI? Comment le DPI élevé est-il géré dans Windows et WinForms? Comment pouvez-vous faire évoluer les applications WinForms aujourd'hui? Explorons le monde du DPI élevé.

En ces jours d’affichage à pixels haute densité, la mise à l’échelle devient un sujet de plus en plus important. Plongeons dans les spécificités du DPI élevé et essayons de comprendre les différents problèmes causés par les affichages DPI élevés et comment les résoudre. Nous allons passer en revue l'émergence des écrans haute résolution et comment Windows gère la haute résolution . Ensuite, nous présenterons le concept de DPI et verrons les spécificités de pour WinForms . Nous verrons comment la mise à l'échelle fonctionne dans WinForms . Enfin, nous terminerons avec quelques astuces pour concevoir des WinForms évolutifs et un exemple .

Telerik UI for WinForms offre un support HDPI intégré. En savoir plus ou téléchargez une version d'évaluation et voyez par vous-même.

Compréhension du DPI

Les points par pouce, plus communément appelés DPI, représentent le nombre de points qui peuvent être placés sur une ligne d'un pouce pendant l'impression. En ce qui concerne les moniteurs, le terme approprié est PPI (pixels par pouce), mais les deux termes sont pour la plupart interchangeables aujourd'hui.

Au début, Microsoft Windows utilisait un affichage par défaut de 96 PPI et Apple / Macintosh de 72 PPI. Alors que le raisonnement derrière cela vient de la norme 72 points par pouce et que Microsoft souhaite avoir 33% d'espace en plus pour une meilleure image et un meilleur dessin de police, vous pouvez imaginer les problèmes qui se sont posés avec les nouveaux moniteurs prenant en charge des pixels plus élevés densité.

La solution est le concept de PPI logique. Le système d’exploitation crée un écran virtuel avec le DPI par défaut (disons 96). Cet écran virtuel est utilisé par le logiciel pour rendre son contenu. Ensuite, le système d'exploitation dessine l'écran virtuel vers l'écran physique.

Aujourd'hui, il existe de nombreux appareils avec différents DPI – il existe de nombreux moniteurs avec 200-300 DPI et des smartphones allant jusqu'à 800 DPI. Cela signifie que si vous dessinez un carré de 4 x 4 pixels, il semblera physiquement plus petit sur un périphérique DPI supérieur que sur un périphérique DPI inférieur.

 Affichage 1: 8x6 pixels "title =" Affichage 1: 8x6 pixels "/> </td>
<td><img decoding= Affichage 1: 8×6 pixels [19659012] Écran 2: 16×12 pixels

Notre carré de 4 x 4 pixels semble bien plus petit sur le deuxième écran, où nous avons quatre fois plus de pixels que le premier écran. Mais si nous devons redimensionner notre carré par un facteur de deux sur le deuxième écran, nous obtiendrons le résultat souhaité.

 Affichage 1: 8x6 pixels "title =" Affichage 1: 8x6 pixels "/> </td>
<td><img decoding= Affichage 1: 8×6 pixels Affichage 2: 16×12 pixels


Mise à l'échelle sous Windows

Alors, comment Windows gère-t-il un DPI élevé? À partir de Windows XP, Microsoft a introduit la bibliothèque GDI +, qui permet la mise à l'échelle des polices et de certains autres éléments de l'interface utilisateur. Malheureusement, cela rendrait principalement le texte plus grand dans un paramètre DPI élevé, ce qui était problématique. Microsoft a récemment ajouté une prise en charge de la mise à l'échelle GDI / GDI + . Cela ne fonctionne pas parfaitement – il met généralement à l'échelle les polices et certains graphiques. Lors de son utilisation, vous devez toujours être prudent et vérifier si le résultat est meilleur ou non.

Windows Vista a introduit la reconnaissance DPI et la virtualisation DPI. Une application peut se déclarer comme compatible DPI et mettre à l'échelle ses propres éléments d'interface utilisateur. Sinon, le système d'exploitation utilisera la virtualisation DPI, qui rendra l'application en utilisant un 96 DPI natif en tant que bitmap, puis redimensionnera le bitmap à l'écran. Cela produirait un rendu correct mais flou de l'application. Il existe également une option globale pour désactiver la virtualisation et utiliser l'ancien rendu de style XP. Au même moment, WPF est apparu avec .NET Framework 3.0. Les applications conçues avec WPF prennent en charge nativement la mise à l'échelle DPI. DirectX et les graphiques vectoriels sont utilisés pour dessiner leurs éléments et la mise à l'échelle sort de la boîte. WPF a une limitation: il ne peut pas mettre à l'échelle les contrôles hébergés.

Windows 7 a rendu DPI par utilisateur et a activé la commutation DPI plus facile avec la déconnexion uniquement. Le système d'exploitation lit également le DPI du moniteur et définit une mise à l'échelle recommandée. Les paramètres standard sont 100% (96 DPI), 125% (120 DPI) et 150% (144 DPI). Windows 8 a supprimé les valeurs numériques et ajouté quelques améliorations mineures. Avec Windows 8.1, la mise à l'échelle DPI par moniteur a été améliorée par la mise à jour Windows 10 Creators (1703). D'autres facteurs d'échelle ont également été ajoutés – 175%, 200%, 225%, etc. Et l'utilisateur peut définir un facteur d'échelle personnalisé jusqu'à 500%.

DPI Awareness

Jusqu'ici tout va bien. Windows prend en charge la mise à l'échelle HDPI (haute résolution). Mais comment l'aborder? Lors de la création d'une application prenant en charge DPI, nous devons d'abord la déclarer comme telle, afin que le système d'exploitation sache comment la gérer. De plus, vous pouvez avoir une reconnaissance DPI par processus ou par thread.

Il existe quatre modes de détection DPI différents dans Windows.

  • Inconnu – l'étirement bitmap est utilisé.
  • Système – Introduit dans Windows Vista. Le système d'exploitation traite tous les écrans avec le même DPI de l'écran principal. L'étirement bitmap est utilisé.
  • Par moniteur – Introduit dans Windows 8.1. Chaque écran a son propre DPI et la fenêtre de l'application est notifiée du changement de DPI.
  • Per-Monitor V2 – Introduit avec Windows 10 Creators Update (1703). En plus du mode précédent, il y a une mise à l'échelle automatique de la zone non-client et de certains contrôles et boîtes de dialogue.

Voici une liste des différentes façons que vous pouvez utiliser pour choisir le mode de reconnaissance DPI pour une application:

  • Dans le fichier manifeste de l'application
  • API native
  • Dans app.config – disponible uniquement pour .NET Framework 4.7 / 4.8 Windows Forms
  • Une méthode statique dans .NET Core 3.0 / .NET5 pour Windows Forms

Manifest File [19659035] Le moyen le plus courant de déclarer une application comme prenant en charge DPI consiste à utiliser le fichier manifeste de l'application. Vous pouvez utiliser deux paramètres: et . Voici un petit tableau qui décrit les différents états que vous pouvez utiliser avec chaque paramètre.

Système d'exploitation minimum pris en charge

États

Mode DPI

Windows Vista

false

Unaware

true

System aware

true / pm

Par moniteur conscient

Windows 10, version 1607

non averti

Système non informé

Système conscient

PerMonitor

Par moniteur

PerMonitorV2

Par moniteur-v2 conscient [19659058] Vous pouvez utiliser les deux paramètres dans le fichier manifeste. Si tel est le cas, Windows 10, version 1607, ignorera et n'utilisera que le plus récent . Les anciennes versions ignoreront . Voici à quoi doit ressembler le fichier manifeste si vous souhaitez configurer la détection DPI pour différentes versions de Windows.

<? xml version = "1.0" encoding = "UTF-8" standalone = "yes" ?>

< assembly xmlns = "urn: schemas-microsoft-com: asm.v1" manifestVersion = "1.0" xmlns: asmv3 = "urne : schemas-microsoft-com: asm.v3 ">

< asmv3: application >

< asmv3: windowsSettings >

</ asmv3: windowsSettings >

</ asmv3: application >

</ assembly >

Native API

Trois appels d'API natifs peuvent désormais définir la prise de conscience:

La dernière API prend en charge PerMonitorV2, c'est donc l'actuel recommande un.

NB! Vous devez définir le mode DPI avant que votre fenêtre (HWND) n'ait été créée.

App.config pour Windows Forms uniquement

Une autre méthode qui a été introduite pour Windows Forms dans .NET Framework 4.7 est dans l'application . fichier config . Microsoft a ajouté un nouvel élément pour ajouter différentes fonctionnalités à une application Windows Forms appelée . Pour l'utiliser, vous devez faire ce qui suit:

  • Déclarez la compatibilité avec Windows 10 dans le fichier manifeste:

< compatibilité xmlns = "urn: schemas-microsoft -com: compatibilité.v1 ">

< application >

< supportedOS Id ] = "{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}" />

</ application >

</ compatibilité >

  • Utilisez le nouvel élément dans la app.config fichier:

< System.Windows.Forms.ApplicationConfigurationSection >

< add key = Valeur "DpiAwareness" = "PerMonitorV2" / >

</ System.Windows.Forms.ApplicationConfigurationSection >

Avec l'élément vous pouvez définir d'autres fonctionnalités DPI ainsi que. Pour plus d'informations, vous pouvez consulter cet article .

NB! L'utilisation de / dans le fichier manifeste remplace les paramètres définis dans le fichier app.config .

Une méthode statique dans .NET Core 3.0 / .NET5 Preview

Avec .NET Core 3.0 Microsoft a introduit une nouvelle façon de définir un mode DPI élevé pour Windows Forms. Une méthode statique appelée Application.SetHighDpiMode (HighDpiMode) HighDpiMode est énuméré avec les valeurs suivantes:

  • DpiUnaware
  • SystemAware
  • PerMonitor
  • PerMonitorV2
  • PerMonitorV2
  • PerMonitorV2 ] DpiUnawareGdiScaled

L'appel doit être effectué au point d'entrée de l'application. Si vous avez utilisé un fichier manifeste pour définir le mode de détection DPI, cet appel de méthode échouera.

Mise à l'échelle DPI en mode mixte

Mise à jour anniversaire de Windows 10, build 1607, prise en charge du mode mixte supplémentaire pour la mise à l'échelle DPI. L'idée principale est de définir la mise à l'échelle DPI sur les fenêtres de niveau supérieur qui est différente de la mise à l'échelle DPI du processus. Cela se fait en utilisant l'API SetThreadDpiAwarenessContext. Vous pouvez appeler l'API juste avant de créer une nouvelle fenêtre. Une fois la fenêtre créée, vous pouvez appeler à nouveau l'API pour revenir au mode d'origine. Pour plus d'informations sur le sujet, je vous suggère de lire cet article .

DPI et WinForms

Ainsi, en ce qui concerne Windows Forms, vous pouvez utiliser diverses techniques pour définir la sensibilité DPI, selon sur le cadre que vous utilisez. Avec le développement de .NET Core et du prochain .NET5, Microsoft s'oriente vers l'utilisation d'une méthode statique dans votre application pour définir la prise en charge HDPI. Mais si vous utilisez un framework plus ancien, vous pouvez utiliser en toute sécurité le fichier manifeste ou le fichier app.config. Les appels natifs ne sont généralement pas recommandés. Gardez simplement à l'esprit que la déclaration du fichier manifeste remplace les autres déclarations.

Au début, Windows Forms ne prenait pas en charge la mise à l'échelle moderne. À partir de .NET Framework 4.5.1, Microsoft a apporté des améliorations aux scénarios HDPI dans Windows Forms. Dans .NET Framework 4.5.2, les contrôles suivants peuvent être redimensionnés à l'aide du paramètre DPI du système:

  • PropertyGrid
  • TreeView
  • ComboBox
  • ToolStripComboBox
  • ToolStripMenuItem
  • Cursor
  • DataGridView
  • DataGridViewComboBoxColumn

La version 4.6 a ajouté la prise en charge des contrôles suivants:

  • DomainUpDown
  • NumericUpDown
  • DataGridViewComboBoxColumn
  • DataGridViewColumn
  • ToolStripSplitButton
  • ToolStripSplitButton

comportement peut être activé en 194515] Fichier .config :

< appSettings >

< add key = Valeur "EnableWindowsFormsHighDpiAutoResizing" = "true" />

</ appSettings [19659065]>

.NET Framework 4.7 a introduit plusieurs améliorations de la qualité des DPI calage dans Windows Forms.

Mise à l'échelle DPI dans WinForms

La plate-forme WinForms possède son propre mécanisme de mise à l'échelle, qui calcule la différence de mise à l'échelle entre le système sur lequel le formulaire a été conçu et le système sur lequel il s'exécute. Ensuite, il modifie la taille et l'emplacement de tous les contrôles en fonction du facteur calculé. Notez que cette mise à l'échelle ne se déclenchera que si votre application déclare être compatible DPI, sinon elle sera rendue dans le sandbox 96 DPI et la mise à l'échelle bitmap du système d'exploitation sera utilisée.

Vous avez probablement remarqué les deux propriétés suivantes dans votre concepteur a généré des fichiers:

this .AutoScaleDimensions = new System.Drawing.SizeF (6F, 13F);

this [19659065] .AutoScaleMode = System.Windows.Forms.AutoScaleMode.Font;

Dans la propriété AutoScaleDimensions le concepteur Visual Studio sérialisera les dimensions de l'unité utilisée pour la comparaison (police ou DPI). Ce sont les dimensions de l'unité sur le système sur lequel le formulaire est conçu. Lorsque vous exécutez le formulaire sur un système avec des paramètres différents, ses dimensions sont obtenues et comparées aux dimensions sérialisées. Le facteur d'échelle est calculé sur cette base, puis il est appliqué.

La propriété AutoScaleMode indique la méthode de calcul du facteur d'échelle. En fonction de cela, le mécanisme de mise à l'échelle calculera le facteur d'échelle en fonction des dimensions de la police système ou du DPI du système. Si vous le définissez sur Aucun, aucune mise à l'échelle ne sera effectuée.

NB! Tous les conteneurs doivent utiliser le même AutoScaleMode . Le mélange de différents modes d'échelle n'est pas pris en charge et peut conduire à des résultats inattendus.

Lorsque le facteur d'échelle est calculé, le cadre appelle la méthode Scale du formulaire qui recalcule fondamentalement la taille et l'emplacement de tous les enfants contrôles là-dessus. Ensuite, leur méthode Scale est également appelée afin qu'ils puissent correctement évoluer.

Malheureusement, ce mécanisme ne fonctionne pas aussi parfaitement que celui de WPF où vous n'avez même pas à vous soucier de la mise à l'échelle . Mais avec les améliorations qui ont commencé avec .NET Framework 4.5.1, la mise à l'échelle a été améliorée.

Pour plus d'informations, consultez cet article .

Prise en charge HDPI avec l'interface utilisateur Telerik pour WinForms

As de 2017, Telerik UI pour WinForms offre une prise en charge HDPI intégrée. La bonne nouvelle est que vous n’avez pas besoin de la dernière infrastructure: la fonctionnalité est prise en charge avec .NET Framework 2.0 et versions ultérieures. Consultez l'article de blog et la documentation pour plus d'informations.

La bibliothèque de traitement de documents Telerik (RadSpreadProcessing, RadWordProecessing ou RadPdfProcessing) fait référence aux assemblys qui sont utilisés dans WPF. Toutes les applications WPF prennent en charge DPI par défaut et cela est déclaré dans les manifestes des assemblys WPF. Par conséquent, si vous utilisez la bibliothèque de traitement de documents dans les applications WinForms qui ne sont pas compatibles DPI, elles peuvent soudainement devenir conscientes DPI au moment de l'exécution lorsque vous instanciez un type à partir des assemblys DPL (lorsque les assemblys DPL sont chargés par le CLR, cela chargera également les assemblys WPF dont ils dépendent, ce qui rendra l'application compatible DPI). Si vous avez l'intention d'utiliser votre application sur des machines où la mise à l'échelle DPI est supérieure à 100%, vous devez explicitement définir l'application pour qu'elle ne soit pas compatible DPI:

private void workbookTestButton_Click ( object ] expéditeur, EventArgs e)

{

SetProcessDpiAwareness (_Process_DPIna_Awareness.Process) [194579]

Workbook wb = new Workbook ();

}

[DllImport( "shcore.dll" )]

static extern int SetProcessDpiAwareness (_Process_DPI_Awareness value);

9238]

enum _Process_DPI_Awareness

{

Process_DPI_Unaware = 0,

Process_System_DPI_Aware = 1, [1965983006] Process_Per_Monitor_DPI_Aware = 2

}

Conseils généraux pour la conception de WinForms évolutifs

Si vous concevez une application évolutive, il y en a peu des instructions simples qui vous aideront beaucoup:

  • Concevez vos formulaires sous 96 PPP (100%) - comme mentionné ci-dessus, Visual Studio sérialisera la taille de mise à l'échelle du formulaire au moment de la conception et il y a souvent des problèmes lorsque le formulaire a été conçu sous un DPI supérieur.
  • Testez toujours différents scénarios - exécutez l'application avec différents paramètres DPI; changer le DPI pendant son exécution; déplacer l'application vers un autre moniteur avec un DPI différent.
  • Concevez l'interface de vos formulaires de manière à ce qu'elle puisse être «redistribuée» - utilisez les contrôles ancrés, ancrés et auto-dimensionnés lorsque cela est possible.
  • Tous les conteneurs doivent utiliser le même AutoScaleMode. [19659026] Utilisez la taille de police par défaut (8,25 px) sur tous les conteneurs. Si vous avez besoin d'une taille de police personnalisée pour un contrôle spécifique, définissez-la plutôt sur ce contrôle sur la classe conteneur.
  • Faites particulièrement attention à ce que la taille de la police soit correctement mise à l'échelle. Sinon, vous devrez redimensionner manuellement la taille de la police pour des contrôles spécifiques.
  • Si vous avez une logique de mise en page personnalisée, gardez toujours à l'esprit que les tailles et les emplacements des contrôles seront différents si le formulaire est mis à l'échelle. Gardez également à l'esprit que vous devez mettre à l'échelle manuellement toutes les constantes que vous utilisez si elles indiquent des pixels.

Exemple avec l'interface utilisateur Telerik pour WinForms

Lorsque vous utilisez l'interface utilisateur Telerik pour WinForms, vous disposez d'une mise à l'échelle automatique prête à l'emploi, même pour .NET Framework 2.0. Il vous suffira de marquer votre application comme compatible DPI. Vous pouvez consulter l'exemple ici: C # / VB . Les exemples fonctionnent pour tout .NET Framework après la version 2.0. Vous devrez installer une version d'évaluation de l'interface utilisateur Telerik pour WinForms, que vous pouvez faire via le lien ci-dessous.

Essayez l'interface utilisateur Telerik pour WinForms

Conclusion

WinForms a parcouru un long chemin depuis son émergence. À ses débuts, la mise à l'échelle DPI n'était pas nécessaire. De nos jours, avec le développement de meilleurs écrans, la mise à l'échelle devient de plus en plus obligatoire. Et comme il y a beaucoup d'applications écrites dans la journée à l'aide de WinForms, il est nécessaire que la plate-forme se développe. Aujourd'hui, WinForms a un bon support HDPI et avec l'interface utilisateur Telerik, vous pouvez avoir une application HDPI transparente prête à l'emploi.

Note de l'éditeur: Cet article a été initialement publié en 2014 par Ivan Todorov et a depuis été révisé et mis à jour pour plus de précision et l'exhaustivité.





Source link