Dot.Blog

C#, XAML, Xamarin, UWP/Android/iOS

Imprimer avec Silverlight 4

[new:20/11/2010]Silverlight 4 a introduit un mécanisme permettant d’invoquer l’impression côté client même en mode Web simple (par opposition au mode Out-of-Browser). Comment en tirer partie ?

Print Screen

L’utilisation la plus basique qu’on peut envisager est celle d’un print screen (copie d’écran), ce n’est pas fantastique mais c’est déjà pas mal puisque cela n’existait pas avant SL 4 !

[silverlight:source=/SLSamples/SLPrint/SL4PrintDemo.xap;width=400;height=300]

Regardez l’exemple ci-dessus. Si vous cliquez sur le bouton “Imprimer” vous verrez apparaitre le dialogue d’impression classique de Windows (ou du Mac) vous permettant de sélectionner une imprimante. Pour les tests, utilisez une imprimante PDF ou XPS, cela évite de consommer bêtement du papier…

Vous avez forcément remarqué la case à cocher “Page entière” et vous avez peut-être même déjà joué avec. Sinon, testez de nouveau une impression mais en décochant la case.

Dans le premier cas toute la page Silverlight est imprimée, dans l’autre seul le cadre central l’est (la grande différence est que le bouton Imprimer n’apparait plus).

Comment ça marche ?

Prenez une application Silverlight 4, placez-y un bouton pour imprimer et voici à quoi doit ressembler le code pour effectuer un Print Screen comme dans l’exemple ci-dessus :

 

   1: private void btnPrint_Click(object sender, RoutedEventArgs e)
   2:         {
   3:             var doc = new PrintDocument();
   4:             var wholePage = cbWholePage.IsChecked;
   5:  
   6:             doc.PrintPage += (s, ee) => ee.PageVisual = 
   7:                  (wholePage ?? false) ? (UIElement) LayoutRoot : centralDoc;
   8:  
   9:             doc.Print("Silverlight 4 Screen to Paper demo");
  10:         }

Comme on le remarque c’est court… Mais ça ne fait pas grand chose non plus !

Tout tient à la classe PrintDocument dont on créé une instance et à qui on explique ce qu’il faut imprimer en programmant son évènement PrintPage.

Dans l’exemple ci-dessus cette programmation s’effectue vie une expression Lambda qui s’occupe de passer soit l’objet LayoutRoot (page entière), soit le canvas central (page partielle). A qui est-ce passé ? A la propriété PageVisual qui provient des arguments de l’évènement.

Enfin, on appelle la méthode Print à laquelle on peut passer un texte qui sera visible dans le gestionnaire d’impression (certains pilotes d’imprimante récupèrent aussi ce texte pour créer le nom de fichier : pilote PDF par exemple).

C’est tout ?

Out-of-the-box comme on dit, oui, c’est après tout… Bien entendu on peut ruser un peu sur les marges, on peut imprimer quelque chose de plus long que la simple page en cours. Mais le principe est là : on créé un document d’impression, on se branche sur son évènement d’impression et là on fourni un arbre visuel à imprimer. L’appel à Print déclenche le processus.

C’est rustique, tout en bitmap (donc ramivore, et cpuvore), je dirais même que c’est moyenâgeux, n’ayons pas peur des mots.

Disons que c’est comme pour le son ou les bitmaps, MS nous livre ici les prémices d’un début de ce qui pourrait devenir une voie intéressante avec 1 an de travail en plus …

Mais ne boudons pas l’arrivée des impressions, même simplistes, dans Silverlight. Cela permet de s’affranchir de solutions plus lourdes (serveurs d’impressions) et des round-trips entre le client et le serveur. Là tout est fabriqué sur place, tout chaud prêt à consommer, sur PC et sur Mac.

Des Extensions ?

Il est vrai qu’on est très loin des besoins d’une application de gestion, pourtant domaine qui semble être le créneau porteur de Silverlight (Flash est mieux fichu pour le son et les graphiques et fait parfaitement des pubs ou des sites sapin de Noël). Petite incohérence dans le ciblage ou tout simplement problème de timing pour l’équipe de SL ? Je préfère envisager la seconde solution que la première qui serait plus grave de conséquences.

C’est donc avec optimisme que je regarde l’avenir, et j’espère, comme pour le WriteableBitmap, que l’équipe de SL saura nous fournir prochainement des couches un peu plus haut niveau, donc utilisables.

Un générateur d’état minimaliste

En attendant, un projet s’est ouvert sur CodePlex : http://silverlightreporting.codeplex.com/

Ce mini projet est vraiment un balbutiement de générateur d’état, mais une fois encore ne boudons pas cette offrande (c’est gratuit et en code source) car elle peut fort bien servir de point de départ à quelque chose de plus ambitieux. (ne pas confondre avec un projet de nom proche qui n’a jamais décollé).

Ici on peut définir entête et pied de page, il y a une gestion de la pagination et les “bandes” peuvent avoir une talle variable. voici un exemple de sortie :

pmb_sample_report.jpg

Conclusion

Niveau reporting, local j’entends, il y a tout à inventer ! Si vous avez une bonne idée vous deviendrez peut-être riche car c’est vraiment un module qui manque pour tout ce qui est application de gestion.

Le petit projet indiqué plus haut ne peut pas réellement servir de base sérieuse car ce qui est imprimé n’est qu’un arbre visuel qui occupe déjà de la place en mémoire et qui, de plus, est transformé en bitmap. Autant dire que pour 2 à 5 pages ça marche, mais qu’il ne semble guère possible de pousser le concept pour créer un véritable générateur d’état.

Il existe des serveurs d’impressions vendus comme des composants Silverlight. Ne vous laissez pas avoir, il s’agit pour l’essentiel de vieilles solutions pour Java ou ASP.NET, uniquement en mode serveur, réadaptées avec plus ou moins de bonheur à Silverlight. Toutes les solutions que j’ai pu tester obligeaient un téléchargement plus lourd qu’une bonne application à elle seule. Inutilisable ou presque.

Bref, pas de pessimisme, mais du réalisme : Silverlight nous laisse sur notre faim et l’unique petit projet un peu évolué ne semble pas pouvoir aller bien plus loin. Il faudra certainement encore un peu de temps pour que nous voyions apparaitre de vraies solutions d’impression locales sous Silverlight.

Impression, gestion correcte des sons, 3D, héritable visuel des contrôles, gestion des bitmaps évoluée… Les petits gars de l’équipe SL on du pain sur la planche pour SL 5 ! Souhaitons-leur bon courage et, surtout, qu’ils implémentent enfin ces modules indispensables au lieu de se perdre dans le mode out-of-browser, qui, pour ma part et celle de mes clients, n’a aucun intérêt (du Web qu’on doit installer sur une machine, ce n’est plus du Web).

blog comments powered by Disqus