Dot.Blog

Un peu de teasing ne faisant jamais de mal j’ai le plaisir de vous annoncer la mise en ligne dans les semaines à venir de Easy DataGen X.

Des données aléatoires réalistes

DataGen, vous connaissez certainement, c’est mon générateur de données aléatoires – mais réalistes – vendu depuis des années sur le site e-naxos (voir la page DataGen).

Le succès de ce logiciel imposait sa refonte. La version actuelle étant Win32 réalisée d’ailleurs sous Delphi (la première release interne ayant été écrite sous ce langage en 2000/2001, une époque où WPF ou Silverlight n’étaient que des projets…).

Un outil indispensable

Ce type d’outil est totalement indispensable. Créer des grappes d’objets ou remplir des tables pour tester un logiciel en cours de conception ou faire des tests de tenue de charge est une obligation !

Mais pour beaucoup d’informaticiens ou de petites équipes cela ne justifie pas toujours l’achat d’une licence. Il est vrai que lorsqu’on doit générer 1000 enregistrements de test pour une seule table deux fois par an, même si le tarif de DataGen est particulièrement attractif, il est n’est pas toujours évident de sauter le pas de l’achat. Ainsi seules de grandes structures (grosses SSII, administrations…) n’hésitent pas à investir dans de tels outils, habituées à acquérir des logiciels améliorants la productivité et la qualité.

Une refonte Web Silverlight en accès gratuit

C’est pourquoi j’ai longtemps attendu que la technologie ait enfin évolué de façon radicale avant de refondre DataGen. Refaire un DataGen en Windows Forms n’apportait rien sur la version Delphi (ou trop peu). Refaire DataGen uniquement sous WPF obligeait les clients à installer un Framework .NET récent que beaucoup n’avaient pas et n’ont pas toujours, même aujourd’hui.

La solution est venue de Silverlight, bien entendu. Il a néanmoins été nécessaire d’attendre la version 3 pour commencer les premières études de faisabilité.

Toutefois développer un tel logiciel uniquement en mode Web impose quelques limites (comme l’impossibilité de dialoguer directement avec une base de données installée chez l’utilisateur ce qui est un plus pour l’outil, et ce que fait la version actuelle Win32).

Deux versions : Silverlight et WPF

La décision a alors été prise d’offrir deux versions du logiciels :

• Easy DataGen X (DataGen “facile” en version 10) qui sera accessible gratuitement via le web, sous la forme d’une application Silverlight.
  
• DataGen X, la version WPF offrant la totalité des fonctionnalités, mais payante.

Pour simplifier la mise en œuvre de tout cela, Le nom de domaine et l’hébergement viennent d’être achetés et un petit écran d’accueil est déjà visible pour faire patienter le visiteur ! Le nom du site est facile à retenir : www.easyDataGen.com … plus .. easy, c’est dur à trouver !

Support Bilingue

DataGen X et EasyDataGen X seront utilisables en français ou en anglais comme la version actuelle. L’interface n’est pas seulement concernée, le fonctionnement de certains générateurs en dépend aussi. Par exemple le générateur de fausses adresses postales sait utiliser un style à l’américaine ou la française pour rendre les données plus réalistes. Il s’agit donc bien d’une fonctionnalité à part entière plus qu’une simple traduction de l’interface.

Les améliorations

Si vous lisez le descriptif de la version actuelle vous aurez une bonne idée du principe et des fonctions de base. DataGen 10 apporte malgré tout de très nombreuses améliorations : d’abord une interface moderne et encore plus facile à manipuler; un très grand nombre de générateurs encore plus puissants pour des données encore plus réalistes, plus d’aide, des automatismes rendant les tâches courantes plus aisées.

La version gratuite en ligne et la version payante seront réellement complémentaires. La première sera accessible de partout avec un accès Web, même depuis un Mac, elle sera totalement gratuite tout en proposant l’essentiel du logiciel. La version payante sous WPF offrira tout ce qu’une application desktop peut amener : l’accès direct à toute base de données pour en déduire le schéma (au lieu de saisir le schéma des tables à générer dans la version Web), la génération directe dans une base cible (au lieu de passer par un fichier XML ou texte intermédiaire pour la version Web), la prise en charge des champs Image (avec génération d’images aléatoires, non pris en charge par la version Web), le générateur C# qui permet d’écrire une fonction C# pour générer des données ultra customisées (absent de la version Web), la quantité de données générée sera illimitée dans la version WPF alors qu’elle sera limitée en taille dans la version Web, etc, etc…

