Click here to Skip to main content
11,581,982 members (77,376 online)
Rate this: bad
Please Sign up or sign in to vote.

we have a Software which is developed in MFC. We are drawing documents with GDI+. The output is primary on screen but EMF, Printing and export as several image formats are supported as well. As it's all done with GDI+ that's no big deal in MFC. Just generate a Device for Printer, EMF, Image or whatever and draw the documents with the device....

But now there is the idea to redesign the whole application. We have several years of experience with C# so we wanna use the .NET technology. there's still the question to use WPF or Windows Forms. Anyway at the moment we are using WinForms.

We've already made a small framework where UserControls take place. A page is a UserControl and contains diagrams(also UserControls) or other elements like TextBoxes, ImageBoxes, etc. For Printing we just use the .ToBitmap() method of the UserControls.


With this approach we are not able to create accurate graphics (Draw directly on the Printer or create EMF). The outputs of this applicaton is also used in Print Media --> so it has to be very accurate. Using the .NET Framework built in Printing classes would mean to code the "Drawing" method of each Control. That's a lot of work and the implemenation of the GUI would be different from the Printing. I also found out that WMF/EMF is not supported in WPF. Also the support in WinForms is quite bad.
As the layout of the document is designed by the user at runtime, Reporting Frameworks are not an option.

