none
WPF or Winforms for ontology designer RRS feed

  • Question

  • We're about to start a project to create an ontology designer "plug-in" (not sure if the correct term is editor, add-in or package). We normally develop web applications, so we're not that updated on the status of Winforms vs WPF, and what is the recommended practice. Our pro's and con's list at the moment:

    WPF Pros
    - Built-in state manager
    - Much better databinding
    - Xaml seems to be the future direction of Microsoft for non-web interfaces.
    - Used by Visual Studio 
    - Hardware accelerated UI

    WPF Cons
    - Much harder to learn than Winforms
    - Fewer control libraries than Winforms

    Winforms Pros
    - Simple to learn
    - Lots of 3rd party controls
    - Visual designer is better than the WPF designer

    Winforms Cons
    - Not improved anymore
    - Not the best databinding
    - No built-in state manager
    - 2nd class citizen in the future when xaml based applications are main focus on all windows (and xbox) platforms

    All comments on the topic is welcome. What would you choose, and why?

    Monday, October 7, 2013 11:28 AM

Answers

  • If you need to do graphics (shapes, geometry, zooms, animations, etc.), WPF is much better for all the reasons you gave. I would add a very important topic: it's "vector oriented", which means it adapts better to any screen size (if you design it properly of course). It can also easily use pixel shaders wich can be cool for fancy graphics effect without performance loss.

    If you need to do dialog boxes of all sorts, treeviews, grids, property grids, etc., then I would choose Winforms for all the reasons you gave, unless you have a very strong requirement that the look should be super sexy (but in the Visual Studio IDE environment, that would be a kinda vain wish anyway :-)

    This is the result of our experience, as my company has been building a Visual Studio integrated tool for many years. You can have a look at the product here: http://blog.codefluententities.com/2012/06/15/codefluent-entities-metro-style/

    The left tree is the solution explorer (Visual Studio owns it and it's a standard Windows/Winforms treeview). The right side is a 100% WPF graphical surface we own that has vector treeviews, links and icons. The last image is 100% winforms property grid (there's no standard WPF property grid AFAIK).


    Simon Mourier



    Monday, October 7, 2013 4:46 PM
  • >The left tree is the solution explorer (Visual Studio owns it and it's a standard Windows/Winforms treeview)

    Minor correction, in 2010 this was true (it was actually a custom Win32 control that did some extending/styling on SysTreeView, but you could mainly imagine it as a stock Win32 tree view). In 2012+ it is a custom WPF control. It isn't actually a tree view as WPF tree views don't support virtualization and the solution explorer needs to be able to scale (performently) to thousands of nodes. To that end it is actually a list view (which does support virtualization) which is styled to look like a tree view. The individual nodes are also fairly optimized to custom render to make them lightweight and fast (since thousands of nodes with thousands of dynamically looked up / applied styles/templates can cause perf issues).

    Monday, October 7, 2013 4:53 PM
    Moderator

All replies

  • If you need to do graphics (shapes, geometry, zooms, animations, etc.), WPF is much better for all the reasons you gave. I would add a very important topic: it's "vector oriented", which means it adapts better to any screen size (if you design it properly of course). It can also easily use pixel shaders wich can be cool for fancy graphics effect without performance loss.

    If you need to do dialog boxes of all sorts, treeviews, grids, property grids, etc., then I would choose Winforms for all the reasons you gave, unless you have a very strong requirement that the look should be super sexy (but in the Visual Studio IDE environment, that would be a kinda vain wish anyway :-)

    This is the result of our experience, as my company has been building a Visual Studio integrated tool for many years. You can have a look at the product here: http://blog.codefluententities.com/2012/06/15/codefluent-entities-metro-style/

    The left tree is the solution explorer (Visual Studio owns it and it's a standard Windows/Winforms treeview). The right side is a 100% WPF graphical surface we own that has vector treeviews, links and icons. The last image is 100% winforms property grid (there's no standard WPF property grid AFAIK).


    Simon Mourier



    Monday, October 7, 2013 4:46 PM
  • >The left tree is the solution explorer (Visual Studio owns it and it's a standard Windows/Winforms treeview)

    Minor correction, in 2010 this was true (it was actually a custom Win32 control that did some extending/styling on SysTreeView, but you could mainly imagine it as a stock Win32 tree view). In 2012+ it is a custom WPF control. It isn't actually a tree view as WPF tree views don't support virtualization and the solution explorer needs to be able to scale (performently) to thousands of nodes. To that end it is actually a list view (which does support virtualization) which is styled to look like a tree view. The individual nodes are also fairly optimized to custom render to make them lightweight and fast (since thousands of nodes with thousands of dynamically looked up / applied styles/templates can cause perf issues).

    Monday, October 7, 2013 4:53 PM
    Moderator