Quelle est la meilleure approche pour l'impression/création de rapports à partir de WPF?

J'ai un projet à venir qui devront être en mesure d'imprimer des rapports à partir de ses données. Ce sera en fonction de WPF, et je me demandais où aller.

Je sais que WPF présente sa propre technologie d'impression (basé sur XPS) qui semble assez facile à utiliser. Toutefois, une partie de moi se demande si ce serait plus facile d'utiliser le contrôle ReportViewer et de l'intégrer dans un Windows Forms de contrôle d'hôte, depuis que donnera aux utilisateurs la possibilité d'exporter vers une variété de formats, ainsi que de l'impression.

Quelqu'un avait une expérience avec l'impression/création de rapports à partir de WPF? La direction recommanderiez-vous?

  • SimpleWPFReporting vous donne la possibilité de créer un rapport avec la pleine puissance de WPF XAML. SimpleWPFReporting prendra soin de les exporter au format PDF ou de l'imprimer.
InformationsquelleAutor Matt Hamilton | 2008-10-07
  1. 25

    Nous avons eu ce même problème, et finit par les utiliser RDLC/ReportViewer pour l'instant. Il n'y a pas de WPF natif outil de reporting (que je connais) et RDLC est assez simple à utiliser, et est gratuit. La gestion d'exécution car il est de petite taille (environ 2 mo), mais vous devez vous rappeler de le distribuer comme il n'est pas de la partie .NET Framework.

    InformationsquelleAutor Bob King
  2. 42

    Limites de la RDL

    J'y suis allé avec RDLC/ReportViewer pour l'impression avec WPF, mais il lui est très limitant. Certaines des limites que j'ai trouvées étaient:

    • RDL ne peut créer que le plus ennuyeux de rapports
    • Il était beaucoup plus de travail pour créer un rapport en utilisant RDL que dans droit en WPF: Les outils de conception sont très primitives par rapport à Expression Blend et de la RDL ne traite que des tableaux
    • Je n'ai pas eu la possibilité d'utiliser ControlTemplates, DataTemplates, Styles, etc
    • Mon champs de rapport et les colonnes ne pouvaient effectivement redimensionner et réorganiser selon la taille des données
    • Graphiques ont dû être importés que des images - il n'a pas pu être établis ou modifiés en tant que vecteurs
    • Positionnement des éléments requis code-behind plutôt que de la liaison de données
    • Manque de transformations
    • Très primitive de la liaison de données

    Impression directement à partir de WPF est très facile

    En raison de ces limitations, j'ai regardé dans la création de rapports à l'aide de pure WPF et a découvert qu'il était vraiment tout à fait banale. WPF permet de mettre en oeuvre votre propre DocumentPaginator sous-classe qui peuvent générer des pages.

    J'ai développé un simple DocumentPaginator sous-classe qui prend tout Visuel, analyse visuelle de l'arbre, et masque les éléments sélectionnés à la création de chaque page.

    DocumentPaginator détails

    Voici ce que ma DocumentPaginator sous-classe ne lors de l'initialisation (appelée lors de la première propriété pagecount est rapportée, ou lors de la première GetPage() call):

    1. Scans de l'arbre visuel et rend une carte de tous défiler les panneaux à l'intérieur de ItemsControls
    2. En commençant par l'extérieur, rend éléments dans le ItemsControls invisible de la dernière à la première jusqu'à ce que le Visuel tient sur une seule page, sans avoir à faire défiler. Si l'extérieur ne peut pas être assez réduit, réduit les panneaux intérieurs jusqu'à ce qu'il réussisse ou n'a qu'un seul élément à chaque niveau. Enregistrement de l'ensemble des éléments visibles que la première page.
    3. Cacher le plus bas niveau, les éléments qui ont déjà été indiqué sur la première page, puis effectuer par la suite des éléments visibles jusqu'à ce qu'ils ne peuvent plus tenir sur la page. Enregistrement de tous, mais le dernier élément ajouté à la deuxième page.
    4. Répétez le processus pour toutes les pages, en stockant le résultat dans une structure de données.

    Mon DocumentPaginator de GetPage méthode est comme suit:

    1. Rechercher le numéro de page dans la structure de données générées lors de l'initialisation
    2. Masquer et afficher des éléments dans l'arborescence visuelle, comme indiqué dans la structure de données
    3. Ensemble PageNumber et NumberOfPages attaché propriétés, ce rapport peut afficher les numéros de page
    4. Rincer le Répartiteur (Dispatcher.BeginInvoke(DispatcherPriority.ApplicationIdle, new Action(() => {} ));) pour obtenir de rendu en arrière-plan des tâches à remplir
    5. Créer un Rectangle de la taille de la page dont VisualBrush est le visuel imprimé
    6. Mesure, d'Organiser et d'UpdateLayout le rectangle, puis le retourner

    Ce qui s'est avéré être tout à fait simple code, et m'a permis de transformer pratiquement tout ce que j'ai pu créer avec WPF en pages et l'imprimer.

    Des rapports supplémentaires de soutien

    Maintenant que mon paginator est au travail, je n'ai plus à vous inquiéter beaucoup de savoir si je suis la création de mon WPF contenu de l'écran ou sur papier. En fait, souvent de l'INTERFACE utilisateur que je construis pour la saisie des données et l'édition fonctionne aussi très bien pour l'impression.

    À partir de là, j'ai ajouté une simple barre d'outils et un peu de code derrière, résultant en un véritable système de déclaration construit autour de WPF qui était beaucoup plus performant que RDL. Mon code de signalement peut exporter des fichiers, d'impression à l'imprimante, copier/coller des images de page, et couper/coller des données pour Excel. Je peux aussi passer tout de mon INTERFACE utilisateur pour l'impression d'une vue" avec un clic sur une case à cocher pour voir ce qu'il va ressembler si elles sont imprimées. Tout cela, en quelques centaines de lignes de C# et XAML!

    À ce point, je pense que la seule fonction de RDL a que mon code de signalement ne pas avoir est la capacité à générer de la mise en forme de feuille de calcul Excel. Je peux voir comment cela pourrait être fait, mais jusqu'à présent il n'y a pas besoin de couper et coller les données a été suffisant.

    De mon expérience, ma recommandation serait d'écrire un paginator, puis commencer à utiliser WPF pour créer vos rapports.

    • Très intéressante que je pense de l'abandon de la RDLC. Avez-vous publié du code de votre document paginator?
    • Pas en ce moment.
    • Pourriez-vous développer sur tout cela? Peut-être avec un code court/xaml exemples?
    • Trouvé ceci: codeproject.com/Articles/138233/...
    • Cette solution de la vôtre est parfaitement candidat pour OpenSourcing, qui pourrait être quelque chose qui permettrait de ramener les avantages pour vous-même et votre entreprise, au prix d'un peu plus de travail initial, nous le savons...)
    • "Impression directement à partir de WPF est très facile". Est-il vraiment? J'ai déjà mis beaucoup de temps et d'efforts dans la mise en œuvre de cette et la pagination d'un lié aux données de grille de données n'est pas facile, par un effort de l'imagination. J'ai peur que le diable est dans les détails et jusqu'à ce que je vois certains, cette réponse n'est pas très utile.
    • aimeriez-vous partager votre code (juste la partie avec la visibilité serait suffisant)? J'ai une prime sur un Question où votre réponse serait très bien
    • Le voici, le voilà, @RayBurns. Voyons un dépôt github afin que nous puissions contribuer à cette incroyable sonorité de mise en œuvre.
    • Intéressant, mais il a été de 6 ans à partir de la réponse, ne pouvait pas trouver tout class que m'aider à convertir xaml à la page. Aussi, il n'y a pas d'autre moyen 🙁
    • J'ai adopté une approche similaire à cela, mais au lieu de déconner avec le visuel de l'arbre-je utiliser un modèle de vue qui a Items et CurrentPageItems où les éléments sont ajoutés jusqu'à ce que la page débordements puis supprime un élément. Le modèle de vue de l'approche vous permet de faire des choses comme obtenir la page des sous-totaux très facilement et peut avoir des propriétés supplémentaires comme IsLastPage que vous pouvez utiliser pour basculer d'un pied de page et qui fait qu'il est très puissant. Je vais probablement écrire quelques posts à ce sujet et après un peu de code dans le proche avenir, mais c'est l'approche générale je dirais si vous envisagez de faire ce

    InformationsquelleAutor Ray Burns
  3. 8

    Regarder http://wpfreports.codeplex.com/

    • j'ai trouvé un artikel sur nullskull ce qui explique étape par étape comment créer un WPF Moteur de Rapport en utilisant la même approche.
    InformationsquelleAutor Lukas Cenovsky
  4. 3

    Prendre un coup d'oeil à PdfReports. C'est un premier code de moteur de rapport, qui est construit sur le haut de la iTextSharp et EPPlus bibliothèques. Il est compatible avec les deux .NET 3.5+ applications Web et Windows.

    InformationsquelleAutor VahidN
  5. 3

    Comment sur Scryber? Il permet PDF des modèles de rapports pour être défini à l'aide xml et lié à des données au sein de votre application au moment de l'exécution. http://scryber.codeplex.com/

    InformationsquelleAutor LiamV
  6. 2

    D'élaborer sur les Rayons des Brûlures de la réponse, si vous êtes à la recherche d'un exemple de mise en œuvre, voir:
    Personnalisé, La Grille De Données Document Paginator

    Qui est un excellent point de départ.

    InformationsquelleAutor Alex Hope O'Connor
  7. 1

    J'ai reccently accompli la tâche de développer propre système de reporting, qui consistent essentiellement sur la conception de l'environnement et de gestionnaire de Source de données. La première tâche était de développer WYSWIG-comme la conception de l'environnement. J'ai fait cela à l'aide de GDI+, sans même se soucier de l'impression, comme il est sorti de l'impression/génération de l'aperçu avant impression a été plus facile que ce que j'attendais, En général, il ne prend que de dessiner tous les objets sur l'écran pour objet graphique d'impression de l'événement.

    Je pense que dans le cas de WPF, il serait similaire, de sorte que vous devriez vous inquiéter, c'est de vous présenter le rapport sur écran et l'impression serait seulement quelques lignes de code.

    InformationsquelleAutor MoreThanChaos
  8. 0

    Sans entrer dans un débat politique sur l'avenir de WPF, la meilleure option est d'envelopper le ReportViewer dans un Windows Forms de contrôle d'hôte.

    http://blog.pineywoodstech.com/index.php/2012/01/using-microsoft-reportviewer-with-wpf/

    InformationsquelleAutor Doug