Xaml, Enumeration et intellisense !

Un petit post bien sympa pour se faciliter la vie...

Lorsque nous construisons des contrôles graphiques (exemple : librairie de contrôles), il arrive que nous utilisions des propriétés qui retournent des membres d'énumération.

Lorsque l'on vient à déclarer ces contrôles dans un fichier xaml, et que l'on appelle la propriété en question pour lui affecter une valeur ...
rien ne se passe : l'intellisense est dans les choux !

Pour corriger cet "intelli-ignorance", il suffit d'appliquer un geste très simple :

1. déclarer le namespace dans le fichier AssemblyInfo.cs de la façon suivante :
[assembly: XmlnsDefinition("http://monTruxAMoi.com/wpf/", "nameSpaceDeLenumeration")]

où XmlnsDefinition provient de System.Windows.Markup.

2. Je compile,

3. Enfin, dans le Xaml ou je désire utiliser mon contrôle, j'ajoute une déclaration xmlns:monTrux="http://monTruxAMoi.com/wpf/"

Hélas cela ne fonctionne "correctement" qu'en WPF ...
En Silverlight (même 3), Visual Studio ne résoud pas correctement les using dans les fichiers xxx.g.cs
du coup, on perd l'intellisense côté C# ... pas pratique !

Silverligh 3 : Fichiers de Styles

Une nouveauté intéressante de SL3 est la possibilité de sortir les styles utilisés du fichier App.xaml pour les placer dans des fichiers propre (exemple : Style.xaml).

Pour ce faire, créez un fichier de type Dictionnaire de ressource,
Et ensuite, dans le fichier App.xaml, ajouter les lignes suivantes :

<Application.Resources>
<ResourceDictionary>
<ResourceDictionary.MergedDictionaries>
<ResourceDictionary Source="Assets/Styles.xaml"/>
</ResourceDictionary.MergedDictionaries>
</ResourceDictionary>
</Application.Resources>


Cela aura pour effet de fusionner la liste des fichiers indiqués par la source comme étant des ressources de l'application (utilisable donc par les appels "StaticResource").

@+

Silverlight 3 !

Nous y sommes !

La version finale de Microsoft Silverlight 3 a été publiée ce vendredi !
A nous le mode Offline, la 3D, le streaming HD, le framework RIA !

Bref que de bonnes nouvelles ...
De là a combiner cela au Cloud Azure...

May the force be with you !
@+

PS : La chaine NBC a annoncé couvrir la diffusion des JO d'hivers de Vancouver en HD (720p) par une plateforme Silverlight 3 !
(Ce qui a été réalisé pour Roland Garros 2009)

Silverlight et WCF ... pour être propre !

L'utilisation d'un canal de communication WCF par une appli silverlight nécessite un appel asynchrone, et donc, l'abonnement à l'évènement blablablaComplete.

Lors de l'appel de la méthode blablabla, nous pouvons passer en paramètre l'objet proxy afin d'effectuer des opérations de nettoyage (pour être plus propre) :
CloseAsync( ) et le désabonnement à l'évènement.

Exemple :

// méthode sur l'évènement complete (sous la forme d'une expression lambda) EventHandler methodComplete = null; // Proxy pour l'appel WCF SrvDatasClient proxy = AppDataHelper.GetProxy(); // définition de la méthode lambda methodComplete = (ssender, ee) => { // traitement du retour //ee.UserState contient le proxy (ee.UserState as SrvDatasClient).SaveCompleted -= methodComplete; // plus propre (ee.UserState as SrvDatasClient).CloseAsync(); // super plus propre }; proxy.GetAllCompleted += methodComplete; proxy.GetAllAsync(proxy); // appel ou je passe en param le proxy

C'est toujours plus propre de fermer ce que l'on utilise ...

Silverlight 2 et URL

En Silverlight 2 (comme en WPF d'ailleurs), il est fortement conseillé de créer des styles, et de mapper ces derniers aux composants concernés (via leur balise style et le mécanisme de resource statiques).

Dès lors, ces styles sont créés soit dans les ressources du usercontrol concerné, soit dans les ressources de l'application (App.xaml)

Dans le cas d'images (incorporée dans l'assembly comme ressource) il est d'usage d'utiliser les url's absolues pour permettre la récupération des images, quel que soit le niveau du sous namespace, ou sous répertoire du xaml du user control concerné.

