Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

Cyril Sansus

WPF, Interfaces Utilisateurs et .NET
techdays 2012 – Fast and Furious XAML Apps!

Une session indispensable pour tous les développeurs d’application XAML (WP7, SL, WPF et WinRT) qui en ont marre d’entendre leur client dire “c’est mou” et qui aimeraient développer des applications fluides, rapides et réactives !

“Pour les utilisateurs la réactivité d'une application est un critère très important et une des clés de la réussite d'un projet. Dans cette session, vous découvrirez les bonnes pratiques pour réaliser des applications fluides et performantes en Silverlight, Windows Phone et WPF.”

Support Windows Phone 7 Nokia Roadshow

Comme promis à ceux qui ont participé à cette journée de training intense, je met à votre disposition les slides et les démo que j’ai utilisé lors du WP7 Nokia Road Show à Toulouse et Bordeaux.

Télécharger les slides

Merci encore à ceux qui ont participé à cette journée, et bravo aux plus chanceux qui sont repartis avec un Lumia.

Un contrôle Bing Maps pour WPF !!!

Les équipes MS viennent de sortir un contrôle Bing Maps en WPF, 100% WPF !!

Terminées les galères du WebBrowser qui embarque une application Silverlight, les problèmes de superposition, les bidouille d’interop et COM pour faire dialoguer tout ce beau monde, les micro-freeze intempestifs !!

Cette première version Béta fonctionne très bien et il m’a fallut 5 minutes pour migrer de mon ancienne solution vers cette solution 100% WPF. Le résultat est bleffant ! On retrouvera toutes les fonctionnalités de base :

  • Visualisation de la map dans les différentes vues (plan, aérienne, …)
  • Ajouter des pin et des shapes
  • Prise en charge multitouch est assez bien (quelques petits sautillement si on va un peu trop vite).

A télécharger à l’adresse suivante:

http://www.microsoft.com/download/en/details.aspx?id=27165

Vivement la version finale !

[Tips] Popup avec le Surface SDK 2.0

Grace au Surface SDK 2.0, on peut très simplement créer des applications touch sur n’importe quel PC tactile. Mon problème est que ce SDK ne propose pas de contrôle Popup et que l’utilisation de la Popup native WP4 pose des problèmes :

  • Pas de gestion des évènements Touch
  • Lorsqu’on touche l’écran on voit apparaitre le feedback par défaut de la tablette

Pour contourner ces deux problèmes vous pouvez utiliser cette classe (c’est un peu cracra mais ca marche) :

public class SurfacePopup : Popup
{
    protected override void OnOpened(EventArgs e)
    {
        HwndSource hwndSource = PresentationSource.FromVisual((Visual)VisualTreeHelper.GetParent(Child)) as HwndSource;
            
        // Enable surface input and touch events
        hwndSource.EnableSurfaceInput();

        // Disable visual tablet feedback
        NativeMethods.EnableTabletGestures(hwndSource.Handle, false);
        base.OnOpened(e);
    }

    public class NativeMethods
    {
        public static bool EnableTabletGestures(IntPtr hWnd, bool enable)
        {
            string atom = "MicrosoftTabletPenServiceProperty";
            long num = (long)NativeMethods.GlobalAddAtom(atom);
            if (num == 0L)
            {
                return false;
            }
            if (enable)
            {
                return NativeMethods.RemoveProp(hWnd, atom).ToInt64() == 1L;
            }
            int value = 16842777;
            return NativeMethods.SetProp(hWnd, atom, new IntPtr(value)) == 1;
        }

        // Microsoft.Surface.Presentation.Common.NativeMethods
        [DllImport("kernel32.dll", CharSet = CharSet.Unicode)]
        public static extern short GlobalAddAtom(string atom);

        // Microsoft.Surface.Presentation.Common.NativeMethods
        [DllImport("user32.dll", CharSet = CharSet.Unicode)]
        public static extern IntPtr RemoveProp(IntPtr hWnd, string atom);

        // Microsoft.Surface.Presentation.Common.NativeMethods
        [DllImport("user32.dll", CharSet = CharSet.Unicode)]
        public static extern int SetProp(IntPtr hWnd, string atom, IntPtr handle);
    }
}
MIX11 : Prochaine version de Windows Phone 7

Impression après le second keynote : Wouah ! La présentation de la prochaine version de Windows Phone 7 était vraiment impressionnante, la liste des fonctionnalités  qui seront disponibles est énorme (1500 !). Seul ombre au tableau : il va falloir attendre un peu, les tools sont prévus pour mai et la sortie pour cet automne.

