- 16février 2009
-
Un bug très très étrange, avec un symptôme déjà rencontré mais pour une raison totalement différente, nous embêtais depuis quelques semaines chez l’un de nos clients : les popups (menu, combobox, etc.) n’apparaissaient pas sur l’un des postes… Après pas mal de recherche, il est apparu que les popups s’affichaient bien, mais en dessous de la fenêtre principale ! Pas très évident à expliquer et encore moins à corriger :) Eh bien, si, en fait, il s’agit d’un bug connu : http://support.microsoft.com/kb/943326/en-us Je vais de ce pas installer le correctif !
|
|
|
- 06février 2009
-
J’ai découvert COLOURlovers il y a déjà quelque temps, et il s’agit d’un site quasi indispensable lorsque l’on a besoin de définir les couleurs d’une application. Entre les palettes de la communauté et COPASO, leur outil intégré de création, on peut trouver à peu près tout ce que l’on cherche. 
Je ne sais pas si je l’avais raté où s’il s’agit d’une plus ou moins nouveauté (on ne peut pas dire que l’on visite ce genre de site tous les jours quand on est développeur, alors ca date peut-être…) mais il y a maintenant la possibilité d’exporter en WPF/XAML les différentes palettes ! 
Voici le résultat (en export XAML/Silverlight) : <SolidColorBrush x:Key="Brush1" Color="#FFEAEDDB" />
<SolidColorBrush x:Key="Brush2" Color="#FFD6D4C4" />
<SolidColorBrush x:Key="Brush3" Color="#FF5C514E" />
<SolidColorBrush x:Key="Brush4" Color="#FF784F56" />
<SolidColorBrush x:Key="Brush5" Color="#FFB1103C" />
|
- 03février 2009
-
L’un de mes grands moments, lorsque j’ai commencé à faire du WPF, a été la découverte que de nombreux contrôles que je croyais “tout bêtes”, ne l’était pas tant que ça. Par exemple, cette semaine, j’ai commencé à intégrer certaines modifications sur le système d’aide de l’un des logiciels sur lequel je travaille. Et au milieu de ces modifications se trouvait la réponse à une demande simple : fournir des tooltips “avancés”, similaires à ceux trouvés dans Office 2007. 
Dans WPF, les tooltips ont deux caractéristiques très intéressantes : - Ils sont skinnables : vous pouvez donc en faire (presque) ce que vous voulez en terme de design
- Ce sont des “ContentControl” : aucun problème donc pour y mettre un Panel quelconque et y ajouter autant de contrôles que nécessaire
L’exemple ci-dessus – même si il est, sur le plan graphique, loin d’être formidable – se fait facilement avec le code suivant : Du coté des ressources <Style TargetType="{x:Type ToolTip}">
<Setter Property="Background" Value="#7F000000"/>
<Setter Property="BorderBrush" Value="#7Fdcdcdc" />
<Setter Property="Foreground" Value="White"/>
</Style>
Du coté du contrôle
<Button ...>
<Button.ToolTip>
<DockPanel>
<Image DockPanel.Dock="Left">
<!-- ... -->
</Image>
<TextBlock DockPanel.Dock="Top" FontWeight="Bold"
VerticalAlignment="Center" Text="Menu principal" />
<TextBlock Text="Cliquez ici ...."/>
</DockPanel>
</Button.ToolTip>
</Button>
Facile non ?
|
- 28janvier 2009
-
 Allez, zou, encore un peu de “pub” pour Thirteen23, qui s’installent de plus en plus comme LA référence dans les applis WPF. (bon, par contre coté jeux de mots, c’est toujours assez spécial : star-chirp, il fallait l’oser quand même…)
