Dot.Blog

C#, XAML, WinUI, WPF, Android, MAUI, IoT, IA, ChatGPT, Prompt Engineering

Les ChildWindow's de Silverlight - Reloaded

[new:10/10/2010]J’avais produit il y a quelques mois une petite vidéo de formation montrant comment se servir des ChildWindow sous Silverlight. La vidéo était hébergée par “Silverlight Streaming” un service de Microsoft aujourd’hui disparu. Je vous propose donc à nouveau la même vidéo hébergée ailleurs pour ceux qui l’auraient loupé…

Parmi les nouveautés de Silverlight (3) se trouve la classe ChildWindow. Elle permet de créer facilement en quelques clics un dialogue modal, le tout avec animation.

Savoir se servir de cette classe ne réclame pas forcément des pages entières d'explication, alors justement m'est venu l'idée d'en faire un tutor video...

C'est au visionnage de cette video que je vous invite pour comprendre comment utiliser cette nouvelle feature de Silverlight 3.

(le son micro n'est pas terrible, pour la prochaine video j'utiliserai autre chose de mieux ! Sorry, la définition est assez basse mais le fichier avi fait déjà 30 Mo et l'original non compressé fait plus de 9 Go ... Je vais voir comment améliorer tout ça pour la prochaine fois, promis !).

Bonne vidéo !

PS: je viens de vérifier la qualité après passage sur YouTube et c'est vraiment pas le must... Mais au moins la vidéo est de nouveau en ligne !

Faites des heureux, PARTAGEZ l'article !

Commentaires (4) -

  • Phobias

    12/03/2012 13:29:50 | Répondre

    Bonjour Olivier,

    Merci pour ton excellente vidéo.

    Lors des dernières Techdays, j'ai vu que Thomas Lebrun utilisait ce composant (que je ne connaissais pas) pour créer une fenêtre pour donner des détails sur les exceptions non gérées par l'application. Cette fenêtre proposait ainsi à l'utilisateur d'envoyer par mail au développeur le détail de l'erreur.

    Bien que cela sorte du cadre de cette vidéo, pourrais-tu m'expliquer en quelques mots comment réaliser cela ?

    Bonne journée

  • Olivier

    12/03/2012 14:44:11 | Répondre

    @Phobias: les childwindows n'y sont que pour très peu dans le mécanisme que tu évoques. Juste un moyen d'afficher l'info comme d'autres auraient pu être utilisés.
    Le principe consiste à détourner les erreurs non gérées au niveau de l'App.Xaml qui possède génèrement un code par défaut pour cela. Il faut le modifier, récupérer l'exception et après tu présentes cela comme tu veux.
    Une childwindow est bien entendu une solution intéressante. Pour l'envoi d'email il faut que le serveur de l'application propose un webservice pour le faire, une appli SL ne peut pas le faire directement.
    Du coup, puisqu'il s'agit d'une boite d'erreur, je ne suis pas partisan de cet ajout, rien ne dit que le problème ne vient justement pas de la communication avec le serveur... l'envoi de mail provoquera une autre erreur...
    L'affichage erreur est une bonne chose, mais je préfère un stockage
    dans l'Isolated Storage plus une option du soft permettant de ressortir le journal des erreurs en format texte (dans "mes documents" par exemple) que l'utilisateur peut envoyer avec son propre gestionnaire de mail, ou qu'un technicien peut vérifier directement à l'écran.
    On peut mixer bien entendu tout cela pour proposer une gestion des erreurs très complète.

  • Phobias

    13/03/2012 22:30:58 | Répondre

    Merci pour ces précisions
    J'apprends beaucoup à chacun de tes articles.

    Pourrions-nous par exemple imaginer que ce rapport d'erreur stocké dans l'isolated storage soit envoyé par mail au prochain lancement de l'application ?
    Une boite de dialogue confirmant ce choix en laisserait tout de même la charge à l'utilisateur ?

  • Olivier

    14/03/2012 03:18:17 | Répondre

    @Phobias: En effet, rien n'interdit de stocker un fichier "erreur" dans l'IS et au lancement de l'application de vérifier que ce fichier est présent ou non, et là prendre la décision d'envoyer un mail au support (puis de supprimer le fichier en cas de résussite de l'envoi).
    Il sera malin de conserver une copie de l'erreur dans l'IS dans un fichier de type log au cas où le mail n'arrive pas (il n'y a pas de moyen fiable et simple de savoir si mail est "bien parti").
    Dans tous les cas, il faudra prévoir un service web ou WCF côté serveur pour transmettre réellement le mail. Une application Silverlight ne pouvant pas en envoyer elle-même ni accéder à la machine de l'utilisateur pour lancer son gestionnaire de mails (sauf avec des droits élevés en OOB par exemple, mais c'est plus rare comme type d'appli SL).

Ajouter un commentaire