Comme on le voit, les deux versions seront bien complémentaires et j’ai vraiment voulu que ces différences soient réelles et non pas artificielles et juste “marketing”.
Certes la version Web gratuite permettra de mieux faire connaître le produit et, je l’espère, de vendre encore plus de versions desktop, mais la présence ou l’absence de facilités ou de certaines possibilités est directement liée aux choix technologiques. Je n’ai coupé aucune fonction de la version gratuite dans le seul but de créer une frustration obligeant à acheter la version payante. L’une est gratuite, disponible de partout via le Web, mais avec les limites de cette technologie, l’autre est plus classique et offre toutes les options que sa nature même autorise.
Pour être totalement franc, la version gratuite servira aussi de vitrine technologique. C’est une réalisation complexe sous Silverlight, en suivant la pattern M-V-VM, et disposant d’une interface agréable. Dans ma position il est assez frustrant de réaliser des choses superbes mais pour le compte de clients qui ne souhaitent pas forcément mettre mon nom en avant mais le leur (ce qui est compréhensible). Pas de mégalomanie ici, mais juste la frustration de ne pas pouvoir montrer tout ce que je réalise. Easy DataGen X comblera, en partie, cette frustration.

Voilà… Encore quelques semaines à attendre pour la bêta de Easy DataGen et vous pourrez tester l’outil en avant-première (l’annonce de la bêta sera réservée aux lecteurs de Dot.Blog).

La version Win32, par les services qu’elle rend, est toujours en vente et le sera jusqu’à la sortie de la version WPF qui sera releasée plus tard, une fois Easy DataGen stabilisé en version RTM. Pour tous les lecteurs de Dot.Blog qui feraient l’achat de la version Win32 à partir de la parution de ce billet j’offrirai la mise à jour vers la version WPF gratuitement pendant les 2 premiers mois de sa mise sur le marché !

Ceux qui auront lu le billet jusqu’à là sans zapper seront ainsi récompensés (car je ne le redirais nulle part) …

Easy DataGen X ? Une raison de plus de … Stay Tuned !

Voici un cas intéressant dont je viens de trouver la solution et que je m’empresse de vous communiquer…

Les écrans multitouch ne sont pas encore légion, sauf chez quelques geeks, dont je suis. Ainsi, pour tester dans un mode proche de la réalité les applications Phone 7 en cours de développement (et faute de téléphones de ce type disponible sur le marché pour l’instant) j’ai acquis un écran 22 pouces IIYama multitouch T2250MTS. C’est très sympa, pas très cher et ça marche vraiment bien de base avec Windows 7 sans installer aucun driver (c’est à dire que Windows 7 possède déjà le fameux driver et que brancher l’USB de l’écran sur le PC suffit sans aucun pilote extérieur ni CD d’installation, c’est beau le progrès !).

L’écran est même fourni avec un stylet qui se cache dans le bas de son boitier, ce qui évite les traces de gros doigts graisseux sur l’écran ! :-)

Bref, tout cela fonctionne à merveille et du premier coup. Quand on arrive sur des zones de saisie et qu’on touche l’écran il y a même un petit symbole de clavier qui apparait pour permettre d’ouvrir un grand clavier virtuel, voire le module de reconnaissance d’écriture. On voit que Windows 7 a été conçu pour investir les Tablet PC… Vraiment cool. Seul bémol, sur un écran vertical manipuler les applis avec les doigts à bout de bras c’est vite crevant… Mais ce n’est pas pour cela que j’ai acheté l’écran, c’est pour utiliser l’émulateur de Phone 7 en mode multitouch (car tester une appli pour téléphone touch avec la souris c’est le meilleur moyen de foirer le design, les doigts sont plus gros et moins précis, il faut y penser à la conception !).

Vous allez me dire c’est quoi le rapport avec Silverlight et Internet Explorer ?

C’est tout simple.

Plantage avec Silverlight ?

Silverlight gère le multitouch. Au moment où internet exploreur se lance et affiche l’application quand je suis en  debug (sous VS ou Blend) je ne sais pas trop quel niveau de sécurité IE reconnaît (en tout cas pas Intranet local car j’ai abaisser toutes les sécurités à ce niveau et cela n’a rien changé) mais à l’activation du plugin Silverlight IE 8 s’arrête, comme planté.