Mango (nom de code de la prochaine version) sera multi-tâche. Elle proposera pas mal de fonctionnalités autour du multi-tasking :

  • L’amélioration du temps de reprise des applications
  • Background Agent : les applications pourront continuer de fonctionner en tâche de fond. Exemple avec une application permettant d’écouter une webradio.
  • Notifications : la plateforme permettra de programmer des alarmes et des reminders
  • Background Transfer Service : la plateforme proposera une queue dans laquelle on pourra aller mettre nos différents transferts.

Gros boulot du coté des performances (et il y en avait besoin) :

  • Le scrolling sera smooth (WOUUUUUH !)
  • La gestion des event de Touch a été modifiée afin qu’ils n’arrivent pas avec 100ms de lag.
  • Le chargement du XMAL a été amélioré
  • Vos applications consommeront moins de mémoire.
  • Il sera possible de profiler les applications directement via Visual Studio 2010.
  • Le décodage des images sera également plus efficace et ne bloquera ni l’interface, ni les events de Touch.

Autre truc relativement énorme : la prochaine plateforme proposera SQL CE et Linq to SQL.

Le Framework a été étendue pour offrir plus de services :

  • Au niveau des Tiles :
    • Possibilité d’avoir plusieurs Tiles pour la même application
    • Les Tiles pourront servir de raccourci dans vos applications
    • Quelques changements au niveau des push Notification pour avoir plus de contrôle
  • Phone Extra :
    • Cette fonctionnalité offre la possibilité de positionner vos application directement dans le hub Music, Photo. Exemple on trouvera l’application YouTube dans les Extra du hub Vidéo. Tout ceci sera configurable au niveau du fichier manifest.
  • De nouveaux Launcher :
    • Bing Map
    • Email chooser
    • Phone number chooser
    • Adress chooser
  • Accès aux Contacts
  • Accès au Calendar

