Home/ Questions/Q 879251
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T11:54:07+00:00

I’ve been developing with WPF for many months now. It’s a great framework and

  • 0

I’ve been developing with WPF for many months now. It’s a great framework and I’m able to do fancy, elegant stuff that would have been a lot more difficult with WinForms.

However, I do have the feeling that for normal “line of business” type of applications without any special UI requirements, it still takes me longer to code the UI in XAML than it did to drag-and-drop it in WinForms.

For example, in WinForms, I would just drop an additional label and an additional textbox on the form and arrange everything (using the helper lines) until it looks nice. In WPF, I’d start by factoring out the properties of the existing label and textbox into a style, so I can reuse them; think about the most suitable layout element, maybe refactor some dockpanels/stackpanels into a grid (or vice versa); try different values for the margins etc. Although I have a lot of experience in WPF, it still takes a long time.

I know that I could just forget about “clean XAML” and use the GUI designer in Visual Studio 2008 (which just absolutely positions everything inside a huge grid), but I fear that I would lose a lot of the advantages that XAML offers by doing that.

Have you experienced something similar? If yes, what did you do to speed up everyday WPF development?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What I do to speed up everyday WPF development:

    1. Ignore look and feel for as long as I can. Ideally, tweaking alignments and margins and defining styles is the very last thing I do.

    2. Use the DockPanel before using a Grid, and a Grid before using a StackPanel.

    3. When using the Grid, star-size everything. I’ll come back and fix this later, but during prototyping, having a clear idea of how many rows and columns the Grid actually has is enormously helpful.

    4. Prototype in Kaxaml, finish in Expression Blend, test in Visual Studio. Figuring out a methodology for this has taken a lot of time, and it’s still very much a work in progress. But Kaxaml is great for quickly seeing how a XAML prototype will behave, and Blend is great for working out the visuals and encapsulating things into user controls and styles.

    5. When using Blend, don’t create layouts in the artboard, create them in the object outline. When I’m first developing a WPF UI, the hierarchy of objects is a hundred times more important than how it looks on the screen. I’m still learning to do this, and it seems possible that once I get good enough at it I won’t need to prototype in Kaxaml anymore.

    6. Work on the smallest thing possible. This requires a lot of discipline. I’ve got a nice big complex XAML file, and I decide that I need to edit the template of a control The first thing to do is to create a tiny XAML file with that control in it, and edit the control template there. The temptation to work like this in situ is strong, as editing the control template is only a right-click away. Don’t do it.

    7. Don’t even think about whether or not I should develop a view model for my tiny little one-off application. Yes, I should.

    8. Learn Blend. Really, really learn it. Learn what all of the tiny icons that surround the selected object mean, and pay attention to them. (Here’s a shortcut: I didn’t set margins on that thing, but Blend did. That’s the answer to maybe 30% of my “what the hell is Blend doing now?” questions.) Use the Blend UI even if I know it would be faster to edit the XAML by hand. This is again a matter of discipline, resisting the temptation to get it done now so that I can improve my ability to get more of it done later.

    • 0