none
Ressources et format d'écran RRS feed

  • Question

  • Bonjour,

    Mon appli WinForm sous .NET 2.0 contient des ressources qui décrivent ses différents formulaires en plusieurs langues (Français et Anglais).

    L'application se charge et démarre toujours correctement. Un changement dynamique de langue se traduit par un rechargement des ressources comme suit :

    Dim r as ComponentResourceManager = New ComponentResourceManager (GetType(Form1))
    
    r.ApplyResources(Me, "$this")
    r.ApplyResources(Me.Button1, "Button1")
    

    Ce rechargement dynamique des ressources fonctionne parfaitement sur différents types d'ordinateurs sauf dans certains cas qui sembles liés au format d'écran .

    Dans ces cas les ressources, comme le Button1 dans l'exemple ci-dessus, n'ont pas le "bon format" ou ne sont pas placées correctement sur le formulaire.

    Tout se passe comme s'il manquait un reformatage ou une mise à l'échelle des ressources rechargées.

    Comment résoudre ce problème ?

    Merci de votre réponse.

     

     


    Alain
    jeudi 21 octobre 2010 19:49

Toutes les réponses

  • Bonjour,

    Pourriez-vous regarder ce lien ?

    http://msdn.microsoft.com/fr-fr/library/w7x1y988.aspx

    Vous trouverez la réponse à vôtre problème dans le point 7 de Meilleures pratiques de localisation

    "Prévoyez beaucoup de place pour la longueur des chaînes à développer dans l'interface utilisateur.Dans certaines langues, les phrases sont de 50 à 75 % plus longues que dans d'autres."

    Excellent conseil mais difficile à appliquer car il faudrait connaitre la plus grande longueur d'une chaine pour chaque langue de façon à adapter la taille de chaque controle ( j'utilise parfois une autre technique qui est moche mais efficace , je ne traduis pas les textes mais je mets la traduction dans un ToolTip  qui affiche la traduction quand on passe le curseur sur un contrôle , c'est bof , je sais )

    En tout cas, rien n'est prévu pour un reformatage ou une mise à échelle automatique pour les ressources dans System.Globalization. C'est à l'équipe de développement de prévoir ces 2 opérations lors de la phase de conception de l'application ( une petite suggestion : utiliser des TextBox multiligne , jouer avec les propriétés WordWrap et MultiLine ). Souvent j'utilise des TextBox en readonly , avec BorderStyle = None et TextAlign = Center ( le seul problème est de connaître la longueur maximale de la chaîne à afficher )

    Pour les problèmes de format d'écran, pourquoi ne pas concevoir des formes pour des écrans 1024 x 732 pixels ( ce qui devrait couvrir au moins 90% des écrans )

    Je crois qu'il est possible de couvrir entièrement une forme avec un control Panel muni de ScrollBars ( Both ). Avec cette solution , il est possible de déborder de l'écran , il suffit de jouer avec les ScrollBars pour visualiser la partie "intéressante" de l'écran ( mais cette solution risque vite d'énerver l'utilisateur lambda qui va devoir jouer avec les barres de défilement pendant 7 ou 8 heures ).

    Autre solution : l'emploi de TabPage et TabControl

    http://msdn.microsoft.com/fr-fr/library/system.windows.forms.tabcontrol.aspx

    http://msdn.microsoft.com/fr-fr/library/system.windows.forms.tabpage.aspx

    Problème classique , et je ne vois pas comment Microsoft pourrez le résoudre à la place de l'équipe de développement, mais problème très interessant car bien peu de chefs ou directeurs de projets osent étudier ou même simplement évoquer par crainte de se faire ridiculiser ( pour moi, c'est un sujet important et ceux qui osent sont les seules personnes intelligentes...). Les indications que j'ai données me sont personnelles mais je suis ouvert à toute critique ou apport ( à condition d'objectivité : j'ai horreur des personnes qui démolissent des idées parce qu'elles ne sont pas d'eux et qui n'ont jamais conçu un écran ou écrit une ligne de code )

    Bonne journée

     

     


    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.
    dimanche 24 octobre 2010 14:13
  • Bonjour Papy Normand et merci de votre réponse très développée qui montre votre attachement à cette question.

    Mon appli est localisée et fonctionne bien dans la plupart des cas (je suis penché sur cette question depuis déjà longtemps, en suivant, bien entendu, les bons conseils pour la globalisation et la localisation). Mais voilà, le matériel évolue et, en particulier, le format des écrans change. 

    Elle fonctionne bien sur la plupart des écrans mais je constate que la mise en page des contrôles sur les formulaire n'est pas correcte sur des écrans dont le rapport Q=L/l > 1,66 et diffère de celui du poste de développement. Par exemple sur un écran 1920 x 1080 (Q=1,77) qui est celui de mon dernier Samsung ! J'ai constaté également ce phénomène sur certains ordinateurs récents.

    Le fonctionnement est correcte si on développe sur ce type d'écran mais alors il ne l'est plus lorsque l'appli s'exécute sur un autre format d'écran.

    Je reprends le déroulement du phénomène observé sur ce type d'écran :

    1. On lance l'appli. Elle s’exécute dans la dernière langue sélectionnée. Sa mise en page du formulaire est correcte.
    2. On change de langue (on choisit une nouvelle langue, sans arrêter l'appli). Elle commute dans la nouvelle langue mais la mise en page du formulaire est altérée.
    3. On ferme l'appli.
    4. On la relance.Elle s'ouvre dans la nouvelle langue et sa mise en page est correcte !!

    Curieux quand même, et je ne comprends pas la raison de ce comportement. Tout se passe comme si le rechargement dynamique des ressources par le ComponentResourceManager ne tenait pas compte de la métrique de l'écran. Alors que ce sont ces mêmes ressources qui sont utilisées au lancement de l'appli...

     

    Avez-vous une idée ? Avez-vous observé ce phénomène ?

    Merci

     


    Alain
    • Modifié AchLog dimanche 24 octobre 2010 15:23 ajout d'une précision
    dimanche 24 octobre 2010 15:18
  • Rebonjour,

    Une petite remarque : si je réponds sur les Forums, c'est simplement parce que il y a 4 ans, j'ai été énormément aidé avec beaucoup de gentillesse lorsque je me suis lancé à fond dans VS 2005 et SQL Server 2005. Maintenant, je ne fais que rendre ce que d'autres m'ont apporté. Mais il est vrai que la politesse n'est plus de mise de nos jours alors votre merci n'en prend que plus de valeur.

    Pourriez-vous expliquer comment vous faîtes pour changer de langue ?

    Ma pratique habituelle est de faire le changement de langue dans une méthode personnelle que j'utilise dans le Main de l'application

    En gros

    {
       static class Program
       {
         /// <summary>
         /// Point d'entrée principal de l'application.
         /// </summary>
         [STAThread]
         static void Main()
         {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);
            if ( CommonCls.AppInit("en-US") )
            {
              Application.Run(new MainForm());
            }
            else
            {
              MessageBox.Show(CommonCls.ErrMsg,CommonCls.ShortMsg);
            }
         }
       }
    
    

     Ma méthode AppInit crée le fichier log de l'application et charge un certail nombre de variables static ( car communes à toute l'application ) :

         /// <summary>
         /// Method to call when the application is starting
         /// </summary>
         /// <param name="p_language">String for the language like en-US or fr-FR, not en or fr</param>
         /// <returns>false if an exception occured else true</returns>
         public static Boolean AppInit(String p_language)
         {
            object[] p_attributes;
            ManagementObjectSearcher p_mos;
            String p_query = "";
            String p_s = "";
            String p_str = "";
    
            ErrMsg = "";
            ErrPlace = "AppInit";
            ShortMsg = "";
            try
            {
              CultureInfo p_ci = new CultureInfo(p_language);
              Thread.CurrentThread.CurrentCulture  = p_ci;
              Thread.CurrentThread.CurrentUICulture = p_ci;
    
    

    Je me souviens avoir lu quelque part que le changement de langue doit se faire avant le 1er appel à Application.Run pour éviter de nombreux problèmes mais impossible de retrouver la source

    Je vais essayer de retrouver cette source demain.

    Si vous regardez ce lien :

    http://msdn.microsoft.com/en-us/library/hx8ykztb(v=VS.90).aspx

    vous verrez

                System.ComponentModel.ComponentResourceManager resources = new System.ComponentModel.ComponentResourceManager(typeof(Form1));

    la définition du ComponentResourceManager se fait dans une méthode appelée dans le constructeur de la forme . Est-ce peut-être l'explication de vôtre problème ?

    Je suppose qu'il faudrait faire le changement de langage ( ou de culture ) dans le 1er écran de l'application pour être sur que la localisation des Strings puisse se faire dans le constructeur de chaque forme .

    C'est un sujet que j'ai en fait très peu utilisé ( j'écrit beaucoup de programmes destinés à des américains mais seuls 2 sont vraiment prévus pour des utilisateurs français et américains , quand j'ai rencontré ce problème, j'ai simplement ajusté la taille des contrôles pour ne plus avoir d'ennuis ).

    Je vais continuer de chercher une explication s'appuyant sur de vrais faits, mais je n'ai aucune idée du temps nécessaire

    Bonne journée ( ou plutot bonne nuit )


    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.
    dimanche 24 octobre 2010 21:36
  • Bonjour Papy Normand,

    Merci de votre réponse.

    Concernant la méthode que j'utilise, je crois l'avoir expliquée dans mes deux messages, mais ce n'est probablement pas suffisant.

    J'ai réalisé une toute petite appli de test qui met ce problème en évidence (il faut avoir les écrans "qui vont bien" -ou plutôt mal- pour voir le  problème apparaître). Je peux vous l'envoyer si vous me communiquez votre mail.

    Par ailleurs j'ai un peu avancé sur le problème. Il est apparemment lié à la propriété "AutoScallMode" du formulaire, associée à la Font utilisée.

    Lorsque AutoScallMode=None la mise en page des contrôles sur le Form est bonne. Dans les autres cas, les ennuis apparaissent.

    La Font choisie a une représentation qui change également peu ou prou avec la résolution d'écran d'où également des problèmes de présentation.

    Voilà où j'en suis.


    Alain
    lundi 25 octobre 2010 10:17