D’autres choses en vrac :

  • API pour contrôler le clipboard
  • RichTextBox
  • Amélioration de la navigation
  • Il sera possible d’utiliser du Silverlight dans les applications XNA.
  • Accès à la caméra
  • Amélioration de l’API Sensor
  • Possibilité d’utiliser les sockets (pour des applications comme Faces par exemple
  • Marketplace services
  • Prise en charge des cultures asiatiques
  • 36 pays seront couvert alors que la première version est limitée à 16.

Au niveau de l’outillage :

  • Un debugger pour les applications en background
  • Isolated Storage Explorer
  • Le Profiler de performances
  • L’émulateur permettra d’émuler le Sensor et la Localisation (terrible d’ailleurs).

En résumé Microsoft a écouté la communauté et nous propose une plateforme complète. Il ne reste plus qu’à attendre le mois prochain pour avoir les Tools.

MIX11 : NUI et Surface 2

Il me tardait de pouvoir voir cette nouvelle version de la table surface : c’est chose faite et je ne suis pas mécontent. Durant la session, on nous a présenté les nouveautés de cette Surface 2.

On a donc pu voir une version Alpha de la Surface 2 dont le nom complet est : Samsung SURF40 For Microsoft Surface. Elle a l’avantage d’être plus proche d’un écran plat que d’une grosse table de salon de 80kg. On peut ainsi l’installer en mode vertical ou en mode horizontal. Petite précision : on n’utilise pas une application vertical et horizontale de la même façon !

Le rendu et la finesse de l’écran n’ont rien à voir avec la version 1. On a l’impression de passer du VHS en HD. Un très bon point pour cette nouvelle mouture. La réactivité de l’écran tactile a également été améliorée.

Quelque détails coté hardware :

  • AMD Athlon II X 2.9 Dual Core
  • AMD Radeon HD 6570M 1Gb GDDR5, DirectX 11

Cette nouvelle version est basée sur Windows 7 et Windows Touch (bye bye le vieux Vista Business).

Tout à changer dans cette Surface, même l’interface utilisateur. En effet, le look est clairement orientée Metro et ressemble très fortement à Zune (“content is king”) ! Tous les contrôles ont été “templatés” dans ce sens. La liste des applications a également beaucoup changé et on peut désormais la faire tourner !

D’un point de vue API, je n’ai pas noté de changement. Par contre l’outillage s’est drôlement amélioré. On aura un nouvel outil le “input simulator” qui permet d’émuler du multi-touch, différents devices, créer des gestion multi-touch en toute simplicité. Microsoft proposera également un outil de portage des applications de la version 1 vers la version 2.

Il ne reste plus qu’à attendre le SDK qui devrait arriver cet été.

PS : j’ajouterai les photos dès que possible.

MIX11 : HTML5 for Silverlight Developpers

Première session après le Keynote dans laquelle Georgio Sardo nous présente les équivalences entres HTML5 et Silverlight.

Ce que je retiens c’est que le duo HTML5/CSS3 comble une partie des lacunes : vectorisation, layout, transform, animation, font, audio/vidéo…

Pour les développeurs Silverlight, vous allez retrouver les mêmes outils en HTML5/CSS3 qu’en Silverlight ou tout du moins un équivalent.

Pour ma part je trouve encore HTML5/CSS3/JavaScript très grossier et complexe (j’ai l’impression de voir Silverlight 1.0). Vivement que tout cela soit définitivement normalisé et outillé car pour l’instant c’est plus proche de l’usine à gaz que d’une solution intégrable dans le cadre d’un vrai site web.

MIX11 : Boot Camp Silverlight 5

En direct du Mix, quelques trucs au niveau du boot camp Silverlight :

  • Quelques nouveautés de la prochaine version de RIA Services (complexe type, custom code generator, …)
  • L’ajout du très attendu évènement OnDataContextChanged (enfin)
  • Rien de plus à se mettre sous la dent pour l’instant.

On continue cet après-midi avec le boot camp WP7.

Bewise Day Conference 2011 le jeudi 7 avril à Toulouse

Comme chaque année Bewise organise sa conférence technique sur Toulouse : la BDC. Si vous êtes dans la région, ça serait bête de rater une pareille occasion de découvrir et échanger sur les dernières technologies Microsoft.

Pour vous inscrire gratuitement : http://bdc2011.bewise.fr/inscription

Venez nombreux !

Dites Non aux UserControls !

Que ce soit dans Visual Studio, dans les samples, sur MSDN partout on nous dit “Pour vos applications XAML, découper vos interfaces utilisateur en UserControl réutilisable”.

Et bien je dis non !

Première raison : les performances. Le temps du calcul du layout d’un UserControl est couteux, et plus on encapsule des UserControl dans d’autres UserControl plus les performances se dégradent.

Comparons deux solutions qui visuellement permettrons d’avoir exactement le même résultat :

  • Dans un cas on encapsule 3 UserControl dans une grille,
  • dans l’autre cas 3 Grid dans une grille.

La figure ci-dessous montre ces deux exemples avec à gauche l’arbre visuel et à droite le code :

 Untitled-3

Résultat sur 100 itérations, le second exemple est 4 à 6 fois plus rapide !! On notera qu’on reste sur une échelle en millisecondes.

Seconde raison : pour les puristes l’utilisation du type UserControl est abusive. Je suis persuadé que vous avez le code ci-dessous (qui d’ailleurs est généré par Visual Studio) :

<UserControl …>
        < Grid x:Name=”LayoutRoot” >
</UserControl> 
 

En gros on utilise un UserControl pour y mettre une Grid, alors qu’un UserControl est un ContentControl et donc devrait être utilisé avec un DataTemplate.

La solution est de ne pas utiliser de UserControl mais directement l’élément dont vous avez besoin (par exemple une Grid). Pour faire cela il suffit de remplacer UserControl par Grid dans le fichier XAML et dans le code-behind comme le montre la figure suivante :

Untitled-2

Rassurez-vous, le designer continu à fonctionner normalement.

Je vous laisse répondre à la question : mais pourquoi a-t-on la fonction “Add UserControl” ?

WP7 – Scrollbar flickering

Si lorsque vous scrollez dans une ListBox la taille de votre ScrollBar change et la ScrollBar fait de petits sauts, vous allez surement apprécier la suite de ce post.

Si vous n’avez jamais rencontré le problème, vous pouvez toujours télécharger le code ci-dessous afin de mieux comprendre.

Télécharger l'application exemple

En fait le problème vient du fait que la ListBox est virtualisée et que les ListBoxItem n’ont pas la même taille.

Il faut savoir que la taille de la Scrollbar est calculée en fonction de deux paramètres :

  • La taille de la zone affichable (l’écran)
  • La taille de la zone à afficher (la hauteur de la ListBox)

Donc pour afficher la Scrollbar d’une ListBox, il est donc nécessaire que la ListBox soit en mesure de calculer sa hauteur.

Problème : les éléments sont virtualisés. Elle ne connait donc pas réellement la taille de tous ses éléments, elle va donc estimer sa hauteur à l’aide d’une formule ressemblant à ceci :

Nombre d’éléments * Hauteur d’un ListBoxItem

Si les ListBoxItem n’ont pas tous la même taille, le résultat du calcul ci-dessus va varier et donc la taille de la Scrollbar aussi. C’est cela qui créer cet effet très déplaisant pour l’utilisateur.

Pour contourner le problème vous avez deux solutions.

La première consiste à faire en sorte que tous vos éléments aient tous la même hauteur, soit en fixant la hauteur en pixel, soit en supprimant les éléments à hauteur variable comme les TextBlock avec TextWrapping.

La seconde, plus radicale, est de supprimer la virtualisation, mais attention vous devez être suûr que le nombre d’élément de la liste reste faible sous peine de vous retrouver avec une application très lente.

WP7 – La virtualisation d’interface

On entend beaucoup parler de virtualisation dans différents blogs sur Windows Phone 7 qui mélangent deux concepts de virtualisation : la virtualisation d’interface (UI Virtualization) et la virtualisation de donnée (Data Virtualisation).

Parce que ces deux notions sont importantes, on va commencer par parler de la virtualisation d’interface et de quelques trucs et astuces sur les VirtualizingStackPanel sur WP7.

Présentation

Le concept de virtualisation d’interface existe sur toutes les plateformes applicatives XAML : WPF, Silverlight et Silverlight For Windows Phone 7.

La virtualisation d’interface permet d’afficher une ListBox de plusieurs millions d’éléments instantanément et sans temps de chargement.

Le principe est simple : au lieu de créer des millions de ListBoxItem et des les binder, on va simplement créer ceux qui sont visibles. Ainsi pour une liste d’un million d’éléments, seuls une dizaine de ListBoxItem seront créés.

L’implémentation

Par défaut les ListBox sont virtualisées ou plus exactement elles utilisent un VirtualizingStackPanel qui s’occupe de virtualiser les ListBoxItem.

Il est possible de désactiver la virtualisation mais cela peut avoir de très lourdes conséquences sur les performances de votre application. Le code ci-dessous présente une solution qui consiste à remplacer la VirtualizatingStackPanel par défaut par un StackPanel :




    
    
        
             -->
                            
        
    

La plateforme WP7

Sur WP7, le VirtualizingStackPanel créé plus d’éléments que nécessaire afin de gérer les scrollings de l’utilisateur sans trop de problème.

Par exemple pour une liste qui affiche 10 éléments, le VirtualizingStackPanel créer 30 éléments. En moyenne il vous suffit de multiplier par trois le nombre d’éléments visibles pour avoir le nombre d’éléments créé.

A noter que les ListBoxItem sont recyclés automatiquement par le VirtualizingStackPanel ainsi une ListBox qui affiche un million d’éléments n’utilisera que 30 ListBoxItem.

Mais si votre ListBox est virtualisée et encore des problèmes de temps de chargement, la virtualisation de données sera peut être la solution (coming soon).

10 trucs sur moi

Je continue dans la foulée de Djeepy, Kosh, Ben, Mim qui dévoilent 10 trucs vraiment pas intéressant sur eux :p

1. A l’âge de 4 ans je m’étais déjà : troué la langue, ouvert l’arcade sourcilière, arracher 4 ongles dans une porte, ouvert le menton. Mais sinon j’étais plutôt calme dans l’ensemble.

2. Mon nom est Cyril Sansus, ça se prononce SAN-SUSSE et non pas SAN-SU. Oui … je vous laisse imaginer le calvaire quand j’étais plus jeune :)