Ce chemin se présente de la sorte :

/nomDeLAssembly;component/blablabla

où blablabla correspond au chemin de l'image.
Si le chemin de l'image dans le projet est Images/toto.png
mon chemin sera :
/nomDeLAssembly;component/Images/toto.png

@+

Silverlight 2, WCF et les FaultException

Lorsque une équipe travaille en Silverlight, il est nécessaire de communiquer avec un proxy (serveur) pour disposer de données et interagir avec elles.
Pour se faire, nous pouvons utiliser les objets WebRequest ou WebClient (tuto : http://bdevuyst.developpez.com/tutoriels/silverlight/S2-interagir-avec-son-serveur/).

Nous pouvons également utiliser WCF (Windows Communication Fundation). Pour rappel, cette technologie permet de ne maitriser qu'une seule syntaxe (en C#, par exemple), et un fichier de paramètres permettra à WCF de savoir quel est le protocole à utiliser pour les échanges (WebService, NetPipes, ...).

Lorsque l'on manipule du WCF, les exceptions rencontrées sur le serveur peuvent être transférées au client grâce à la classe FaultException (Il s'agit d'une Exception qui peut être sérialisée vers un client).
Tout autre Exception (dérivant de System.Exception) se voit arrêtée par WCF côté serveur.
En effet, pour des raison de sécurité, une System.Exception ne peut traverser WCF.
(Elle contient trop d'informations sur l'architecture de l'application - stacktrace par exemple).

Suite à un souci (l'explication est à trouver ici : msdn), ces erreurs ne peuvent être remontées vers le client Silverlight 2 (ce sera peut être le cas en version 3).

Dès lors, pour pouvoir gérer, côté Silverlight, les exceptions éventuelles de l'application serveur, il faut être un petit peu sioux !

Voici le lien d'une solution Visual Studio 2008, proposant une réponse à ce problème :
ftp://ftp-developpez.com/bdevuyst/tutoriels/silverlight/S2-gestion-exception-wcf/SilverlightApplicationGstException.zip

Globalement, voici le mécanisme :

La solution est divisée en 3 projets :
- Le projet Web qui héberge l'application Silverlight et un Service WCF (.svc),
- Le projet Silverlight,
- Un projet bibliothèque de classe qui "simule" une autre couche, qu'utilise le Service WCF,

1. L'application Silverlight appelle le point de terminaison WCF, (derrière le bouton),
2. L'application WCF traite la demande, cherche à obtenir les données, et une exception se produit... (pas de chance ;) )
3. La couche WCF catch l'exception, et retourne un objet d'un type particulier
4. Cet objet retourné est la clé du mécanisme

Il s'agit d'une classe générique qui contient 3 propriétés :

• Message : Correspond au message de l'exception générée, vide si le traitement s'est bien passé,

• StackTrace : Pour le debug (dans le cas de symbole de debuggage absent, ce champ est vide)

• ObjetAttendu dont le type est précisé lors de la déclaration de la variable. Cette dernière contiendra l'objet attendu si aucune exception ne s'est produite pour le récupérer.

L'application Silverlight récupère alors un objet qui contient les trois propriétés, et peut donc déterminer si une exception s'est produite, et si un résultat est exploitable.

Je vous invite à télécharger les sources pour bien saisir le mécanisme...
Lien des source de la solution Visual Studio 2008 :
ftp://ftp-developpez.com/bdevuyst/tutoriels/silverlight/S2-gestion-exception-wcf/SilverlightApplicationGstException.zip

@+

Nouveautés Silverlight 3

Silverlight continue de grandir : à l'occasion du Mix 2009 à Las Vegas, Microsoft a levé le voile sur les nouveautés SL3.

Voici une liste non exhaustive :

- Héritage des styles (comme en WPF)

- Effets graphiques 3D (ombres, projections 3D, ...)

- Création d'applications Offline, avec un loader d'application Silverlight qui gère la mise à jour automatique de l'instance Offline à partir de l'Online,

- Gestion de la HD pour les vidéos

Pour une description plus complète :

http://silverlight.net/getstarted/silverlight3/default.aspx#whatsnew

@+