I use PdfSharp/MigraDoc to create and view documents in an application.
I use the WPF version since I need the WPF documentviewer. Now I'd like to print the documents (which works from the DocumentViewer), but for some reason I only get empty pages when I try printing myself.
I use this code to print:
MigraDocPrintDocument printDocument = new MigraDocPrintDocument();
printDocument.Renderer = new DocumentRenderer(druck.GetDruck());
printDocument.Renderer.PrepareDocument();
printDocument.Print();
What do I need to do to print from WPF (from WinForms this worked nicely, but I need WPF for the DocumentViewer).
This is a known bug of MigraDoc 1.31: printing only works if you use the GDI+ build.
As a workaround you can try to use both versions - WPF build for the preview, GDI+ build for direct printing.
Related
I have below sample code for my wpf app.
I need to fill in text fields of form with strings.
Run('AutoItWpfTesting.exe')
WinWaitActive("Window1", "")
$hHwnd = WinGetHandle("Window1")
MsgBox(0, "Message", $hHwnd)
$returnVal1=ControlGetHandle ( "$hHwnd", "", "[NAME:txtVersion]")
$returnVal2=ControlSend($hHwnd,"","[NAME:txtVersion]","blahblah")
MsgBox(0, "Message", $returnVal2)
it returns 0 for $returnVal2 and Empty string for $returnValue1.
However this works fine for my sample winform application.
Any clues why this behaviour is..and Any tweaks available to get exact text-box to auto fill data for wpfa app.
WPF applications do not use Windows' controls and handles for the controls. You can see that by using Spy++. WPF Alternatives for Spy++
If you want to automate WPF applications you will need another tool or use the UI Automation API to build one.
My windows forms application hosts AvalonEdit (the composite WPF control in question) in one of its forms to cater to its text editing requirements. Here's the code I use:
WPFHost = gcnew ElementHost();
TextField = gcnew AvalonEdit::TextEditor();
WPFHost->Dock = DockStyle::Fill;
WPFHost->Child = TextField;
TextField->Options->AllowScrollBelowDocument = false;
TextField->Options->EnableEmailHyperlinks = false;
TextField->Options->EnableHyperlinks = true;
TextField->Options->RequireControlModifierForHyperlinkClick = true;
TextField->ShowLineNumbers = true;
ContainerControl->Controls->Add(WPFHost); // the container is a panel
The code compiles and executes fine, except for the scrollbars - http://dl.dropbox.com/u/2584752/avalonEditBug.png . Right clicking on what's left of the bar raises an ArgumentOutOfRange exception.
Strangely, I wasn't able to reproduce the issue when I tried hosting the control in a newly created sample project. 'mI using the latest build of the text editor and have all the requisite assemblies installed.
EDIT: Wrapping the editor in a usercontrol doesn't help either.
You say that the control works fine in a new/blank project but fails in the one you need makes me wonder about conflicts more than anything. In the project you're really wanting compared to the project it worked in what are the differences? .NET version? Referencing an assembly from a directory in one but out of the GAC in another?
It's hard to say that the control is messing up for you when you've got it working elsewhere, so the only thing I can suggest is just dive deep into the differences of the two projects.
Good luck.
This looks like a layout error to me. Maybe WPFHost measures the TextField unexpectedly.
I can suggest setting specific Width and Height on the TextField itself. If this fixes the problem you can adjust those as the size of the WPFHost control changes or try setting the MaxHeight/Width, sometimes they help and save some code for Width/Height updates.
try to create a WPF grid as a child of ElementHost, and place the editor inside that grid. On Other way, is to create an UserControl have the editor in that control and use the control inside your Winform app. Such approach helped me a couple of times.
I've implemented a workaround for the issue as mentioned in this thread [ Synchronizing a WPF ScrollViewer with a WinForms ScrollBar ].
I need to create some mini-windows, like the ones shown in the image bellow, in my winform main form.
It would be nice if they could be draggable, resizable, and, mainly, closable.
How can I approach this design? Has anybody already seen some control (with code available) implementing something similar?
alt text http://img716.imageshack.us/img716/5765/imagea.png
A normal Form works fine for this. Set its FormBorderStyle to either FixedToolWindow or SizableToolWindow as desired.
If you want to keep your floating windows inside your main window, use MDI (Multiple Document Interface). Here is a tutorial (Google can find you many more).
Have you tried just setting the FormBorderStyle property to SizeableToolWindow?
Is that what you're after?
You can create them as resizable and draggable custom controls.
You could use my example at:
http://hourlyapps.blogspot.com/2008/07/resizable-and-movable-controls-c-net.html
I need to host WPF control inside IE, therefore I'm trying to implement IHTMLPainter and IElementBehavior interfaces. I'd like to build my custom behavior and use it inside IE, but the problem is how to draw WPF control by just having IntPtr hdc parameter.
Probably I can get Drawing.Graphics by the following code:
Graphics.FromHdc(hdc);
But I'm not sure that this is the best way. Please advise
I'm assuming you want to be able to make use of the advanced features of WPF within a MSHTML context. In that case, Graphics.FromHdc(hdc); will not do the trick for you. The resulting Graphics object will have no way to receive WPF content because WPF uses a retained-mode system and its MILCore rendering engine uses Direct3D not GDI+.
I'll give you one sure way to use WPF features inside a IHTMLPainter, plus pointers to another way that would likely be faster if you can get it to work.
Bitmap copying solution
An easy solution is to simply copy the background provided by MSHTML into an ImageBrush, use RenderTargetBitmap to let WPF render to a bitmap, then copy it back to the device.
To do this, construct your WPF content in any Visual subclass with a Background property (eg Grid or Border), then in your IHTMLPainter.Draw() method, just do the following:
Create a System.Drawing.Bitmap corresponding to rcUpdate
BitBlt from the given DC into the System.Drawing.Bitmap
Construct an ImageSoure from the System.Drawing.Bitmap (see recent SO answers for details)
Construct an ImageBrush from the BitmapSource using a viewport/viewbox that will lay it behind the portion of the visual corresponding to rcUpdate
Set your root visual's background to the ImageBrush
Set the RenderTransform on the root visual so that the rcUpdate portion starts at (0,0)
Render the root visual to a RenderTargetBitmap of rcUpdate size
BitBlt the RenderTargetBitmap to the rcUpdate area of the DC
This should work well, be simple to implement, and work for any WPF content including advanced features such as 3D, BitmapEffects, etc. The only disadvantage is that those two bitmap copies might slow things down somewhat.
Note that if you know your WPF Visual is totally opaque you can completely skip steps 1-5 and simply render your Visual to a RenderTargetBitmap and BitBlt it to the device.
Direct3D possibility (partial solution)
Obviously it would be faster to avoid all this bitmap copying during render. This is most likely possible, but I can only give you some ideas to point the way -- it will take a lot of trial and error and probably some undocumented calls to make it work.
Since WPF renders using Direct3D, obviously you would prefer to get a Direct3D surface from MSHTML and paint on it. Doing this requires two things: Getting the surface from MSHTML, and getting MILCore to draw on it.
IHTMLPainter has a flag HTMLPAINTER_3DSURFACE to request a Direct3D surface in its GetPainterInfo call, but I couldn't find any examples of how to use HTMLPAINTER_3DSURFACE. I suspect it could be figured out with a little trial and error.
I did not find any way to get WPF's native component "MILCore" to accept a Direct3D surface to paint on instead of a hWnd. There is no documentation on MILCore, and the only public API for setting up rendering tree, HwndSource, doesn't seem to be able to do the job.
Rendering behaviors through IHTMLPainter and IElementBehavior are meant to alter or supplement the display of existing elements in a page, not to render content for user controls. If you're looking to use WPF controls in a page, this is not the path to take. Instead, consider creating a blank windowed UserControl with ActiveX support, then do either of the following.
Add your WPF control at runtime as a member of the UserControl.
Perform WPF activities using the window handle (HWND) of the control.
Alternatively, you could just use Silverlight to make user controls. Silverlight has a pretty good subset of WPF display features, and even manually constructed Silverlight content is easier to manage than trying to get .NET Windows + ActiveX Hosting + WPF working.
If I've mistaken your question and you're truly intent on using WPF to perform drawing activities in an element behavior, Graphics.FromHdc() is an acceptable way to get a usable Graphics object. You should attach to the HDC specified in the Draw() callback.
Draw Method (IHTMLPainter) # MSDN
You could also attach to the window handle (HWND) of the document view (retrieved via IOleWindow), if your WPF activities involve the entire viewport. The window object can be cast to IOleWindow for this purpose (see IHTMLWindow2).
IOleWindow Interface # MSDN
IHTMLWindow2 Interface # MSDN
I'm really loving the WPF RichTextBox, and all of the out-of-the-box functionality it comes with...but printing is something that I'm having trouble with. I can print (from code) using a PrintDialog and passing in my RichTextBox as a Visual (or by using the "Document").
But my question is, is there a simple way to use the application commands:
ApplicationCommands.Print
ApplicationCommands.PrintPreview
With a WPF RichTextBox? Also, how would I go about letting the user change the page layout and such?
Take a look at http://blogs.msdn.com/llobo/archive/2007/01/24/printing-richtextbox-content-find-the-idle-printer.aspx