3. Je dessine depuis l’âge de tout petit : crayon, bic, huile, gouache, acrylique, brush, pastel, 3DS Max, photoshop, painter. J’ai voulu me lancer dans le design automobile, mais le destin en a décidé autrement. Heureusement j’ai su faire de mon coté artistique un véritable atout dans mon travail (tiens, je devrais mettre cette phrase dans mon CV)

4. C’est un copain qui m’a enseigné les bases du C vers mes 18 ans. Ma première application fût une pyramide de texte, ma seconde un tracé de ligne (bresenham) et ma troisième un cube en 3D qui tournait. Avec tout ca j’ai fini comme stagiaire dans une société de jeux vidéo durant 1 an et demie et puis j’ai débarqué à Vertice, puis Bewise.

5. J’ai chez moi : un GameCube, une DS, une Wii, une PS2, une XBOX 360 et une PS3. Malgré tout ça je ne joue pas à WOW.

6. Mon surnom est Vko qui se prononce Vico. Vko comme le roi des patates, une longue histoire qui me suit depuis presque 15 ans.

7. J’ai travaillé dans un golf, je ramassais les balles du pratice dans mon petit tracteur. Je me tapais 15 bornes à vélo tout les week-ends pour me faire tirer dessus et gagner 3 cacahuettes.

