J'ai une application .NET 2.0 qui fonctionne sur Compact Cadre. Il a un tas de formes différentes qui ont été toutes conçues à l'origine pour exécuter sur un périphérique spécifique avec une résolution d'écran spécifique. Je cherche maintenant à faire fonctionner cette application sur certains autres périphériques ayant des résolutions d'écran très différentes (certaines ont des rapports d'aspect totalement opposés où l'écran est maintenant plus grand qu'il n'est large). Ma question est de savoir comment puis-je changer mes formulaires pour bien paraître sur ces autres écrans?
Ceci est un peu différent de la conception des formulaires sur le cadre complet, car je dois concevoir ces formulaires pour prendre tout l'écran car les écrans sont si petits. J'ai pensé à créer des formes séparées pour chaque type d'orientation de l'écran (par exemple myform_wide.cs, myForme_Tall.cs, etc.). J'aimerais pouvoir réutiliser le code généré non concepteur contenant beaucoup de logique commerciale liée aux contrôles de l'interface utilisateur. Peut-être que je pourrais d'en quelque sorte utiliser des classes partielles pour que cela se produise (par exemple, myform.cs est compilé dans myform_wide.designer.cs, etc.). J'aimerais vraiment éviter les versions spécifiquement compilées pour chaque orientation de l'écran. Une autre approche que j'ai pensée va essayer de réorganiser certaines commandes à l'exécution en fonction de la taille de l'écran déterminée.
Qu'est-ce que vous pensez?
5 Réponses :
Nous utilisons le Contrôle conscient de l'orientation Cadre de Clarius. Il résout le problème de facteur de forme non seulement, mais également sur des périphériques qui le supportent, le changement d'orientation (rotation de l'écran).
L'aspect le plus distinctif du développement mobile en ce qui concerne le développement de bureau traditionnel est la nécessité de soutenir une gamme de facteurs de formulaire de périphérique toujours croissant.
Pour les développeurs de téléphonie mobile expert Ce n'est pas une nouvelle qui concevant des applications mobiles prenant en charge plusieurs facteurs de formulaire, les résolutions et les orientations de l'écran sont une entreprise non triviale, fastidieuse et stimulante. Il est également généralement évident que les caractéristiques d'amarrage et d'ancrage intégrées dans le cadre compact de .NET V2.0 est loin d'être suffisante.
Le contrôle conscient de l'orientation permet de concevoir et de coder un seul contrôle ou un formulaire avec plusieurs dispositions ou skins qui sont automatiquement appliqués au temps d'exécution (et de conception) selon le facteur de forme disponible, la résolution et l'orientation. Ses formulaires de studio visuels exceptionnels et l'intégration des concepteurs de contrôle de l'utilisateur et son comportement d'interface utilisateur adaptatif à code zéro rendent le contrôle conscient de l'orientation un compagnon indispensable pour tout magasin mobile ciblant plusieurs périphériques, rapportant la productivité nécessaire pour vous concentrer sur votre entreprise.
C'est un cadre de recherche assez intéressant. Je pense que si je commençais un nouveau projet, je rechercherais cela, mais pour mon projet existant, j'ai trop de code existant pour basculer à ce stade.
puisque les concepteurs C # sont très «axés sur pixels», il n'est pas facile de convertir vos formulaires.
Je ne sais pas combien d'effort vous voulez mettre dans cette situation, mais si vous avez beaucoup de temps et que vous voulez une solution vraiment flexible, je vous suggère de pouvoir utiliser une sorte de gestionnaire de mise en page qui prend en charge les dispositions de débit, les dispositions de la bordure, etc. .
Bien sûr, les concepteurs C # d'origine ne seront pas beaucoup d'aide à concevoir ces formulaires flexibles de la mise en page.
mais en utilisant un gestionnaire de mise en page peut ralentir l'affichage initial de votre formulaire. Si vous souhaitez vraiment un affichage de formulaire à grande vitesse, vous devrez calculer toutes les positions de toutes les commandes de votre formulaire avant d'afficher le formulaire. Réorganisez les commandes et affichez votre formulaire - Ceci est cependant beaucoup de codage et pas très flexible en ce qui concerne les changements d'interface graphique.
Vous devriez probablement définir vos formulaires principaux «AutoScalemode» de «DPI».
Ensuite, il s'agit d'utiliser des ancrages et d'accoster sur vos commandes particulières sur les formulaires. Si vous le faites de cette façon, le cadre compact gardera les choses où vous pensiez être.
En outre, peut modifier la propriété "facteur de formulaire" du formulaire pour voir comment votre formulaire examinerait les appareils mobiles de différentes tailles et formes.
Cet article devrait vous donner quelques indications sur la manière d'utiliser des ancrages et de l'amarrage: MSDN.MicRosoft .com / fr-US / bibliothèque / ms229649.aspx
Mes formulaires utilisent déjà la mise à l'échelle DPI et je modifie les ancrages et l'amarrage au besoin. Cependant, j'ai toujours quelques problèmes: pour des écrans de résolution supérieure, les commandes ne sont pas correctement aménagées (par exemple, des zones de texte s'étendent toute la largeur de l'écran lorsqu'elles n'ont vraiment pas besoin de; sur les écrans inférieurs à ceux dont ils ont besoin à). De plus, pour les appareils qui ont des rapports d'aspect différents, cela ne fonctionne pas du tout, car je sais comment des contrôles très vastes, mais il y a maintenant une barre de défilement verticale nécessaire pour faire défiler vers le bas.
Je pense que j'ai compris ce que je veux faire. Pour une raison quelconque, même sur mes périphériques élevés, le DPI apparaît toujours comme 96 selon l'API WinForms afin que la mise à l'échelle automatique ne fait rien. Au lieu de cela, si j'appelle manuellement échelle Sur mes contrôles, je les amène à évoluer exactement comment je veux. Maintenant, cela ne résout pas complètement mon problème dans des scénarios où je ne veux pas faire de la mise à l'échelle, mais je veux réorganiser mes commandes si l'écran est dans le rapport d'image opposé à celui que j'ai initialement conçu pour. Pour ce cas, je pense que je vais regarder en utilisant différents panneaux de mise en page (par exemple, flowlayOntPanel et TableLayOntPanel ) pour organiser correctement les commandes de manière appropriée.
Espérons que cela aidera tout futur Googler ...
Juste pour ajouter des informations supplémentaires ici, le FlowlayOntPanel et TableLayOntPanel que j'ai mentionné précédemment ne sont pas disponibles sur le cadre compact (j'aurais dû constater que l'une à venir). Tout ce que je veux vraiment, c'est un moyen d'obtenir des concepteurs de VS pour générer essentiellement plusieurs méthodes d'initialisement à des résolutions différentes. Ensuite, dans le constructeur de mon formulaire, je peux simplement choisir lequel à appeler. Je ne trouve pas un moyen de faire cela, malheureusement. Peut-être que je dois examiner la création d'un addin vs qui fait cela ...
J'ai trouvé l'article Microsoft sur ce sujet suivant: MSDN.MicRosoft.com/fr- US / Bibliothèque / MS838174.aspx C'est destiné à VS .NET 2003, mais cela ne semble pas qu'ils ne ressemblent pas vraiment à cette question dans une version ultérieure. Ils disent essentiellement que vous devriez créer des méthodes de portrait et de paysage et de copier le code généré par VS concepteur pour chaque mise en page dans la méthode appropriée. Je suis en train de suivre cette approche, sauf que je copie les méthodes d'initialisation complètes car il est trop difficile de choisir le code de taille / de position.
La propriété 'Taille automatique' sur les étiquettes est en train de gâcher lors de la commutation entre les facteurs de formulaire - BTW - donc je le reste à false.