I'm looking for a reporting/printing solution that does not involve RDLC/SSRS. I'd like to use the DocumentViewer, which I know supports XPS. I have found plenty of examples that use Visual to XPS but I haven't found many examples where I can take an existing WPF page, with various controls like labels, listboxes, grids, etc and create that into an XPS document. Is there a code example out there that takes an entire XAML page and creates XPS?
It's not trivial, the basic problem here is that XPS represent fixed pages. An existing WPF page does not necessarily translate to pages on a document. How will your report be split if it cannot fit the page? This information is needed.
What you can do is to create the report as a FlowDocument (see http://msdn.microsoft.com/en-us/library/aa970909.aspx). This will give the .NET framework enough info on how to paginate your report such that when you do this:
FlowDocument flowDocument;
// load, populate your flowDocument here
XpsDocument xpsDocument = new XpsDocument("filename.xps", FileAccess.ReadWrite);
XpsDocumentWriter writer = XpsDocument.CreateXpsDocumentWriter(xpsDocument);
writer.Write(((IDocumentPaginatorSource)flowDocument).DocumentPaginator);
it works. (Code lifted from Pro WPF in C# Book).
Usually your WPF page has a root UI element, say Grid. As Grid is a specific type of Visual(please vide "Inheritance Hierarchy" part #http://msdn.microsoft.com/en-us/library/system.windows.controls.grid.aspx for more details), you just need to write that root Grid element like other visuals into XPS. And then all embedded controls will be automatically written into XPS document.
Related
I like DocumentViewer for display of an XPS document in a WPF application. But I also need to redact the XPS document. I have found stand alone applications (.exe) for redacting XPS. What I need is a WPF control for view and redaction of XPS. Or an extension to DocumentViewer for redaction. The redaction must actually remove the data and not just hide it (this is for a litigation application). Does anyone know of way to view and redact XPS in WPF?
With a custom DocumentPaginator you can control how each element of the document is printed.
If you can identify the text ranges you want to redact then you can replace the glyphs with a black visual and not add the text range to the final document.
...
Hmm. As I typed the above it really sounds a bit complex when there are simpler solutions.
Read the XPS document, convert it to a FlowDocument.
Allow the user to select text ranges to redact.
Replace* the selected text with the ████████████████ character (U+2588, Full Block).
Convert the document back to XPS and print.
* As you replaced the original text, it will not be available in copy/paste actions.
There are plenty of tutorials on how to each the above steps separately. Let me know if you need any additional help.
If my mind don't lie, you can't edit XPS directly, but you can create WPF representation of document, edit it and print to new XPS file.
I'm trying to use the Silverlight RichTextEditor in our website. Now we'd like to translate the content in richtextbox into HTML code to save and load.
However, as we know, the richtextbox control does not support the UIelements output. When we insert an image in the richtextbox, the richtextbox would use a inlineUIcontainer to show this image. The property Richtextbox.xaml does not include any information about the image. It just shows the code like "".
Does anyone have this problem and handle it before?
RichTextBox.Xaml strips out a lot of things, as a security safeguard (more for the setter than the getter as far as I recall, but it does it both ways so there are no round-trip surpises).
I recommend looking at the XAML Serializer written by David Poll on his blog (here: http://www.davidpoll.com/2010/07/25/to-xaml-with-love-an-experiment-with-xaml-serialization-in-silverlight/ ) as it can serialize RTB awesomely well (it's in fact one of the test cases he shows). David was a PM on the Silverlight XAML Parser in SL4, so he knows an awful lot about XAML.
But be careful when setting the .Xaml property, as you could mistakenly end up spinning up InlineUIContainer elements which load resources into your AppDomain that you don't want in there, so make sure you control the inputs or you strip them yourself very carefully.
I have a RichTextBox and need to serialize its content to my database purely for storage purposes. It would appear that I have a choice between serializing as XAML or as RTF, and am wondering if there are any advantages to serializing to XAML over RTF, which I would consider as more "standard".
In particular, am I losing any capability by serializing to RTF instead of XAML? I understand XAML supports custom classes inside the FlowDocument, but I'm not currently using any custom classes (though the potential for extensibility might be enough reason to use XAML).
Update: I ended up going with RTF because of its support for text-encoded embedded images. XAML doesn't seem to include image data in its encoding, and XamlPackage encodes to binary, so RTF just works better for me. So far I haven't noticed any lack in capability.
If all your users are doing is typing in the RichTextBox and doing character formatting, RTF is as good as XAML. However there are many FlowDocument capabilities you may expose in your UI that are not convertible to RTF.
Here are some examples of FlowDocument (and RichTextBox) features that are not expressable in RTF or are implemented differently:
A Block can have an arbitrary BorderBrush, including gradient brushes with stops, VisualBrush
A Section has the HasTrailingParagraphBreakOnPaste property
Floater / ClearFloaters is implemented differently
Hyphenation can be enabled/disabled per block, not just per paragraph
WPF Styles and ResourceDictionaries can be included in the Resources property
Arbitrary WPF UI such as bound CheckBoxes, etc, can be embedded inside the RichTextBox and can be cut-and-pasted from other windows.
For example, suppose you want to allow users to drag or cut/paste in a "current date/time" field into your RichTextBox that would always show the current date and time. This could be done by adding a second read-only RichTextBox that has the InlineUIContainer and the already-bound control. This even works when cutting and pasting from other applications and does not require custom controls.
Another consideration is that the code to convert between FlowDocument and RTF is relatively complex so it may have lower performance than going with XAML. Of course loose XAML doesn't include images and such - for that you need to use XamlPackage. I store my XamlPackage in the database as a byte[], but you can also choose to Base64 encode it for storage as a string.
The bottom line is that it really depends on whether you want the user to be able to use features not available in RTF. Even if your application doesn't include tools to generate FlowDocuments that use these features, it is possible to cut-and-paste them from other applications.
Be aware that in Wpf RichTextBox's method called TextRange.Save has a bug whereby it loses any end of line terminator. Microsoft will not fix.
https://connect.microsoft.com/WPF/feedback/ViewFeedback.aspx?FeedbackID=478640&wa=wsignin1.0#tabs
I'm porting an application from WPF to Silverlight and was saddened to read of the lack of FlowDocument support.
What is the best way in Silverlight then to display text with markup?
I just need the basics, e.g.
bold
italic
hyperlink
colors
font sizes
Added:
I don't mean a RichTextBox (as in the Vectorlight demo) but a way to format text on the application surface itself, like I can do with FlowDocument in WPF:
(source: deviantsart.com)
In Silverlight 3 Vectorlight's Free RichTextBox can do a pretty good job of what you need using HTML.
In Silverlight 4 you have the option of using the RichTextBox to represent your content.
If you do get something like that up and running, msg me and maybe we can collaborate on bringing my "BindableFlowDocument" into the world of Silverlight. ;)
edit - wow, I must have gotten mixed up - my original answer was way off
Inline with the comments of SL4 RC's RichTextBox (RichTextArea, circa SL4 Beta), and with your example of importing marked up text, the SL4 RC RichTextBox will allow for an import of XAML formatted text - like string richText = MyRichContent.Xaml; on this page: http://timheuer.com/blog/#richtextbox. Details are listed here: http://msdn.microsoft.com/en-us/library/system.windows.controls.richtextbox.xaml(VS.96).aspx.
Just use the RichTextBox in Silverlight 4.0
What would be a good approach to display and edit large amount of unformatted text (just like notepade does) using WPF? Loading a big string into a TextBox makes the UI unresponsive. The overall performance is not nearly comparable with TextBox Controls of previous Microsoft UI Frameworks.
What options do I have to solve this problem. I do not want to block the UI thread while the text control loads the text. Also I might need some sort of "virtualization" because it might not be a good idea to load the whole text into the control (I guess that 20MB of text would create a lot of glyphs even if they are not visible). It seems that TextBox doesn't even have an AppenText() Method anymore so I don't even have a way to control asynchronous loading of the text.
Isn't this a common problem? It seems that WPF does not provide anything for this out of the box. Why is this so?
AvalonEdit, the text editor in SharpDevelop, was written completely from scratch in WPF and is optimized for large amounts of text. It doesn't support rich text (although it does support syntax highlighting and other cool features such as folding). I think this might fit your bill perfectly.
Here is an article on the editor written by the developer:
http://www.codeproject.com/KB/edit/AvalonEdit.aspx
I am not sure if this helps, but have you tried using FlowDocumentPageViewer and FlowDocumentReader?
It also has very good annotations support and looks ideal for loading documents in text format.
The problem is that the TextBox is a single container element. List controls, such as ListBox virtualize very well because of container recycling. There really isn't anything simple that you can do to speed up the TextBox.
But the TextBox control does have an AppendText() method:
TextBox tb = new TextBox();
tb.AppendText("Hello");
So yes, you can use this to dynamicly add some text just like you mentioned.
You can just use a textbox with a style that gives the user more room to view the text. There are probably more advanced controls from Telerik and others but if you don't require editing options that should suffice.
You could always mix and match technologies: you could drop a WinForms TextBox onto a WPF parent. You lose things like styling, opacity, animation, transforms, etc., but if all that matters is editing text, the WinForms TextBox does that just fine.
Have you tried the WPF RichTextBox? You'll definitely want to read up on the FlowDocument information if you go this route.
You could use FlowDocument, but this doesn't work out of the box to bind to the Document property of a FlowDocument in MVVM.
Another solution is using FlowDocumentScrollViewer and bind to its Document property.
(or you could even use a FlowDocumentReader and bind its Document property, similar to the FlowDocumentScrollViewer. This gives you a different UI.)
The View:
<FlowDocumentScrollViewer Document="{Binding FlowDocument, Mode=OneWay}" />
The ViewModel:
FlowDocument fd = new FlowDocument();
Paragraph p = new Paragraph();
Run r = new Run();
r.Text = "large text";
p.Inlines.Add(r);
fd.Blocks.Add(p);
FlowDocument = fd;
private FlowDocument _FlowDocument;
public FlowDocument FlowDocument
{
get{ return _FlowDocument; }
set
{
_FlowDocument = value;
NotifyOfPropertyChange(nameof(FlowDocument));
}
}
see also this for extra performance tips: https://learn.microsoft.com/en-us/dotnet/framework/wpf/advanced/optimizing-performance-text#flowdocument-textblock-and-label-controls
How about trying something like this:
Keep the whole string in memory but show only a 'slice' of it in the textbox. Size of the that sliced string would be dynamically calculated depending on the size of textbox, font size etc.
Of course this involves a lot of not trivial code for proper displaying, synchronizing and so on, but it seems the way to go.
One other option is to use Scintilla.NET. It has the best performance for large amounts of texts I have seen so far. Loading large files is almost instantaneous. Even though it is a WinForms control, you can embed it into your WPF window with WindowsFormsHost container. There is syntax highlighting and some other features that should be more than enough for displaying unformatted text. From the downsides - since this is a WinForms control, it overlaps other WPF UI elements. Also there may be issues with resizing the control. Unfortunately, I don't see any better option than using a non-WPF control instead of the default TextBox and RichTextBox.