8. 2007 fût une année affreuse avec une fin heureuse.

9. J’ai connu toute les coupes de cheveux : boule à zéro, rasé, brosse, mèche de 15cm avec le crane rasé (la pire de toute), cheveux mi-long, raie au milieu, etc…

10. J’aime cuisiner et je possède une bonne 10ène de livres dédiés à ce hobby.

Parce que ce jeu est complètement con, je passe le relais à Guillaume.

Mise en ligne des ressources / démo de la BDC

Retrouvez dés maintenant toutes les ressources autour de l’évènement majeur pour les développeurs .NET du sud qui a eut lieu en avril : la Bewise Developper Conference.

C’est ici que ca se passe : http://afterbdc.bewise.fr/.

PS : à noter la magnifique démo SL4 :)

[WindowsPhone7] Lecteur de flux RSS

Parce que j’aime pas tester à moitié, je me suis amusé à développer un petit lecteur de flux RSS avec un look qui vous rappellera surement quelque chose :)

image

La RC de Visual Studio est plutôt molle mais fonctionne correctement.

L’émulateur est pas mal, espérons toutefois que les performances sur Device soient meilleures.

Blend 4 Beta fonctionne bien … mais c’est l’outil sur lequel j’ai le moins travaillé.

Et le plus intéressant, la version Silverlight pour Mobile est hallucinante. On a l’impression d’être avec la Silverlight 4.0. Wouua !

[WindowPhone7] Premiers pas

Hop voici les premiers pas avec les outils de développement pour Windows Phone 7.

Premier changement suite à l’installation des outils : les type de projets pour la plateforme Windows Phone 7. Les projets se découpent en deux groupes :

  1. Les projets Silverlight
  2. Les projets XNA

image

Du coté du Designer de Visual Studio 2010 RC : un émulateur, du XMAL et tout plein de contrôles avec les styles par défaut.

image 

Les développeurs Silverlight et WPF ne seront pas perdus car on retrouve bon nombre des outils (Style, Layout, Controles….).

Je vous recommande vivement de jeter un petit coup d’œil au UI Design and Interaction Guide.

En résumé, un énorme travail sur cette nouvelle plateforme.

Windows Mobile 7 – Silverlight + XNA !

L’actualité Windows Mobile est très active depuis la Mobile World Confress 2010 à Barcelone. (Contrairement à mes posts depuis le début de l’année)

Tout commence le 15 février avec l’annonce de Steeve Ballmer de Windows Phone 7 Series :

“Today, I’m proud to introduce Windows Phone 7 Series, the next generation of Windows Phones.”

“In a crowded market filled with phones that look the same and do the same things, I challenged the team to deliver a different kind of mobile experience. Windows Phone 7 Series marks a turning point toward phones that truly reflect the speed of people’s lives and their need to connect to other people and all kinds of seamless experiences.”

Hier, Microsoft a dévoilé quelques détails sur la plateforme applicative qui reposera sur Silverlight et XNA et qui ne sera pas compatible avec la version 6.5.

Plus de détails sur le blog de Pierre Cauchois.

Prochaine étape : le MIX pour avoir les outils de développement en main.

Et si vous souhaitez avoir des informations supplémentaires sur la prochaine plateforme mobile, rendez-vous à la 4ème édition de la Bewise Day Conférence à Toulouse.

C’est l’évènement gratuit à ne pas rater si on veut découvrir les nouvelles technologies Microsoft ou poser des tas de questions à des experts ou aux Microsoftees.

A bientôt !

Interfaces professionnelles avec Windows Mobile (Part 2)

Dans la première partie, nous avons vu un aperçu des problématiques et des limitations de Windows Mobile lors la création de formulaires.

Dans cette seconde partie, nous allons examiner les outils mis à notre disposition afin de créer des formulaires Windows Mobile et voir les avantages et les inconvénients de chacun.

A noter que les notions présentées ici sont valables en Windows Forms.

Designer de Visual Studio

