Geek Answers Handbook

Library exchange issue between WPF / Silverlight and GDI + due to difference in System.Windows.Point / System.Drawing.PointF

In the project, I am currently working on http://sourcecodecloud.codeplex.com/ I have a library containing non-trivial geometry and layout algorithms. They are completely engine independent.

The application was originally written for GDI +, now I'm going to implement its Silverlight and / or WPF port. The problem is that all my algorithms use the System.Drawing.PointF , SizeF , RectangleF structures. They are all based on float . Corresponding WPF / Silverlight double classes.

The question is, does anyone have experience? What is the best way?

  • Create your own wrappers for Size, Point, Rectangle, etc., which can wrap both options.
  • Stick to either System.Drawing or System.Windows and throw it in another. The negative impact is an unnecessary reference to the assembly of "alien".
  • Some other magic?
+4
source share
4 answers

I would start with Portable Library Tools as your base. Any types there are suitable for use in all of your projects. For any types that are not present there, I would create my own abstract types and implement derived types that carry the corresponding type from each structure separately. Use those abstract types that you create as much as possible from your own code.

+1
source

One way that might be applicable is to use namespace aliases. You use an alias instead of the actual type and a compiler directive to switch between them. Because namespace aliases are for each file, this may not be acceptable if the code is distributed across multiple files.

 #if GDI using Point=System.Drawing.Point; #else using Point=System.Windows.Point; #endif

If you use var , you can eliminate many checks, throws and maintain performance. You still have to look for functions that accept and return certain types, such as Math.Sin etc

+4
source

I would use WPF types and use some global (extension?) Method to convert to GDI. They are more complete and more reasonable than where. The disadvantage is that they are based on a dual basis, so they are larger. But with all this memory that we have now, you are unlikely to have a problem with this.

+1
source

I am developing a map / GIS application with a lot of geometry and graphical calculations. Initially, I used GDI + classes such as Point and PointF directly in the rendering code, but it was increasingly becoming a problem because I wanted to support Cairo, SVG, Direct2D and other graphics engines. So at the end, I created my own hierarchy based on the interface, for example IPointF2 , IPointD2 , IPointD3 , etc. This, of course, is not ideal when it comes to performance, but I don’t see a better way to keep your algorithmic code separate from the graphics engine.

I wrote something on this subject a while ago.

+1
source

More articles:


All Articles