Impossible de s’en sortir. Il faut aller le shooter depuis les processus de Windows ou bien stopper le debug sous VS ce qui a le même effet.

Sécurité cachée !

Et là, l’oeil averti du chasseur de bug voit passer à toute vitesse comme une petite fenêtre cachée sous IE qui, hélas puisqu’on vient de flinguer IE, disparait sans qu’on puisse la lire…

Il y a donc une question qui est posée, en modal, ce qui bloque IE 8. Il “suffit” donc d’accéder à ce dialogue.

Je n’ai pas réussi. Et si on minimise IE pour que ça ne soit plus qu’un petit carré minuscule, on ne voit pas derrière la fenêtre du dialogue… Elle ne vient donc que quand IE est shooté. Bug…

Problème numéro 1: Identifier cette fichue fenêtre.

Ca passe tellement vite que c’est illisible bien entendu.

Ruse : Utiliser l’enregistreur d’écran livré avec Expression Encoder 3 et enregistrer la vidéo du bug pour faire ensuite un arrêt sur image et lire le texte du dialogue…

Ca ne marche pas au premier essai car ça va vraiment vite. Il faut ruser encore plus en modifiant les réglages d’enregistrement de la vidéo, notamment en passant à 100 images secondes et un débit d’au moins 20.000/s.

Là, on finit par choper sur la vidéo un “fantôme” du dialogue plus ou moins opaque selon la chance qu’on a. Mais on l’a eu ! Et que lit-on ?

“Un site Web veut ouvrir un contenu Web en utilisant ce programme sur votre ordinateur” et en dessous : Nom: Composant de saisie tactile ou avec sty…, Editeur: Microsoft Windows.

Le nom du composant n’est pas complet mais on a compris de ce quoi il s’agit. Silverlight, le plugin, au moment du chargement (car la première instruction de l’appli n’est pas encore atteinte, ce que prouve le debugger) doit forcément inspecter la machine pour savoir s’il y a de la vidéo, du son, et tous les périphériques ou facilités utilisées par le plugin. Parmi celles-ci se trouve vraisemblablement le multitouch et la gestion du stylet.

C’est à ce moment que le fameux dialogue est activé pour me demander si je donne le droit ou non à ce module de s’activer. Normalement on dispose sur ce genre de dialogue d’une case à cocher permettant d’indiquer si on souhaite ne plus voir la question.

Hélas, comme IE 8 semble avoir un léger bug, ce fichu dialogue est totalement incessible, on le voit à peine quand on shoote l’application. Et encore faut-il la ruse de la vidéo pour lire de quoi il s’agit.

Comment autoriser l’application bloquante ?

Second problème alors : comment autoriser le programme en question (la gestion du stylet) alors même que le dialogue et sa case à cocher ne sont pas accessibles ?

Réponse : en plongeant dans les arcanes de la gestion de sécurité de IE 8…

Et là, ce n’est pas de la tarte… J’aime bien IE, mais ce n’est pas d’une grande limpidité dès qu’on aborde ce genre de question.

Je vous fait grâce des multiples recherches sur le Web pour arriver à trouver une réponse utilisable. Que je vais maintenant vous exposer car ça peut servir ! (et pas seulement avec un écran multitouch, je suppose que le bug du dialogue doit se voir dans d’autres cas).

Pour faire simple, IE range dans la registry la liste des programmes ayant des droits faibles ainsi que la règle d’élévation de droit qui doit être appliquée. Comment certaines applications arrivent dans cette première liste, c’est un mystère que je n’ai pas essayé d’éclaircir, ce genre de plomberie en informatique me donnant rapidement la nausée. Donc, il existe dans la registry une première liste, elle se trouve là :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\

C’est une liste d’ID, donc de GUID. Il faut la balayer pour lire les clés qui correspondent afin de localiser le programme dont on veut changer les droits. (La registry doit être ouverte en mode administrateur cela va sans dire).

Pour ce qui est du stylet, j’ai fini par trouver le coupable, c’est le programme “wisptis.exe” qui se trouve dans %SystemRoot%\System32. Les clés d’un ID sont AppName, le nom de l’appli, ici celui de l’exe (ce qui ne simplifie pas la recherche vu à quel point le nom n’est pas parlant), AppPath, le chemin que je viens d’indiquer et enfin Policy, un DWord codant l’autorisation.