Tout d’abord parlons de Visual Studio, et plus exactement de son éditeur de formulaire. Plutôt agréable et simple, très proche de l’éditeur de Windows Forms, il permet de créer très rapidement des formulaires. Son principal intérêt est qu’il permet d’avoir un aperçu des formulaire (voir la figure 1). Autre caractéristique tout aussi intéressante, vous pouvez modifier la propriété FormFactor des fenêtres afin de visualiser le résultat sur d’autres émulateurs.

Capture  Figure 1 : Aperçu d’un formulaire dans Visual Studio.

Pour le reste, il suffit de faire glisser un contrôle depuis la Toolbox et de le positionner à l’endroit souhaité.

AutoScaleMode

Un des problématiques dans la création d’interface est la gestion des différentes résolutions : 320x240, 640*480 (VGA), 497x480 (QVGA), WVGA, etc.

Pourquoi est-ce un problème ? Tout simplement parce qu’un écran VGA est 2 fois plus grand qu’un écran classique. Pour qu’une interface garde le même aspect, il faudrait donc multiplier toutes les dimensions par 2. 

Heureusement les fenêtres réalisent automatiquement ce changement d’échelle lorsque la propriété AutoScaleMode de la fenêtre est positionnée à Dpi (valeur par défaut).

En résumé le problème de la résolution est considérablement réduit grâce à cette propriété et toutes les interfaces que vous réaliserez resterons identiques quelque soit la résolution du mobile.

Nous verrons plus tard que dans le cadre du développement de contrôle personnalisé que la notion d’AutoScale doit être prise en compte.

Positionnement

Si on devait simplifier, la conception d’une interface graphique revient à positionner et dimensionner des contrôles dans une fenêtre. Pour cela, vous avez plusieurs possibilités :

  • Soit faire du positionnement manuel
  • Soit faire du positionnement “automatique”

Pour illustrer mes propos j’utiliserais un formulaire très simple composé de trois éléments :

  • Un Label positionné en haut du formulaire
  • Un bouton positionné en bas du formulaire et centré horizontalement
  • Une ListBox qui occupera l’espace restant dans la partie centrale
Positionnement manuel

Le positionnement manuel consiste à définir une position (Location) et une taille (Size) fixe. Le code pour le formulaire d’exemple ressemble à ceci :

this.label1.Location = new System.Drawing.Point(3, 0);
this.label1.Size = new System.Drawing.Size(234, 17);
 
this.listBox1.Location = new System.Drawing.Point(4, 21);
this.listBox1.Size = new System.Drawing.Size(233, 212);
 
this.button1.Location = new System.Drawing.Point(84, 245);
this.button1.Size = new System.Drawing.Size(72, 20);

Voici le résultat sur l’émulateur “Classic” en version portrait (à gauche), paysage (au centre) et sur l’émulateur “Square” (à droite).

image image image

Figure 2 : Positionnement manuel

Plusieurs problèmes se posent :

  • Les marges (semi-automatiques avec le designer de VS) sont hétérogènes donnant une impression d’interfaces non finalisées.
  • Le mode paysage ne fonctionne pas correctement
  • Toutes les résolutions ne sont pas prise en charge

Les problèmes d’orientation d’écran et de résolutions sont parfaitement normaux étant donné que la position et la taille sont fixes.

Il existe un moyen simple pour contourner ce problème : les ancres (Anchor).

Les ancres peuvent être définies sur les 4 cotés (gauche, droite, bas, bouton) des contrôles à l’aide de la propriété Anchor des contrôles. Elles permettent de “coller” les côtés d’un contrôle aux côtés de son parent. Exemple, un bouton avec une ancre en bas à droite restera coller en bas à droite quelque soit la résolution ou l’orientation.

Si on modifie sensiblement notre exemple en ajoutant des ancres sur les trois contrôles :

this.label1.Anchor = AnchorStyles.Top | AnchorStyles.Left | AnchorStyles.Right;
this.listBox1.Anchor = AnchorStyles.Top | AnchorStyles.Bottom | AnchorStyles.Left | AnchorStyles.Right;
this.button1.Anchor = AnchorStyles.Bottom | AnchorStyles.Left | AnchorStyles.Right;

On obtient le résultat suivant :

image image image

Figure 3 : Positionnement manuel avec ancrage

Cette fois-ci, le résultat est satisfaisant.

D’une manière générale on utilise des ancres lorsqu’on fait du positionnement manuel.