L’appli est très sympa coté interface, et même si il reste quelques petits défauts d’affichage de temps à autres, on est vraiment dans le plus pur produit WPF : des animations un peu partout, de la transparence à gogo etc. Après, il leur reste quelques petits soucis d’ergonomie : on aimerai bien par exemple avoir un raccourci pour créer un nouveau twit, et ce genre de choses, F5 ne serait pas de trop pour rafraîchir, de même que la gestion d’un bouton back pour revenir en arrière En tout cas, ca se télécharge par ici.
|
- 20janvier 2009
-
C’est assez ancien, mais puisque Benoît fait dans le screen saver, moi aussi ! :) 
Ce que vous voyez ci-dessus est la version “application” de decollage, mais cela s’installe très facilement en économiseur d’écran. Pour la petite histoire, il s’agit de l’une des premières applications WPF que j’ai pu voir, elle n’est peut être pas bluffante, mais quand on sait que WPF n’est pas plus compliqué à programmer que WinForms (enfin… presque…), cela m’avait impressionné. Ca se télécharge par ici, mais c’est surtout leur blog qui est intéressant.
|
- 26avril 2008
-
Si vous faites un peu de programmation WPF, vous avez certainement dû vous retrouver assez souvent à écrire du code ressemblant à : ThreadPool.QueueUserWorkItem
(new WaitCallback(delegate(object ignored)
{
// un appel à un traitement long comme une requête
// sql ou un web-service
Dispatcher.BeginInvoke(
DispatcherPriority.Normal,
new WaitCallback(delegate(object ignored_too)
{
// le traitement de mise à jour de votre
// controle
}
), null);
}
));
Je vous propose donc un petit extrait de code qui se charge d'écrire cela à votre place (le bonus étant que les namespaces sont importés automatiquement) :
Une fois installé, vous pourrez utiliser le snippet wpfthreadtask :
|
- 21avril 2008
-
C'est un peu ancien, mais je viens juste de le voir : une démo de l'application AT&T utilisant surface.
|
- 31janvier 2008
-
Cela fait maintenant un an que je réalise (principalement) du développement WPF, d'abord pour 2 ou 3 projets "direct-poubelle" - vous savez ces mini-projets que l'on prévoit de ne jamais arriver à finir et qui ne sont là que pour faire toutes les gaffes possibles et imaginables - puis pour deux applications LOB. Bien qu'ils ne soient pas finis, ces deux derniers projets ont aboutis à la création d'un certains nombres de règles d'or que nous utilisons (et utiliseront) pour améliorer le développement... N'ayez pas peur du découpage design/développement C'est probablement l'un des points les plus difficiles à mettre en place - et un sujet de complainte fréquent sur les blogs parlant de WPF - mais une fois un certain nombres d'idées prises en compte et appliquées, cela va beaucoup mieux... La règle à retenir pour ce point est : "ne faites pas faire au développeur le travail du designer". Dans les règles suivantes, j'utiliserai le terme "fonctionnel" pour désigner les données et la façon de les manipuler, et le terme "présentation" pour tout ce qui est de l'ordre du rendu visuel. Si vous utilisez un modèle de séparation "règles métier" / "affichage", sachez donc que la partie que je nomme "fonctionnelle" correspond au code utilisé dans la "vue" pour appeler les objets métiers et traiter leurs réponses. - Le développeur doit exposer des propriétés pour toutes les données qu'il souhaite voir afficher. Ce n'est pas à lui de décider de où, ni de comment seront affichées les informations d'un écran.
- Les animations et autres effets graphiques sont du ressort du designer. Oui, même celles que l'on ne peut pas facilement exprimer en XAML ! Il n'est pas logique que le développeur "fonctionnel" se charge de déclencher des animations ou de manipuler directement des objets (panels, listview...) de la partie "présentation". Après tout, lorsqu'un designer fait une animation Flash, il écrit du code ActionScript pour de très nombreuses choses. Le principe est ici le même : il devra probablement mettre les mains dans le cambouis. Bon, bien sûr, ça c'est le concept, mais une bonne solution pour éviter que le code soit saccagé - euh, oui je suis développeur dans l'âme, pourquoi ? - est :
- Si votre équipe est suffisamment grande, d'affecter un développeur à l'équipe design, ou dans le cas d'une petite équipe de faire travailler le développeur au code de présentation après qu'il ait fini le code fontionnel. Ce développeur-designer sera chargé d'écrire tout le code nécessaire aux animations et autres effets graphiques.
- de séparer dans des fichiers sources différents (à l'aide de partial class) la partie fonctionnelle de la partie présentation.
- Le développement d'une fenêtre ou d'une page, demandera probablement plusieurs aller-retour. C'est l'une des choses qu'il ne faut clairement pas oublier : il n'y a que très peu de chance que le designer ne soit pas bloqué par un oubli du développeur et/ou que le développeur ne soit pas amené à ajouter du code (évenements, nouvelles propriétés) à cause du designer.
- Vos développeurs vont devoir oublier une bonne partie de ce qu'ils savent sur l'écriture d'une application.Dans chaque développeur Windows Forms se cache un bidouilleur-né : nous avons été habituées depuis longtemps à nous servir des contrôles directement (qui ne s'est jamais servi de la propriété Tag d'un ListViewItem comme seul et unique conteneur pour ses données métier ?) et donc à nous appuyer sur eux, mais ce genre de comportement ne doit plus être de mise avec WPF.
Prenez le temps de développer un framework applicatif L'un des points que l'on omet aussi souvent lorsque l'on parle de WPF c'est de se souvenir qu'il s'agit d'un framework de présentation et en tant que tel, qu'il n'est pas suffisant dans le développement d'une application complexe. Qu'il s'agisse de répercussions de ce fait ou des oublis dans le framework, voici deux exemples de fonctionnalités à développer. - Le modèle de gestion des threads choisi pour le framework est... comment dire ? .... extrêmement pénible ! Pour éviter de nombreux soucis de concurrence, les données utilisées sur celui d'affichage ne sont pas accessibles sur les autres. Il vous faudra donc, pour la santé mentale de vos développeurs, faire développer des classes simplifiant la discussion inter-thread( par exemple pour fusionner le résultat d'un appel asynchrone à un web-service avec une ObservableCollection exposée par votre contrôle)
- Il n'est pas possible d'écrire du code ni même des expressions dans le fichier XAML (il n'y a pas d'équivalent XAML à "IsEnable= (madonne==null)" par exemple), il vous faudra donc créer des classes de conversion de données ou d'extension du markup pour pallier à ce manque.
Acceptez les limites de WPF Avec .net 3.0 (et 3.5), nous avons le droit à une version 1.0 de WPF, ce qui engendre un certain nombre de soucis et de limitations. Pour un développement réussi, il vous faudra donc les prendre en compte. - La performance de WPF est loin d'être exceptionnelle... Exit donc les délire d'animations qui demanderont un QuadCore minimum pour fonctionner correctement. Si dans l'ensemble la performance n'est pas mauvaise pour un système vectoriel, certaines fonctionnalités de WPF ne sont clairement utilisable qu'avec parcimonie : les bitmaps effects par exemple sont à réserver à de très petites surfaces
- XAML n'est pas suffisant ! Il est vain d'essayer de faire croire que XAML est une solution parfaite pour les designers. En effet, et malgré une étendue déjà plus qu'impressionnante, certaines choses ne sont pas réalisables en XAML ou ne le sont qu'avec un niveau de complexité bien plus grand qu'en C# (par exemple). N'hesitez donc pas à écrire du code lorsque cela est nécessaire et/ou plus simple !
- Le compilateur XAML a encore du chemin à parcourir. C'est peut-être le point le plus gênant lors de l'utilisation de WPF : il existe de nombreuses erreurs dues à des facteurs techniques (mauvais type d'objet, paramètres incorrects, etc...) qui ne sont pas détectées par le compilateur (alors qu'un compilateur comme celui de C# est capable de les repérer) et qui se traduisent donc par des exceptions plus ou moins compréhensibles (plutôt moins d'ailleurs...) lors de l'exécution. Il n'y a malheureusement pas de palliatif à ce problème mis à part un : prenez votre mal en patience.
|
- 20décembre 2007
-
Il y a quelques temps, j'ai évoqué des projets WPF/Silverlight sur lesquels je travaillait... En voici quelques screenshots, histoire que vous puissiez avoir une idée du rendu : - d'abord un outil de visualisation de statistiques, récupérant ses données soit depuis des rapports sous SqlServer Reporting Service soit - et c'est le but principal recherché - depuis les vues statistiques de la gestion commerciale d'un client/partenaire.
Le concept-art réalisé sous CorelDraw - parce que je suis un fan de ce produit - avec le tag "beta" histoire de faire un peu Desktop 2.0 :)...
...et sa réalisation ou plutôt l'état actuel de sa réalisation puisqu'il reste encore quelques modifications à apporter.
- Je travaille aussi actuellement à la ré-écriture de certains modules de la Gestion Commerciale précédemment évoquée (les deux screenshots sont réalisés sur la même partie de l'application, le suivi des clients) :
L'un des grands challenge lorsque l'on écrit ce type d'application est d'arriver à innover - et à rendre une application visuellement plus agréable - sans pour autant changer les habitudes de travail ni même ralentir celui-ci. Vous remarquerez probablement dans ces screenshots un petit emprunt à Zune 2.0 (le système de tri de la liste), mais il est plus que probable que celui-ci soit remplacé par les beaucoup-plus-classiques entêtes de colonnes pour la version finale. - Je ne reviens pas vraiment dessus, puisque j'en ai déjà parlé, mais, pour le plaisir (en tout cas pour le mien), voici un petit screenshots de l'application kiosque réalisée en silverlight pour un client :
PS : oui, je sais, ca fait beaucoup de orange & noir, mais ce ne sont que des coïncidences : ce n'est pas moi qui ai choisi les thèmes de couleurs... Mots clés Technorati : WPF, Application LOB
|