Vous trouverez des explications ici : http://www.hotline-pc.org/mode-protege.html#

Une fois l’application localisée dans cette première liste on a la moitié de la solution. Changer la Policy à ce niveau ne semble pas avoir d’effet (immédiat en tout cas).

Il faut savoir qu’en réalité, pour l’utilisateur courant, IE stocke une seconde liste, similaire, dans une autre clé de la registry :

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy

L’astuce consiste donc à créer une nouvelle clé dans cette liste en utilisant le GUID repéré dans la première liste puis de recréer à la main les clés, dont Policy à laquelle on donne une valeur dépendant de ce qu’on cherche à obtenir. Pour la gestion du stylet j’ai mis 3, qui semble donner le maximum de droits.

Je reviens sous VS, je lance mon appli SL, et là, Ô magie… mon appli s’affiche et IE ne pose plus l’infamante question cachée…

Et ça marche !

Problème résolu. Comme on ne peut pas dire que la solution est évidente, je pense que la partagée ici sera un jour utile à quelqu’un.

Visiteur qui tombera au hasard d’une recherche Bing ou Google sur cette page et qui gagnera quelques heures de ton précieux temps, n’hésite pas à me laisser un message, ça fait toujours plaisir ! Quant aux fidèles lecteurs de Dot.Blog, le jour “J” j’espère que vous vous rappellerez que ce billet existe !

Et pour d’autres infos le mieux c’est : Stay Tuned !

Une dernière info : Le multitouch de l'écran utilise une barrière infrarouge visiblement, c'est à dire que les doigts ou le stylet coupe une grille infrarouge invisible. Ca marche vraiment bien. Sauf qu'en cette époque estivale, les mouches arrivent ! Et dans ma campagne elles ne sont pas en retard ! Hélas quand une mouche se pose sur l'écran : elle clique ! Ce qui fiche un beau bazard parfois ! Prévoyez ainsi avec l'achat d'un écran de ce type un désinsecteur électrique qui grillera tous ces nuisibles qui prennent votre écran pour un tarmark ! Je sais ça fait un peu rire comme truc... mais le geek n'a pas que des aventures palpitantes, il doit aussi combattre, outre les bugs, les mouches et autres diptères !

Des règles et des bonnes pratiques pour développer des applications Silverlight il en existe bien plus que deux, faire croire le contraire ne serait pas honnête. Ne serait-ce que par la richesse des EDI utilisés (Visual Studio, Expression Blend, Expression Design…) il faut accumuler de l’expérience et mémoriser de nombreuses patterns pour architecturer et designer correctement une application.

Alors, en vrac, voici deux règles qui me passent par la tête et que je voulais vous communiquer:

Programmation par Templates

Sous Silverlight lâchez les vieilles habitudes. L’une de celles-ci que je rencontre souvent est celle qui consiste à se jeter sur son clavier pour créer un UserControl (ou un Control par héritage) dès qu’on a besoin d’un nouveau composant qui semble absent de la bibliothèque.

Erreur. Méthode du passé.

En effet, Silverlight et WPF impliquent des changements radicaux de mode de pensée et d’habitudes. Sous ces environnements, la majorité des besoins sont couverts par les composants existants, il “suffit” juste d’en modifier le template.

Nous sommes passés d’une programmation par héritage à une programmation par modèle (template).

Deux exemples pour bien cerner ce que j’entends par là.

Sticky Note

Prenons pour premier exemple un cas d’école, déjà ancien mais en plein dans notre propos : sticky notes pour WPF (sticky notes listbox). Ce “composant” se présente comme une liste verticale de petites notes de type “post-it” légèrement décalées les unes par rapport aux autres.

L’effet est sympathique et donne un peu de fantaisie et de vie à ce qui ne serait qu’une liste rectangulaire dans une grille en programmation classique.

Ce magnifique “composant” n’utilise aucun code “'classique”. Inutile dans les sources de chercher la classe StickyNotes qui hériterait de Control ou même de chercher dans les fichiers de l’application le UserControl créé pour l’occasion.

Rien de tout cela.

Sticky Notes est créé uniquement en jouant sur le templating d’une simple… Listbox ! Une poignée de Xaml et des templates, c’est tout.

Language button

Dernièrement dans une application Silverlight je devais implémenter un bouton permettant de choisir depuis la page d’accueil la langue à utiliser (français ou anglais). Forcément on pense à un ToggleButton ou quelque chose d’équivalent (ce qui n’existe pas de base). On pourrait aussi associer deux RadioButton dans une grille.