Attention toutefois ce mode de positionnement à une limite : si un élément de l’interface change dynamiquement de taille, les autres éléments ne suivront pas ! De plus la gestion des marge avec Visual Studio est une véritable prise de tête, il faut généralement repasser derrière le Designer pour avoir quelque chose de plus propre.

Positionnement automatique

A la différence du positionnement manuel, le positionnement automatique ne vous permet de définir ni la position ni la taille des contrôles : c’est le système qui les calcule automatiquement.

Le positionnement automatique se fait en utilisant la propriété Dock. Le “docking” permet :

  • D’empiler votre contrôles soit à droite, à gauche, en bas ou en haut
  • ou de définir que votre prend tout l’espace disponible

La figure ci-dessous montre un exemple avec 5 contrôles qui utilisent les différents modes de docking.

image Figure 4 : Différents modes de Dock

Donc si on “dock” une bouton en haut (figure 4):

  • Sa position est (0, 0) soit en haut à gauche.
  • Sa largeur est la largeur de l’écran et n’est pas modifiable
  • Sa hauteur sera la hauteur que vous lui avez fixé.

Fonctionnalité intéressante : lorsqu’on dock plusieurs contrôles en haut (figure 5), les contrôles s’empilent les uns en dessous des autres.

image

Figure 5 : Plusieurs boutons dockés en haut

Voici le code et le résultat de l’interface de test avec du positionnement automatique.

this.label1.Dock = System.Windows.Forms.DockStyle.Top;
this.listBox1.Dock = System.Windows.Forms.DockStyle.Fill;
this.button1.Dock = System.Windows.Forms.DockStyle.Bottom;

image image image

Figure 6 : Positionnement automatique

Le résultat est correct sur les différentes résolutions et orientations d’écrans. Cependant on remarques plusieurs défauts :

  • Le bouton prend toute la largeur de l’écran
  • Les marges sont incorrectes : les contrôles sont collés au bord. 
  • Un espacement excessif est mis entre le la liste et le bouton.

Il est possible de contourner le problème du bouton en utilisant un Panel :

  • Le Panel est docké en bas
  • Le bouton est positionné dans le Panel
  • On utilise du positionnement manuel au niveau du bouton

A noter que le positionnement automatique a un avantage majeur : il prend dynamiquement en compte le changement de la taille des contrôles. Autrement dit, si un contrôle est redimensionné, la position des autres contrôles sera automatiquement ajustée.

Conclusion

Nous venons de voir qu’avec le positionnement manuel, l’utilisation d’ancre et quelques retouches on obtient un très bon résultat. Mais la modification de ce type d’interface est complexe.

A l’inverse avec le positionnement automatique il est très simple d’ajouter ou modifier des contrôles : l’affichage se mettra automatiquement à jour. Malheureusement le système calculant tout automatiquement, on n’obtient pas toujours le résultat attendu.

Généralement si j’en restais là, je vous conseillerais d’utiliser à la fois le positionnement manuel et automatique.

Mais je ne vais pas m’arrêter là car ce mécanisme n’est pas satisfaisant. L’objectif ici est de créer des interfaces professionnelles, homogènes, intelligentes, simple à créer, simple à manipuler et maintenables.

Rendez-vous donc dans la prochaine partie où nous verrons comment faire mieux en prenant le meilleurs des deux types de positionnements que nous venons de voir (oui il y aura du code !).

D’ici quelques jours, vous pourrez retrouver cet article (et bien d’autres) sur le site de Bewise.

[Windows Mobile] Afficher une fen&#234;tre lors d’une exception non g&#233;r&#233;e

Personne n’est à l’abri d’une exception non gérée, c’est à dire une exception que vous n’avez pas “catché” et qui fait planter méchamment votre application. Heureusement il est possible de détecter ce type de plantage et d’afficher une fenêtre.

Pour récupérer les exceptions non gérées, vous devez utiliser l’évènement UnhandledException comme suivant (d’ailleurs cela devrait être la première instruction de la plupart des applications .NET) :

AppDomain.CurrentDomain.UnhandledException += 
                                    CurrentDomain_UnhandledException;

Ensuite, il est possible d’y afficher une fenêtre afin d’informer l’utilisateur qu’une erreur est survenue.

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    using (ErrorForm form = new ErrorForm(e.ExceptionObject as Exception))
    {
        form.ShowDialog();
    }
}

Problème le code-ci dessous ne vous affichera pas la fenêtre !? En effet la méthode ShowDialog retournera directement DialogResult.None.

En fait, l’état plutôt instable de l’application lors d’une exception non gérée fait que votre fenêtre peut recevoir des messages erronées depuis la boucle de messages Win32.

