We have a multipage FlowDocument report that we are developing in WPF that uses charts. When we view the FlowDocument we can see the charts, however when we print the flowdocument the charts do not show on the printed material (we tried printing to different printers including pdf documents, xps document, actual printed paper).
We have found that, if we manually page through the FlowDocument (look at each page) and then print, the charts show in the printed material. It's almost as if the charts need to be viewed or displayed before they can be printed.
I would like to get to the point where I do not need to view the FlowDocument and just print the report in batch.
As for printing .... here is the code that I'm using to print the FlowDocument
PrintDialog printDialog = new PrintDialog();
if (printDialog.ShowDialog() == true)
{
FlowDocument mainFlow = m.mainFlow;
// Save all the existing settings.
double pageHeight = mainFlow.PageHeight;
double pageWidth = mainFlow.PageWidth;
// Make the FlowDocument page match the printed page.
mainFlow.PageHeight = printDialog.PrintableAreaHeight;
mainFlow.PageWidth = printDialog.PrintableAreaWidth;
// Reapply the old settings.
mainFlow.PageHeight = pageHeight;
mainFlow.PageWidth = pageWidth;
IDocumentPaginatorSource ps = mainFlow as IDocumentPaginatorSource;
printDialog.PrintDocument(ps.DocumentPaginator, "FlowDoc");
}
Hello,
Would you also post the XAML for a sample FlowDocument which contains an embedded xamChart? I'll be in a better position to reproduce this problem with it.
Thanks,
Until you can send some code from your project where I can see why the chart is not printing, I will share with you some of the things I was going to look at. If there is a reproducible bug with the xamChart not printing when it is part of a FlowDocument which has not yet been rendered to screen, then the work-around would be to have the FlowDocument rendered completely before printing. One way to do this is to use the XpsDocument APIs. With this you can write a WPF Visual to a XpsDocument with the XpsDocumentWriter. Then use the XpsDocumentWriter to print the document with a PrintContext. The great thing about using XPS to print is for when the user prints to XPS, they will get a text savvy XPS file.
Thanks
Hey Curtis - sorry for not posting back sooner. Thank you for your reply. I did try the Xps route and the charts did not render with that option either. As for posting the Xaml, that will take some effort as the Xaml report is huge and very confidential. I'm working on a simple example to post and hope to get back you today.
However, I have found a temporary workaround to the problem. After my FlowDocument is built (the pages are dynamic) I call the following methods.
// Add this page to the my main Report // BlockUIContainer bc = new BlockUIContainer(); bc.Child = accountInfoWindow; reportFlowDocument.mainFlowDocument.Blocks.Add(bc);}// Again, I'm not sure why I need to do this, but it seems to // make the charts show up when we print, ......ask Infragisics .// Causes the window to flash on the screenreportFlowDocument.Show();reportFlowDocument.Close();
// Send to the printer//
// Make the FlowDocument page match the printed page.mainFlow.PageHeight = printDialog.PrintableAreaHeight;mainFlow.PageWidth = printDialog.PrintableAreaWidth;
I think you are on to something.
If you would, please submit this as a bug. Also attach any code you have ready and refer to this forum webpage to the following online form:
http://devcenter.infragistics.com/Protected/SubmitSupportIssue.aspx
This seems to be a serious enough problem we are bound to fix it sooner than later.
Thank you,
Here it is two years later - and we're seeing the same problem.
Has there been a solution to this issue and if not is there one planned?
Hi,
You are seeing the same problem with version 2010.3?
If you would be willing to create a small sample project that illustrates the problem, I will submit a bug report for you and see what I can do to find a work-around solution for you!
Sincerely,
I'm attempting to batch-print UserControls. Essentially, each user control represents a report in our product. The problem I'm running in to is that each report won't print the XamChart or XamDataGrid unless the chart/grid has been displayed on the screen.
It appears as though there is some painting mechanism in the control that won't actually display the chart until it is forced on to the screen. If I host each user control in a form, briefly show/close the form, THEN print, everything displays properly. But if I don't display the control prior to printing, then the charts and grids are completely blank in the printed document.
I have tried this with several user controls, and the only ones that give me grief are those hosting an infragistics component (in this case, XamChart and XamDataGrid).
I have noticed similar behaviour reported in other posts (such as http://forums.infragistics.com/forums/p/7357/30278.aspx#30278 and http://news.infragistics.com/forums/p/7357/30431.aspx#30431). One person mentions that they have to display the item on the screen first before printing, the other states that because the first page shows up in the print preview, it prints properly, but the charts on the subsequent pages don’t print. Note that I am printing to XPS, not to a printer.
Attached is some sample code that reproduces the issue. The command line project prints the reports. The UI project is for demonstration purposes, showing that the user control does in fact have a chart in it.
Here is a breakdown of the output:
1) Using the native XpsDocument class, try printing the user control without showing it. (FAIL)
2) Using the native XpsDocument class, show a dialog with the user control in it, THEN print it. (PASS)
3) Using the Infragistics Report class, try printing the user control without showing it. (FAIL)
4) Using the Infragistics Report class, show a dialog with the user control in it, THEN print it. (PASS)
Note that I only included the Infragistics reporting classes to prove that the issue is not in the native XpsDocument classes, and exists in the chart itself.
I have duplicated the problem using the sample code with both 2010.3 by itself and with the SR applied.
Wasn't sure how to add the code the post, so I tried inserting a ZIP file with the code as a media file. Hope this works okay.
Paul,
I'm referring to the next availalable service release.
http://ko.infragistics.com/support/service-releases.aspx#ServiceReleases
-Graham
I have not seen a recent service release and I have an ongoing support case for this problem. I have not been notified that there is a fix available.
Which specific service release includes the fix and where can we download it from?
Thanks ... Paul
This bug is resolved in the latest service release, but when you are doing measure/arrange before printing you must also call UpdateLayout to make sure that the layout has been synchronously updated, or there may be pending work to make the chart presentable.
A workaround that might help you in the meantime is to attach control to the live tree and perform measure, arrange, and then updatelayout, and then detach the chart. I don't believe you have to let the chart actually display to get this to work, it should be enough if the chart's loaded event fires.
Let me know if this helps.
I am interested in a solution to this problem as well.
Bug number is 60336, I will get back to you if I can find any work around. Unfortunately the error that was introduced before the service release may be more difficult to work around than the original problem was.