Mais le plus intéressant consiste à se demander “quel control existant se rapproche le plus du comportement que je souhaite implémenter”. En y réfléchissant quelques secondes on s’aperçoit assez vite qu’une CheckBox possède deux états stables (oublions ici l’état indéterminé). Ce composant comporte toute la logique et les états visuels permettant de gérer deux états.

Par défaut une CheckBox c’est une case à cocher avec un bout de texte devant ou derrière.

Le plus dur consiste à se l’imaginer comme deux drapeaux (français et US) côte à côte, celui qui est sélectionné étant à 110% de sa taille et l’autre à 50%. Par convention arbitraire et chauvinisme inconscient certainement j’ai considéré que IsChecked = True était le Français, à False l’anglais. En partant d’une CheckBox que j’ai totalement vidée de son contenu, et en ajoutant les deux drapeaux (et quelques autres ingrédients et animations via le VSM) j’ai obtenu un merveilleux “ToggleButton” sans jamais “sous-classer” le moindre contrôle. Juste en écrivant un template.

Le ViewModel de la page d’accueil offre une propriété IsFrench de type booléen qui est simplement bindée à la propriété IsChecked du CheckBox (en mode TwoWay) et l’affaire est jouée !

Règle 1 : De l’héritage au templating

La programmation Xaml (Silverlight / WPF) est une programmation visuelle qui s’effectue par templating. Créer des UserControl et encore plus sous-classer des contrôles existants devient quelque chose de rarissime.

Nous sommes passés de l’ère de la programmation objet par héritage à celle de la programmation visuelle par templating. Bien comprendre toute la signification de ce changement est un point primordial et un préliminaire indispensable pour comprendre cette technologie et donc la programmer intelligemment.

Programmation par Properties

Il s’agit du même genre de glissement, une pente douce mais dont la longueur finit par conférer une vitesse tellement grande à celui qui s’y laisse glisser que le décor n’a plus rien à voir avec celui qu’on a tout le temps d’admirer en balade à dos d’âne…

Dans l’exemple précédent on touchait du doigt cette nouvelle approche mais sans la mettre en exergue.

En effet, dans la pattern M-V-VM plutôt que de créer un code incompatible avec le visuel d’un côté pour ensuite créer de l’autre des tripotés de convertisseurs (programmation classique non M-V-VM sous WPF et Silverlight dans une moindre mesure) il semble bien plus simple d’exposer dans les ViewModels des propriétés directement exploitables par l’UI. Si adaptation des données il doit y avoir c’est le ViewModel qui s’en charge (directement si cela est ponctuel, ou via une classe de service si la chose doit être réutilisées ailleurs).

Dans l’exemple précédent du Checkbox transformé en ToggleButton de langue, aucun événement n’est programmé, aucun gestionnaire n’est écrit pour réagir au clic. Tout se joue dans le ballet automatique de IsChecked de la CheckBox et de IsFrench du ViewModel sous l’égide discrète mais indispensable d’un binding two way…

Quant l’utilisateur clique sur la CheckBox (enfin sur le ToggleButton avec les deux drapeaux) le composant sous-jacent bascule sa propriété IsChecked à vrai ou faux selon le cas. Comme cette dernière est liée à IsFrench du ViewModel, une propriété de type booléen aussi pour assurer la compatibilité des comportements, le ViewModel reçoit pas un événement mais l’une de ces propriétés (IsFrench) se voit modifiée. Ce qui déclenche le Setter de cette dernière. Ce dernier s’occupant de modifier le fichier de ressource utilisé pour puiser les chaines de caractères. De là et par une série de notification de changement de propriétés, il avertit en retour la Vue que toutes les propriétés de type texte ont été modifiées. La vue (et ses binding) y réagit en rafraichissant les affichages…

Toute cette mécanique s’est déroulée sans aucun gestionnaire d’événement, sans aucune programmation “classique” (en dehors du ViewModel et de ces propriétés gérant INotifyPropertyChanged, ce qui peut être automatisé ou simplifié en utilisant Mvvm-light par exemple).

Règle 2 :  de l’événementiel à binding