Pour palier ce problème vous pouvez utiliser la méthode Application.DoEvents() comme le montre le code suivant :

static void CurrentDomain_UnhandledException(object sender, UnhandledExceptionEventArgs e)
{
    Application.DoEvents();
 
    using (ErrorForm form = new ErrorForm(e.ExceptionObject as Exception))
    {
        form.ShowDialog();
    }
}

Et voilà : ca marche !

Layout pour Windows Mobile (Part 1)

Windows Mobile est, contrairement à ce que l’on pourrait croire, une plateforme ultra complète pour le développement mobile : Compact Framework, office, téléphonie, connectivité, Bluetooth, GPS, notifications, gesture, Web Service, Threading …

Malgré tout cela, Windows Mobile se traine une API plutôt vieillotte concernant l’interface graphique. L’un des points faibles qui va nous intéresser est le layouting, c’est à dire le positionnement, le dimensionnement et la création de formulaires mobiles pour créer de vraies applications métiers.

En effet, la création d’un formulaire Windows Mobile n’est pas évidente si on souhaite obtenir une interface modulable qui s’adapte à la fois à la résolution, à l’orientation de l’écran ainsi qu’au contenu des contrôles.

Un problème majeur qu’on rencontre également en Windows Forms à la différence que le Framework .NET est plus complet sur ce point (FlowLayoutPanel, TableLayoutPanel, AutoSize, GDI+ …).

Bref : Windows Mobile n’offre pas vraiment de solution “toute prête” pour positionner et dimensionner les éléments d’une interface. De ce fait, on abouti souvent à des interfaces peu homogènes et qui ne fonctionnent que pour une résolution donnée (je ne parle même pas de la rotation d’écran).

Une des principales lacunes des contrôles Windows Mobile est qu’ils ne sont pas capables d’adapter leur taille en fonction de leur contenu. L’exemple le plus flagrant est le contrôle Label qui ne possède pas de propriété AutoSize : vous devez définir des dimensions fixes. Et si par malheur le texte vient à change en cours d’exécution et qu’il dépasse la taille du Label, le texte sera tronqué.

Les figures ci-dessous illustrent cette problématique. A gauche , on peut voir un label avec un texte suffisamment court pour qu’il rentre en largeur. A droite, le même label mais pour lequel j’ai dû positionner un texte plus long : on ne peut tout simplement pas voir la fin du texte.

1 2

Si certains se disent “trop simple ! Un petit coup de MeasureString et le tour est joué”, sachez que le Compact Framework ne permet pas de calculer la taille d’un texte avec des contraintes en largeur :p

Toutes ces problématiques ont des solutions et je vous propose de les découvrir ensemble dans cette série de posts. La prochaine fois sera (je pense) consacrée aux outils que propose le Compact Framework afin de créer vos formulaires.

Plus de Messages Page suivante »


Les 10 derniers blogs postés

- TechDays Paris 2012 : Nouvelles tendances du poste de travail - Bring Your own PC par Blog Technique de Romelard Fabrice le il y a 2 heures et 21 minutes

- TechDays Paris 2012 : System Center Service Manager 2012 Vue d’ensemble par Blog Technique de Romelard Fabrice le il y a 4 heures et 31 minutes

- TechDays Paris 2012 : Pleinière second jour par Blog Technique de Romelard Fabrice le il y a 5 heures et 40 minutes

- TechDays Paris 2012 : Retour d'expérience sur la mise en place d'un Cloud Privé par Blog Technique de Romelard Fabrice le il y a 5 heures et 59 minutes

- TechDays Paris 2012 : Comment SharePoint a sauvé mes TechDays par Blog Technique de Romelard Fabrice le il y a 22 heures et 4 minutes

- Perspective 3.0 pour Silverlight 5.0 par Perspective le il y a 23 heures et 25 minutes

- Techdays paris 2012 : mythes et réalités virtualisation et cloud privé par Blog Technique de Romelard Fabrice le 02-07-2012, 17:30

- TechDays Paris 2012 : Top 10 des Best Practices pour SQL Server par Blog Technique de Romelard Fabrice le 02-07-2012, 17:02

- TechDays Paris 2012 : Kinect + Office 365 un bon geste pour votre SI par Blog Technique de Romelard Fabrice le 02-07-2012, 16:39

- TechDays Paris 2012 : Pleinière du premier jour par Blog Technique de Romelard Fabrice le 02-07-2012, 16:24