(1 item) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(6 items) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(4 items) |
|
(2 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(2 items) |
|
(5 items) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(1 item) |
|
(3 items) |
|
(1 item) |
|
(1 item) |
|
(2 items) |
|
(8 items) |
|
(2 items) |
|
(7 items) |
|
(2 items) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(1 item) |
|
(2 items) |
|
(4 items) |
|
(1 item) |
|
(5 items) |
|
(1 item) |
|
(3 items) |
|
(2 items) |
|
(2 items) |
|
(8 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(6 items) |
|
(1 item) |
|
(2 items) |
|
(5 items) |
|
(5 items) |
|
(7 items) |
|
(3 items) |
|
(7 items) |
|
(16 items) |
|
(10 items) |
|
(27 items) |
|
(15 items) |
|
(15 items) |
|
(13 items) |
|
(16 items) |
|
(15 items) |
Mike Taulty recently posted an example showing how to use LINQ to generate a graph in XAML.
He uses the new XML literal syntax in VB.NET. Since C# doesn’t get that feature, an exact conversion to C# would be relatively verbose. So, score one to VB.NET? Not so fast. I wanted to show an alternative approach that works as well in C# as it does in VB.NET.
You don’t need to go via XAML for this sort of thing at all. Perhaps the most important thing to grasp about XAML in WPF is that anything you can do with XAML, you can also do with code. Here’s a LINQ example based on Mike’s program, but which bypasses the XAML completely:
public Window1() { List<Point> data = new List<Point>(); int width = 8 * 96; int height = 6 * 96; for (double i = 0; i < (Math.PI * 2); i += (Math.PI / 50)) { data.Add(new Point(i, Math.Sin(i))); } this.Content = new Grid { Width = width, Height = height, Background = Brushes.Black, Children = { new Polyline { Stroke = Brushes.White, Stretch = Stretch.Fill, StrokeThickness = 2, Points = new PointCollection( from p in data select new Point(p.X, p.Y)) } } }; }
This has much the same effect as Mike’s example. The main difference is that this builds the UI objects directly, whereas his code builds a XAML document which, if loaded, will create the UI objects. I’m assuming that we do actually want to show the graph, in which case the important thing is that you create the relevant objects—a Grid
and a Polyline
in this case. XAML is strictly optional in WPF; the objects describe the UI, and XAML is merely one convenient way to create those objects.
In fact, I’d argue that in this particular case, XAML might best be avoided. The problem with generating XAML from either C# or VB.NET is that you get no compile time type checking, and no IntelliSense. XAML-specific tools such as Visual Studio 2008’s WPF designer in can offer such facilities, but by intermingling XAML and code in one file, we make it harder for the tools to help us. By contrast, the technique I’m using here combines LINQ with WPF in a way that retains full compile-time checking and IntelliSense.
Moreover, the new C# 3.0 object initializer syntax offers something that used to be the preserve of XAML: I’ve been able to make my code’s structure directly reflect the structure of the objects I’m creating. (Creating trees of WPF objects in C# 2.0 is much more cumbersome and, in my opinion, is much harder to read than XAML. This is one of the main reasons we favoured XAML over C# in the examples in our WPF book.)
That said, sometimes you do actually want XAML. For example, if you’re building a Silverlight 1.0 application, you really do need to provide XAML, because there’s no other way to create new UI objects. (Silverlight 1.1 fixes that.) So Mike’s technique would be appropriate when generating XAML content on the fly on a web server, for example. And there are some things that are still pretty clunky in code—I’d rather set up data bindings in XAML than C#, for example.
This example starts off with some data generated by code, and so it’s easiest to remain entirely within one programming language. But in practice, most of your UI won’t be built from data. Even if you do have a significant amount of data-driven UI, you’re likely to have a lot of static content too. There are plenty of situations where XAML makes the most sense.
So I don’t want anyone reading this to go off and write something of the form “WPF author abandons XAML”... I’m still a big fan of XAML, and even with the better syntax available in C# 3.0 I’m not planning to get rid of the XAML examples in the next edition of Chris’s and my book. I just wanted to show that for certain tasks, it’s more straightforward to build UI objects directly from code. As ever, it’s a case of choosing the right tool for the job.
And don’t forget, data binding is sometimes a better solution to this kind of problem. See my harmonic series demo for an example of how to generate a graph in WPF with data binding.