VB4: "XAML, I am your father"

Posted by: Tom Hollanders blog, on 20 Jun 2007 | View original | Bookmarked: 0 time(s)

I think I've mentioned before that I've been a Visual Basic developer since the glory days of VB 1.0. While these days I prefer the syntax of C#, I still dabble in VB fairly often (usually because I've been the only one in p&p who will write VB QuickStarts!), and I often think that the contributions that VB has made to software development as a whole are often underrated. While its popularisation of concepts such as GUI designers, properties and passing objects by references has been noted many times, I've just noticed something that appears to be a VB throwback in a new guise that I hadn't seen anyone mention before. Maybe I'm just a conspiracy theorist (I don't know anyone in the relevant teams), but whether or not this theory is true, I think it's a good story regardless.

I'm currently working on a project that's finally forced me to start learning WPF. Of course I've seen the snazzy demos with videos on spinning cubes, but up until now I never really had the time (or more importantly the necessity) to figure out how it all worked. Now I've only just dipped my toes into the water, but so far I'm blown away by both the capabilities and the simplicity of the architecture.

Once you start looking at WPF, it doesn't take long before you hear about this thing called XAML. At first glance, XAML is the XML language you use to build WPF GUIs. While there are fancy WPF designers in Visual Studio 2005 (via CTP tools) and Expression Blend, ultimately these are just editors over XAML files, and I've found that, just like with HTML, learning how to write XAML by hand is a great way of getting a better appreciation and understanding of the technology. If you haven't seen XAML code before, there are stacks of WPF XAML examples here, amongst other places.

However after reading and playing with XAML a bit more, I had the "a-ha" moment when I started to understand that XAML isn't actually about WPF at all. While the two technologies taste great together, you are completely free to build WPF apps entirely in code without a line of XAML. More interestingly, you can use XAML to build things completely unrelated to WPF. This is because XAML is actually a language for defining graphs of arbitrary .NET objects. While there are a few gotchas (like the requirement for classes to have default public constructors), XAML can be used for a wide array of applications, even when there isn't a UI to be seen.

To test this theory, I thought I'd try building a Windows Forms application in XAML. Obviously this wasn't the scenario that XAML was built for, but since all of the key classes are well behaved in terms of their constructors and collection types, it all worked just like a bought one. Here is the XAML for my trivial Windows Form:

<wf:Form x:Class="XamlWinForms.Window1"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:wf="clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms"
    xmlns:sys="clr-namespace:System;assembly=mscorlib"
    Text="Window1" Height="300" Width="300"
    >
  <wf:Form.Controls>
    <wf:Panel BackColor="#00FFFF" Dock="Fill" BorderStyle="Fixed3D">
      <wf:Panel.Controls>
        <wf:Button Text="Click Me!" Left="50" Top="50" Width="100" Height="50" Click="Button_Click"></wf:Button>
        <wf:ListBox Top="120" Left="20">
          <wf:ListBox.Items>
            <sys:String>Foo</sys:String>
            <sys:String>Bar</sys:String>
          </wf:ListBox.Items>
      </wf:ListBox>
      </wf:Panel.Controls>
    </wf:Panel>
  </wf:Form.Controls>
</wf:Form>

You would never do this in a real application, mainly due to the lack of visual designers, plus the need to specify co-ordinates for everything makes it much more painful than writing WPF applications by hand. But still, after admiring my work, it got me thinking that this is actually a far more sensible representation for a GUI, even in a WinForms app, than what Visual Studio does by default. Visual Studio's approach is to use the designer data to generate code (such as C# or VB) that explicitly adds all of the controls to the form and sets all of the properties. Even though this code is now safely hidden away in generated partial classes, it's all a bit fragile and, to me at least, feels unnatural - especially when it comes to parsing the code to re-render the form in the visual designer.

But then it occurred to me that I've seen a very similar approach to declaratively specifying forms before, in - you guessed it - Visual Basic 4.0 to 6.0. I don't actually have any of my old projects lying around on my hard disk anymore, but a quick search of the web came up with a number of examples of .FRM files, with code like this:

VERSION 5.00
Begin VB.Form Form1 
   Caption         =   "Form1"
   ClientHeight    =   3090
   ClientLeft      =   60
   ClientTop       =   450
   ClientWidth     =   3690
   ForeColor       =   &H0000FFFF&
   LinkTopic       =   "Form1"
   MaxButton       =   0   'False
   ScaleHeight     =   3090
   ScaleWidth      =   3690
   StartUpPosition =   3  'Windows Default
   Begin VB.Timer Timer1 
      Interval        =   1000
      Left            =   3000
      Top             =   2280
   End
   Begin VB.CommandButton Command1 
      Caption         =   "Press to Play"
      BeginProperty Font 
         Name            =   "MS Sans Serif"
         Size            =   9.75
         Charset         =   0
         Weight          =   700
         Underline       =   0   'False
         Italic          =   0   'False
         Strikethrough   =   0   'False
      EndProperty
      Height          =   495
      Left            =   720
      MaskColor       =   &H008080FF&
      TabIndex        =   0
      Top             =   2400
      Width           =   2175
   End
   Begin VB.Shape Shape1 
      FillColor       =   &H000000FF&
      FillStyle       =   0  'Solid
      Height          =   615
      Index           =   8
      Left            =   2280
      Shape           =   5  'Rounded Square
      Top             =   1080
      Width           =   495
   End
End

This file format was defined before the days of XML, but if you look at the content it has an uncanny resemblance to the XAML in its ability to define controls and properties, nest objects in one another, and even mix controls and (rudimentary) graphics together. I know that the XAML team has spent a bunch of time taking this idea and moving it far, far beyond what was ever possible in those days - but it's nice to know that good ideas like this don't die, they are just cryogenically frozen, waiting for just the right era to be thawed out again.

Category: XAML | Other Posts: View all posts by this blogger | Report as irrelevant | View bloggers stats | Views: 1 | Hits: 0

Similar Posts

  • Q3 2009 Release Week kicks-off November 4th, Free Daily Webinars more
  • Silverlight MVP more
  • Congratulations to Q3 NEW Silverlight MVPs more
  • Free Open Source .NET Mobile API From Mobile Experts - 51degrees.mobi more
  • Languages in the 2nd Edition of Programming Entity Framework more
  • Silverlight 3 FireStarter Free Online Event more
  • Its a Small World, After All, part 2 VB, C#, and GPS (Matt Gertz) more
  • Im asked, how did you learn what you know ? more
  • Better XAML By Farr: WPF Line of Business Seminar more
  • TechEd North America, here we come! (Lisa Feigenbaum) more

News Categories

.NET | Agile | Ajax | Architecture | ASP.NET | BizTalk | C# | Certification | Data | DataGrid | DataSet | Debugger | DotNetNuke | Events | GridView | IIS | Indigo | JavaScript | Mobile | Mono | Patterns and Practices | Performance | Podcast | Refactor | Regex | Security | Sharepoint | Silverlight | Smart Client Applications | Software | SQL | VB.NET | Visual Studio | W3 | WCF | WinFx | WPF | WSE | XAML | XLinq | XML | XSD