Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. WPF
  4. WPF XAML vs Procedural Code

WPF XAML vs Procedural Code

Scheduled Pinned Locked Moved WPF
csharpvisual-studiowpfhtmlgraphics
2 Posts 2 Posters 4 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • T Offline
    T Offline
    thrakazog
    wrote on last edited by
    #1

    I've been playing around with WPF a little bit. I'm using vs 2008. I'm trying really hard to see what the benefits are to using XAML. I understand that when I drag buttons and junk from the toolbox that they will be described in the XAML markup. That's fine. But if I want to do anything beyond that, like custom drawing, I don't see when XAML would be the answer. So far the only one I can come up with to us XAML is the shiny preview window in the designer. This is nice but doesn't overcome the XAML problems I'm seeing: No strong typing. No error handling. No intellisense. No inheritance. (I've seen some workarounds for this but they don't exactly excite me.) If I write my WPF customizations in nice procedural code behind C# these problems go away. Along with the shiny preview window. Am I missing something here?

    J 1 Reply Last reply
    0
    • T thrakazog

      I've been playing around with WPF a little bit. I'm using vs 2008. I'm trying really hard to see what the benefits are to using XAML. I understand that when I drag buttons and junk from the toolbox that they will be described in the XAML markup. That's fine. But if I want to do anything beyond that, like custom drawing, I don't see when XAML would be the answer. So far the only one I can come up with to us XAML is the shiny preview window in the designer. This is nice but doesn't overcome the XAML problems I'm seeing: No strong typing. No error handling. No intellisense. No inheritance. (I've seen some workarounds for this but they don't exactly excite me.) If I write my WPF customizations in nice procedural code behind C# these problems go away. Along with the shiny preview window. Am I missing something here?

      J Offline
      J Offline
      James J Foster
      wrote on last edited by
      #2

      There are many advantages of XAML, but disadvantages as well as you pointed out. In the case of WPF, XAML is a non-language specific description of the UI using a more natural hierarchical relationship between elements. This also enables easier code sharing between languages, and enables tools to generate XAML without knowing the nuances of a programming language. Expression blend is one such tool, and there are converters for many other third party tools as well, such as Adobe Illustrator. You can write a feature-rich app with just XAML and never touch a line of VB.NET or C#. That being said, there are advantages to both XAML and procedural code and those trade-off decisions need to be addressed in your design. I personally like to see the hierarchical relationship, but do have some gripes when it comes to debugging complex XAML.

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups