2010-10-14 14 views
1

Nous utilisons actuellement WPF pour créer un document de facturation de plusieurs pages, pour ensuite être imprimé/exporté via XPS.WPF Impression - Facture multipage via Flowdocument, Paginator et FixedDocument

La route que nous avons empruntée pour y parvenir consiste à créer un UserControl contenant un ListBox standard, affichant les lignes Invoice, qui est ensuite inclus dans un FlowDocument à l'intérieur des balises BlockUIContainer.

Lorsque ce FlowDocument est placé à l'intérieur de balises FlowDocumentScrollViewer dans une fenêtre, il fonctionne parfaitement, avec le contenu de la commande UserControl correctement affiché. Cependant, lorsque nous essayons de créer le même FlowDocument dans le code, il échoue avec un "'Impossible de créer un type inconnu' {clr-namespace: FOO} FooUserControl" XamlParseException. Le FlowDocument peut être créé par programmation si le UserControl est supprimé.

C'est le FlowDocument XAML:

<FlowDocument xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation" 
      xmlns:local="clr-namespace:MARS" 
      ColumnWidth="400" FontSize="14" FontFamily="Georgia"> 
<Paragraph> 
    Blah 
</Paragraph> 

<BlockUIContainer> 
    <local:printTestUserControl></local:printTestUserControl> 
</BlockUIContainer> 

Et ceci est le code que nous utilisons pour créer dans le code:

FileStream xamlFile = new FileStream("printTestFlowDoc.xaml", FileMode.Open, FileAccess.Read);    
FlowDocument content = (FlowDocument)XamlReader.Load(xamlFile); 
flowDocScrollViewer.Document = content; 
xamlFile.Close(); 

La raison pour laquelle nous créons la FlowDocument dans le code est alors d'utiliser un objet Paginator pour le découper en une série de FixedDocuments pour ensuite imprimer/exporter vers XPS, dont nous n'avons pas encore essayé, mais d'après ce que j'ai lu jusqu'à présent, il semble que ce soit est une méthode réalisable pour l'impression de documents de plusieurs pages dans WPF (où le document aura un en-tête sur la première page, un pied de totaux sur la dernière, et x pages de lignes entre les deux).

Tout conseil sur cette question, ou d'autres méthodes pour le faire serait le bienvenu.

Voici quelques liens pour lesquels nous avons ramassé des informations, mais malheureusement pas assez! (je vais inclure les autres liens dans les commentaires, comme StackOverflow ne me fait pas confiance avec plus d'un lien à l'heure actuelle!)

See the section "Dynamically Creating a FlowDocument, Data Binding and Printing It" Scott Hanselmann semblait avoir le même problème que nous avons fait, mais en ajoutant la ligne

Dispatcher.CurrentDispatcher.Invoke(DispatcherPriority.SystemIdle, new DispatcherOperationCallback(delegate { return null; }), null); 

n'a pas obtenu notre FlowDocument pour charger, mais il ne lie à TextBlocks dans son FlowDocument, plutôt que d'inclure un UserControl.

Merci beaucoup d'avoir lu jusqu'ici! et pour toute aide que n'importe qui peut offrir.

+0

Feng Yuan - Convertir le document de flux XAML au format XPS avec style (plusieurs pages, taille de la page, en-tête, marge) http://blogs.msdn.com/b/fyuan/archive/2007/03/10/convert- xaml-flow-document-à-xps-avec-style-multiple-page-page-size-header-margin.aspx – Ted

+1

Dernière partie de la série d'impression FlowDocument de RoeCode http://roecode.wordpress.com/2008/05/28/using-flowdocuments-xaml-à-print-xps-documents-partie-6/ – Ted

+0

MSDN - Comment: charger un fichier XAML dans un FlowDocumentScrollViewer http://msdn.microsoft.com/fr-fr/ bibliothèque/ms753299.aspx – Ted

Répondre

0

Désolé d'avoir mis du temps à mettre de l'ordre dans cette question, mais nous venons tout juste de terminer ce projet, et je vais maintenant en ranger tous les détails. Il s'est avéré que la méthode flowdocument/XPS était une façon complètement erronée d'aborder cette tâche, et en fait les rapports RDLC intégrés nous ont permis d'obtenir tout ce dont nous avions besoin pour nos documents de facturation, d'une manière relativement directe . Le principal avantage de ceci était que nous étions capables de rapporter sur des instances en mémoire de nos objets de modèle d'affaires, plutôt que d'avoir à utiliser les données recherchées d'un db, via les procs stockés appelés de cristal, que le système précédent compté sur. L'éditeur de fichiers de rapports dans VS était simple à comprendre, même s'il était parfois un peu irritant lors de la création de rapports complexes.

Espérons que cela puisse être utile aux personnes considérant leurs options en matière de reporting à partir d'applications WPF.