So here are my question(s):
Is there any guide line, design pattern, framework or any other information to build such an application? (Dynamic layout at runtime, output as EMF (or similar), Printing.
WMF/EMF is very old, but it's still the only way to get accurate graphics from applications into office, InDesign, etc. Is that correct?

Thanks in advance for any suggestions!
Posted 5-Jun-12 3:08am
Edited 11-Jun-12 2:35am
AdamDavidHill at 11-Jun-12 6:37am
This is more of an idea than an answer but hope it helps... Have you considered / looked into using SVG? It's fairly similar to XAML for paths and quite portable. You could maintain objects' basic path data, and then either render dynamically as generated WPF Paths for the UI or output as an SVG file for use with a generic application or printer. If your diagrams need to be interactive then it might get quite fiddly, but might be worth exploring.
SAKryukov at 11-Jun-12 13:38pm
Yes, the idea is good, but as WPF is preoccupied with XAML, and XAML would be enough for all practical diagramming purposes, I would recommend WPF. Please see my answer with links to my past answer, where I sketched the basic design idea, with sufficient detail, for starters.
neyerMat at 11-Jun-12 8:19am
Thank you for your respone.

This is a quite good idea. I already thougt about that. I also thougt about EMF/WMF to generate the diagrams and render it to Bitmap or a WPF Visual for UI. But there are many problems with that solution:

- As you already mentioned, it's very tricky to have user interaction with this graphics.

- afaik SVG is rearlly supported by Microsoft (especially Office).

- "3rd party controls" can not be used because no WPF Visual supports "DrawToSVG" or similar. That would mean that Controls such as Graphs, Button or even a TextBox can not be exported. I would have to reinvent the wheel and code every standard Control again (or at least derive from thoose) to support SVG.

This is the main problem. WPF itself works with vectors, it is not possible to save this vector graphics to a common file format (such as SVG, EMF). I know that is possible to render a Visual to Bitmap. But that's not a vector graphic. SVG seems nice but I don't know how to get it from UIElement.

AdamDavidHill at 11-Jun-12 18:52pm
Just to clarify what I meant with my idea; exporting WPF paths to SVG is actually not so bad. Exporting general UI controls is not. The main problem you face there is implicit templates - i.e. what you're trying to export is partly the default template of a control. If you build all the diagrams from scratch in basic paths then exporting isn't much of an issue as is very similar to for the basics. As SAKryukov says, GDI+ and WPF are very different. He's provided some interesting links to get you going, though.
SAKryukov at 11-Jun-12 13:30pm
GDI+ or WPF? These are two different things...

1 solution

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

Please see my comments to the question. You can use either System.Windows.Forms with System.Drawing and GDI+ or WPF, not all together (in fact, you can use interop, but this is not practical).

If you can consider using WPF, I would strongly recommend using it. It is designed with the support of many different activities in mind; and diagramming is one of the major programming chores supported very well. Most things like interaction with the user, vector graphics (with the use of XAML, not as universal as with SVG, but practically the same for diagramming purposes), zoom and pan — all that is already implemented.

Please see my past answers where I tried to sketch the design of diagramming software:
Connect different controls[^],
Vector graphics software like CorelDraw or Inkscape in C# or VB.NET[^],
Architecture diagram tips[^].

nv3 at 11-Jun-12 15:23pm
Very well and comprehensively answered!
SAKryukov at 11-Jun-12 17:09pm
Thank you very much,
neyerMat at 12-Jun-12 4:24am
Thank you for your answers(s)

I don't want to mix up the technologies. I just want to figure out which one is the right to develop my application. As already mentioned above the current software is written in Visual C++. It works fine but it's getting harder day by day to maintain this "piece" of code (~300 000 lines).

Now we want to redesing the whole program. I already made several sample applications in WinForms and WPF to analyze which technology is the right one.

For WPF there are a lot of possibilites as you already suggested. the following article discribe a very good solution how to get things done in WPF.

Our application is a little bit mor complex. Instead of single shapes we would have complex UIElements such as Charts, TextBoxes, Images, etc. The software is like a report generator but the user can design the layout at runtime.

That's still a lot of work, but no big deal if you have only to get the results on screen and print them.

But we have to export the outputs as EMF (or any other accurate format) to import it at least to MS-Office.

afaik WPF does NOT bring this functionallity out of the box. So the way we would have to go in WPF is write each UIElement on our own with basic Shape objects. Than write a Export method which "translate" the WPF shapes to the desired file format.

As WPF already works with vectors for me it seems to reinvent the wheel (I know that WPF is more than just 2D-charting and the fileFormats such as EMF or SVG are not capable of all the possibilties that WPF has)

But with this restrictions WPF seems not to be the best choice, even if it has Zoom and Pan,etc. already implemented(also MFC(GDI+) can do that more or less out of the box).

To bring it to the point:

How to design the UIElements (charts, text, images, mix of both) to export it as EMF or similar?

The way above seems to be the only solution but with a huge effort (Write EMF or SVG export from scratch). Any other ideas???

In fact EMF just stores a stack of GDI commands. Maybe it's not the correct format when using WPF. Anyway.. is there any file format which should do the job for WPF?? How do others export their results? Screenshots? :-\ XPS? Workarounds with virtual PDF or GhostScript Printers???
SAKryukov at 12-Jun-12 11:21am
Don't use EMF, don't get you in trouble. Use XAML, and/or SVG, which is the only open, public, non-proprietary comprehensive 2D vector graphics format. Just forget EMF.
neyerMat at 13-Jun-12 4:33am

just to let you know how "good" SVG works together with MS-Office.

Another point of view is that Microsoft itself do exactly the same for PostScript Printers.

BUT it's just not possible to use that already implemented feature...

It's getting more and more frustrating. It seems that there is NO SOLUTION to create a vector graphic from WPF. WMF/EMF is dead (but still in use...), SVG is not supported by Microsoft (big A vs. big M???) XPS is not supported by anyone except MS.

At the moment the only solution seems to generate EPS files with a virtual printer or JUST FORGET WPF!

For me it looks like Microsoft want to push their own standards (XAML, XPS) and just don't support other formats to make the new file-formats popular...
neyerMat at 14-Jun-12 6:48am

This gives more information about the effort to export SVG... any tipps for another format??
neyerMat at 20-Jun-12 9:16am
another great article how to create metafiles:

That's more or less exactly what we do in our programm, but with C++. That make things a lot easier. You can create UserControls which can render on any System.Drawing.Graphics device.

asfaik and also regarding to the solutions provided, nothing similar exists for WPF.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

  Print Answers RSS
0 OriginalGriff 345
1 Sergey Alexandrovich Kryukov 220
2 Andy Lanng 114
3 virusstorm 109
4 Kornfeld Eliyahu Peter 90
0 OriginalGriff 1,358
1 Sergey Alexandrovich Kryukov 970
2 Abhinav S 671
3 F-ES Sitecore 505
4 Suvendu Shekhar Giri 448

Advertise | Privacy | Mobile
Web03 | 2.8.150603.1 | Last Updated 11 Jun 2012
Copyright © CodeProject, 1999-2015
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100