117

For a long time now, I have been stuck with Windows Forms development (started with VB6, and has continued through to C# .NET 4.5), and I have pretty much hit the limit of what Windows Forms can do, both using pure .NET, and special effects with Native Code.

I have tried to learn WPF and XAML, but I get stuck right at WPF's new designer. It really seems very difficult to use in comparison to the Windows Forms designer.

I want to know if there are any alternatives to .NET's WPF designer, that are more suited to Windows Forms developers?

ASh
  • 34,632
  • 9
  • 60
  • 82
Matthew Layton
  • 39,871
  • 52
  • 185
  • 313
  • 7
    I usually don't even use the designer, save for checking whether the overall layout is what I would expect; in the end I write everything by hand in XAML and/or use Blend when needed - although I'm not a designer so that barely ever happens. – Patryk Ćwiek Mar 28 '13 at 12:07
  • You can use Expression blend, but I don't think that's really any easier, it's more for designers than developers IMO. I normally just turn off the preview and work with the xml. – BlackICE Mar 28 '13 at 12:07
  • 5
    It's not difficult to use, you are simply not used to it. The biggest hurdle to overcome is the paradigm shift between the two technologies. Get yourself a good book on XAML, once you get used to XAML you won't even use the designer anymore - you will type XAML directly. – slugster Mar 28 '13 at 12:08
  • 3
    @slugster, I did wonder about that. The same thing happened with HTML...I used to build the UI with dreamweaver, and now I code HTML by hand – Matthew Layton Mar 28 '13 at 12:10

5 Answers5

186

I like to blog about beginner articles for WPF, and there are a few in particular that may help you out:

To summarize, the biggest difference between Winforms and WPF is that in WPF your data layer (the DataContext) is your application, while in Winforms your UI layer is your application.

To look at it another way, with WPF your application consists of the objects you create, and you use Templates and other UI objects to tell WPF how to draw your application components.

That's the opposite of WinForms where you build your application out of UI objects, and then supply them with the data needed.

Because of this, the designer isn't actually used that much since your application components are designed in code, and the designer is only needed to draw a user-friendly interface that reflects your data classes (typically Models and ViewModels)

And personally, I prefer to type all my XAML out by hand since it's faster and doesn't make as much of a mess as the drag/drop WPF designer does, although I do use the Designer on occasion to preview what my UI will look like.

So to your answer your question about if there's other WPF designers suited for WinForms developers, I would suggest that instead of looking for another designer, instead look to learn how to use WPF in the way it's meant to be used. Using WPF like it's WinForms means you miss out on much of what makes it so great :)

Community
  • 1
  • 1
Rachel
  • 130,264
  • 66
  • 304
  • 490
  • 15
    Totally agree with @Rachel. The most important realization when coming into the light of WPF is to understand that [UI is not Data](http://stackoverflow.com/questions/14381402/wpf-programming-methodology/14382137#14382137) and act accordingly. – Federico Berasategui Mar 28 '13 at 14:57
  • 2
    @Rachel - just to play devil's advocate: Starting with UI (which buttons, text boxes etc. appear in the window) helps focusing the application on *what* you want to do. The rest is just implementation details of *how* you want to do it. – Asaf Nov 13 '13 at 16:43
  • 1
    @Asaf Yes, the UI can be a good way to start, especially when working with clients to figure out what they want. But when designing and building your application with MVVM, I always find it easiest to start with the properties and functionality of the application classes (Models and ViewModels) first, and to work on the UI second, sometimes in a separate phase. – Rachel Nov 13 '13 at 18:20
  • @Rachel +1 agreed, especially since a program is often much more than what is visible so using the UI as a template may not always be optimal. – AndersK Mar 19 '14 at 07:08
  • 1
    -1 Sorry Rachel, but the way you explain it does not impress me. WPF and WinForms are not that different. They're both UI layers in which you can manipulate (CRUD) business objects. The explanation you give on your blog is too simplistic in the way you describe how people think in the Winform an WPF realm. – Youp Bernoulli Jul 08 '14 at 19:20
  • 3
    @HighCore take a look at http://stackoverflow.com/questions/982978/mvvm-for-winforms and you will have to acknowledge that Winforms is just a View / UI component in which business objects can be Bound to user controls. Okay: WPF is more suitable for MVVM but nevertheless Winforms can also work in such a Design Pattern. And as Rachel states "That's the opposite of WinForms where you build your application out of UI objects, and then supply them with the data needed." It's so untrue for although. I always think in a manner of at least Data and View. Data and Winforms / WPF / HTML whatever. – Youp Bernoulli Jul 12 '14 at 13:29
  • @YoupTube the fact that *you* know how to separate UI from data regardless of technology does not change the fact that 99.9999999% of winforms developers simply do a bunch of horrible code behind stuff instead of designing an application properly. And NO, archaic useless winforms is completely lacking compared to current technologies and does NOT support DataBinding. Show me the winforms equivalent of this: ``. – Federico Berasategui Jul 12 '14 at 15:24
  • 2
    It does support databinding at least at the level of Data entry / modification. And those 99.9999999% of developers will also mess-up in WPF I suspect. But let us finish this discussion. WPF is absolutely more powerfull / suitable for MVVM and a separation of concerns but I think you and also Rachel push Winforms in a negative corner. Especially when you keep using the words you use... – Youp Bernoulli Jul 13 '14 at 12:32
  • @youpTube show me the winforms equivalent of this: ``. No, we don't "push" anything. winforms' complete lack of features evidences itself every time there's a [*"how do I do this on winforms?"*](http://stackoverflow.com/q/22922233/643085) question which ends up being answered (by me) with a WPF solution because there's no way to deal with winforms' incapabilities and uselessness other than ditching it completely and using decent technology. If you fail to recognize that, that's your problem, not ours. – Federico Berasategui Jul 16 '14 at 22:46
  • 3
    @YoupTube You're right, Winforms does support data binding, and it is possible to create your own custom bindings for cases where the default binding system won't work too. I wrote this answer and my blog articles with beginners in mind though, and typically beginners think in terms of UI components, not data objects. In addition, binding in WinForms didn't always exist in the state it does now, so many developers that grew up with WinForms, or who are used to other technologies that don't use bindings, will often not identify this key difference when switching to a bound architecture. :) – Rachel Jul 17 '14 at 17:23
  • I've been working in WPF with the MVVM pattern with Entity Framework for the last 18 months. I've just been forced to go back to a Windows Forms solution to add some features. Oh my days it's awful! so much code & the whole event driven design which creates dependencies between UI & logic seems so wrong. Yes Xaml & the MVVM pattern has a steep learning curve & commanding is a pain to set up but once you understand the power of DataContext & binding you'll never look back. – Hardgraf Jun 26 '15 at 10:49
  • I echo the comments above. I tried to use Blend but didn't get on with it. I don't the touch the designer. I write everything in Xaml by hand. Also, Mahapps is a fantastic library for those who want that 'Modern UI' look without having to struggle with custom control templates. – Hardgraf Jun 26 '15 at 10:49
  • All what is said about WPF is good, But as developers when we are asked to transform an earlier winforms Application into a new look and feel WPF, We are always asked to use some old classes from the old application, is it OK or just take more time and start from scratch?? – Ashraf Sada Jun 24 '16 at 21:16
  • 2
    @AshrafAbusada I suppose it depends on how your WinForms application is built, and if you want to use MVVM or not. The two biggest challenges I would see are WinForms applications that are not built in a way that makes replacing the UI layer easy, and the lack of `INotifyPropertyChanged` on the object models. Depending on the complexity of your model layer in the WinForms app, it might actually be faster to just rewrite them. – Rachel Jun 25 '16 at 14:48
9

Well although, some people don't agree, I would also recomment to not use the VS designer. At least not to create an interface. If you may want to get a first impression of your implementation without starting the application, it's a good viewer at least as long no sophisticated things like Styles and Templates are used. But, IMHO, its drag and drop result should only be used as prototype and therefore be discarded after it's no longer needed.

Here are some reasons which are important for me not to use it.

  1. The VS designer is working with fix margins and alignments (which is usually not necessary, if you're using the layout controls), means you have to touch many controls, if the requirements are changed. If you're deep in XAML and the WPF mechanics you can create an applications which can be modified with small effort, regarding the look and feel.

  2. Since the designer is generating the xaml, the composition is not optimal and the UI may perform badly. I didn't measure it, it's just a feeling.

A much better alternative is MS Blend, although the start is everything else but easy. Its drag and drop result is much better that the result of the VS designer.
But it's a pretty powerful tool, which helps you to use pretty powerful elements to create a state of the art UI. I recommend to visit at least a short workshop to get an idea of its opportunities.

Back to your question, IMHO, and I think many people agree, get yourself a good book e.g. WPF Unleashed and later, if you want to know more about the details, WPF Pro. There are a lot of features which are different to Winforms. You won't get to know them by using any designer. I think that's the best approach.

Please also consider that there are many frameworks and libraries (e.g. MVVM light, WPFToolkit) out there, which are already solving some common problems. So it's not necessary to reinvent the wheel.

DHN
  • 4,807
  • 3
  • 31
  • 45
9

I know this is an old question but for the benefit of anyone else looking at this, I think I should redress the balance a bit - reading some of the other answers, I get the feeling that some of the 'don't use the designer' sentiment comes from not using it properly. This tutorial is quite good to get you going and answers some of the criticisms in the other posts.

For instance, you can switch from the Winforms-like margin-based layout that is the default when you drop a control, to a more WPF-ish style by right-clicking and selecting 'Reset Layout'

This video covers similar ground.

I still prefer the VS2010 designer on balance - VS2013 seems to be a bit buggy when dragging and dropping onto TabItems **, (which my current project uses a lot) - but the VS2013 Document Outline view lets you move things around in that view too, which can be a real plus.

Really, though, to get the most out of WPF and xaml you need to be reasonably fluent in both the designer view and the xaml view and switching between them; if you shy away from the designer, you are missing out on something that can help you a lot.

** Edit - although this seems to have been improved in Update 3 for VS 2013, and in previews of VS14, to date I still get odd behaviour at times.

peterG
  • 1,651
  • 3
  • 14
  • 23
7

First of all, in WPF (XAML) in Visual Studio deisgner, you should always use the xaml code to build you UI and do not drag and drop you control! You need to keep your code clean. You can use Expression Blend to help you, it's more graphic oriented with drag and drop, but it's not free.

It's not a big learning curve, but I think you should learn how to do your xaml by hand instead of searching for alternative.

mlemay
  • 1,622
  • 2
  • 32
  • 53
  • 1
    Drag-n-drop is no harm, although if you prefer typing, that is also fine. Manually typing is never the key for WPF. – David Mar 28 '13 at 12:12
  • 3
    When you drag and drop in WPF, I see that often, you have a lot of margin of -1200 and things like that that does not make sense at all... I've always did it by hand it's better for sure – mlemay Mar 28 '13 at 12:16
  • 1
    This is off topic. Make sure your problem is commonplace to all, not yourself only. Besides, you cannot say drag-n-drop is bad, if you have some problems. Relying on designer is still needed and sometimes favored, you might see this is true, if you know how expression is welcomed by both designer and developers. – David Mar 28 '13 at 12:19
  • 1
    yes if you use expression blend, ok you can do it, but i was talking in visual studio... – mlemay Mar 28 '13 at 12:21
  • No one limits this to VisualStudio, we are talking about WPF. – David Mar 28 '13 at 12:22
  • 12
    I think advising someone coming from Forms and starting WPF to not use the designer is a really bad idea. The fastest way to understand XAML is to use drag and drop and then observe the code. – Ucodia Mar 28 '13 at 13:38
7

I've been through this process as you did. Afterwards I was teaching everyone in my company WPF. There are a couple of important lessons I have learned and everybody I know who works with WPF.

  1. If you are working with UI controls in the code behind, .... Then you are doing it wrong. There is absolutely no need for you to deal with UI controls in the code behind.
  2. You do not need the visual developer for clicking on it. You are much more productive by only dealing with XAML. Use Copy/Paste. Do not trust in your typing capabilities. It will save a lot of headaches.
  3. Think of the XAML just as a window that loks over the data. In the code behind you are changing the data. In XAML you are defining how the UI will interpret the data.
  4. Converters are amazing. As soon as you get a key amount of Converters, your productivity will rocket Sky high. They will take over the role of the crazy amount of control eventhandlers that hide or resize, or what ever about UI,

It makes UI development fun. Especially once you find out how it likes to play along with Asyc processes. It really takes away a lot of the headaches that were caused by Winforms.

user853710
  • 1,715
  • 1
  • 13
  • 27