Click here to Skip to main content
15,867,308 members
Please Sign up or sign in to vote.
4.67/5 (3 votes)
Hi,

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.

|----------------|
|.....page.......|
|.|----|.........|
|.|diag|.........|
|.|----|.........|
|................|
|----------------|

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
Updated 11-Jun-12 2:35am
v3
Comments
Adam David Hill 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.
Sergey Alexandrovich Kryukov 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.
--SA
neyerMat 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.

see:http://msdn.microsoft.com/en-us/library/system.windows.media.drawingvisual.aspx
Adam David Hill 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 http://msdn.microsoft.com/en-us/library/ms752293.aspx is very similar to http://www.w3.org/TR/SVG/paths.html#PathData for the basics. As SAKryukov says, GDI+ and WPF are very different. He's provided some interesting links to get you going, though.
Sergey Alexandrovich Kryukov 11-Jun-12 13:30pm    
GDI+ or WPF? These are two different things...
--SA

1 solution

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[^].

—SA
 
Share this answer
 
v3
Comments
nv3 11-Jun-12 15:23pm    
Very well and comprehensively answered!
Sergey Alexandrovich Kryukov 11-Jun-12 17:09pm    
Thank you very much,
--SA
neyerMat 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. http://www.codeproject.com/Articles/24681/WPF-Diagram-Designer-Part-4

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???

[edit]
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???
Sergey Alexandrovich Kryukov 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.
--SA
neyerMat 13-Jun-12 4:33am    
http://answers.microsoft.com/en-us/office/forum/office_2010-word/svg-does-not-paste-properly-into-word/b24a9fc2-1093-49bd-ad9e-6f7585e8934a

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.
http://msdn.microsoft.com/de-de/library/ms742418.aspx

BUT it's just not possible to use that already implemented feature...
http://social.msdn.microsoft.com/Forums/en-US/windowsxps/thread/dab2607b-1119-41d6-bf1d-6df02cbd4951

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...

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900