La seconde règle d’or à bien comprendre pour tirer totalement partie de Xaml et de ses enfants (Silverlight et WPF) est ainsi d’opter pour un modèle de développement de type Model-View-ViewModel se basant presque exclusivement sur des couples de propriétés mis en relation via binding.

On est passé de l’ère du développement dit “événementiel” des premières versions de Windows à ce qu’on pourrait appeler la “programmation par Binding” ou par “properties”.

Conclusion

Pour résumer :

Règle 1 on cherche à templater des contrôles existants sans créer des UserControl ni dériver des contrôles existants.

Règle 2 : on base la dynamique de l’application sur le binding entre propriétés et non plus sur les gestionnaires des événements des contrôles.

Si vous avez déjà fait vôtre ses règles alors vous allez devenir, si ce n’est pas déjà le cas, de très bons développeurs Silverlight et Xaml très recherchés !

Si vous n’aviez pas encore vu les choses sous cet angle là, je serai très heureux si par chance j’ai réussi à tirer le voile qui vous empêchait de les voir ainsi. Vous ne ferez qu’entrer plus vite dans la catégorie précédente !

Bon Dev, et, œuf corse,

Stay Tuned !

Pour une fois que Microsoft nous fabrique des petites vidéos humoristiques en Français il ne faut pas s’en priver.

C’est drôle, caricatural, et c’est court (7 Mo la vidéo) donc rapide à charger.

Pour l’instant il y a 2 épisodes.

J’aime bien.

Pour voir les deux épisodes c’est ici :

http://cid-19c8825385018760.skydrive.live.com/browse.aspx/Les%20Temps%20Changent

Xaml n’est pas compilé, ce qui signifie que le runtime l’interprète à l’exécution. Cet interpréteur est donc présent aussi bien quand on exécute une application WPF que Silverlight. Cela peut permettre des choses intéressantes comme la création de code Xaml dynamiquement au runtime…

Cette possibilité n’est que peu souvent évoquée alors que dans certains cas elle autorise de dynamiser tout ou partie d’une interface. Rien n’interdit en effet de créer une mise en page complète par ce procédé, VSM et animations comprises. La génération de Vues (partielles ou totales) en fonction d’une description paramétrée par l’utilisateur fait partie des cas concrets où de la génération dynamique de code Xaml peut grandement simplifier la mise en œuvre du code.

Le potentiel est grand, il suffit juste de savoir que cela existe car techniquement cela est finalement très simple. L’essentiel tient dans XamlReader.Load() qui sait rendre un objet à partir d’un code Xaml.

Pour sortir des sentiers battus, voyons comment on peut utiliser cette stratégie pour créer dynamiquement un composant à partir de son nom de classe non pas en utilisant la réflexion sous C#, juste en générant du code Xaml…

L’exemple live ci-dessous permet de créer un contrôle (pré-saisi par défaut pour un textBlock) qui sera ajouté dans un StackPanel dans la seconde moitié verticale de l’affichage. Créez plusieurs TextBlock de cette façon en modifiant le texte ou d’autres paramètres. Puis créez-en un auquel vous ajouterez dans les paramètres: Name=’Test’. Enfin cliquez sur le bouton “changer couleur des TextBlock”.

Tous les TextBlocks créés passeront en Foreground noir, et celui qui a pour non ‘Test’ vera sa taille de fonte augmentée de 4.

Le code de création du contrôle est le suivant :

namespace DynamicXaml{    
public static class DynamicXamlHelper
{
public static UIElement CreateControlFromName(string controlName, 
string controlNamespace, string xmlnsPrefix, string properties)
{
var sb = new StringBuilder();
sb.Append("<" + controlName + " xmlns");
if (xmlnsPrefix.Length > 0) sb.Append(":" + xmlnsPrefix);
sb.Append("=\"" + controlNamespace + "\" " + properties + "/>");
try
            { return (UIElement)XamlReader.Load(sb.ToString()); }
catch
            {
return null;
}
}
}
}

Les paramètres sont ceux que vous pouvez taper dans les textBox de l’exemple live ci-dessus:

• le nom de la classe du contrôle, par exemple “TextBlock”
• le namespace du contrôle, ex: http://schemas.microsoft.com/winfx/2006/xaml/presentation
• le préfixe xml, vide dans l’exemple par défaut
• une zone libre de paramètres qui seront ajoutés à la balise de création.

Pour le reste, le plus simple est jouer avec le code source de l’exemple : DynamicXaml.zip (7,08 kb) [Downloads: 67]