Text transcript of show #166. June 22, Windows Presentation Foundation explained by Ian Griffiths

Transcription

1 Hanselminutes is a weekly audio talk show with noted web developer and technologist Scott Hanselman and hosted by Carl Franklin. Scott discusses utilities and tools, gives practical how-to advice, and discusses ASP.NET or Windows issues and workarounds. Text transcript of show #166 Windows Presentation Foundation explained by Ian Griffiths Scott chats with about Windows Presentation Foundation (WPF). Why is it so hard to master? What techniques should the WinForms developer learn first? Scott's working on a side project, and he and Ian brainstorm ways for Scott's application to use WPF more effectively. (Transcription services provided by PWOP Productions) Our Sponsors Copyright PWOP Productions Inc. Page 1 of 12

2 Lawrence Ryan: From hanselminutes.com, it's Hanselminutes, a weekly discussion with web developer and technologist, Scott Hanselman, hosted by Carl Franklin. This is Lawrence Ryan, announcing show #166, recorded live Friday, June 19, Support for Hanselminutes is provided by Telerik RadControls, the most comprehensive suite of components for Windows Forms and ASP.NET web applications, online at and by.net Developers Journal, the world's leading.net developer magazine, online at In this episode, Scott talks about Windows Presentation Foundation with Ian Griffiths. Hi, this is Scott Hanselman and this is another episode of Hanselminutes and I'm sitting down here in Norway at the Norwegian Developers Conference and I've got Ian Griffiths with me who is a free-lance WPF consultant and also a Pluralsight instructor and course author, thanks for chatting with me today. Oh, thanks, for having me on. I'm continually trying to understand WPF and I started with my Baby Smash application which I wrote incorrectly and then I'm trying to make it more correct and now I'm working on another WPF project I'm calling Shoebox Scan where someone could basically talk to a scanner and put a bunch of photos from their shoe box and then do some work and you just spent the last hour with me, kind of correcting my mistakes and we hit an interesting wall and I think that that's a nice metaphor for what I think a lot of people who are using WPF are doing. I really thought about it in terms of WinForms and in terms of Win32, you went with me very kindly, running, screaming against the wall until we finally hit it. Maybe talk to this a little bit about what we tried to and what went wrong and now what I'm going to have to do to go forward. So this is a very common pattern in WPF application developments and as I tend to tell people when I see this sort of thing, I found all the WPF apps I've worked on before into one of two categories. One is where I build a separate class that manages all the interaction stuff that's completely separate from the code behind, in the XAML and then there's the applications where I wish that's what I've done and wherein the former one because that's the path of least resistance, right? You sit down in front of the Visual Studio Designer and wonder why the XAML, it doesn't do very much but then you get used to do that and you start writing code and you think "Okay, I've got to get a bitmap on this screen, I'll use this image tag, that seems to work or I can make it do stuff, I can resize it, I can maybe have extra stuff led on top of it to represent the scans in your example, I can drag stuff out and everything ends up kind of getting baked into the view. You start using WPF's Visual Tree which is the structure that represents what's on the screen to hold your application state and it can either be what you might think of as a model state the underlying ideas that are part of the application or it might be more transient stuff, it's not really part of the model like which things are selected right now, am I in the middle of a drag operation? Do I have adorners because this is the thing I'm dealing right now and all these things can live in the view because that seems to be obvious thing to do." So they put this in the context of the application so that people who, of course, can't see this because we're on a podcast, I'm trying to make an application where I can scan the entire scanner flatten which has a number of pictures on it and then I want to drag rubber bands around them. So I might have 5 or 10 pictures that are being scanned in one pass. I've been holding all of those and, like what you said, the Visual Tree. I've got 10 little small wallet sized pictures, they're held very nicely in the visual tree. I figured they're inside of a canvas and I'll spin through them later and that's not a good idea, that's what you're saying? It's always a bad idea in the long run. What tends to happen and exactly what we saw happen just now as we're working through it, is you suddenly get to a point where things just seem to be impossible, it's like the complexity has exploded because you're trying to hold your head what it was you meant by this particular thing in this place in the Visual Tree. It's like, "Ah, there's a content control there that signifies this particular thing to my app." I noticed you're trying to write code that's embodying relatively straightforward concept so we have the idea which was we want to make sure we use a drag, an outline into the image that that's inside the image... We were finding that we could drag the image all the way off the form and off into space and I said, "I want to bound that inside of this." So we only had really two places, there was the XAML and there was the code behind... And that's everything that we're doing and that was the only interaction was just you and I trying to get the XAML to do what we get it to do, there was only code behind they had no other classes. Yeah and that's a problem for a couple of reasons, one of which is it makes the code really hard to follow. The fairly quite simple ideas you want to represent don't look that simple when you come to write the code, you end up with all sorts of stuff that is dealing with either putting things into the Page 2 of 12

3 view or taking them back out again to get back to the information you first thought of and yeah you just get, and also the other problem is you've got a lack of testability. How on earth would you write a unit test to say that a user can't drag something outside of the bounds of the image there? That's not going to be a particularly easy thing to do. You're probably going to end up having to use something like an automated test framework with UI automation support. To fake input into the UI and that's a bit of a nightmare. That's not the right way to go out testing some code which is ultimately no more complex than this number is no less than zero, this number is no greater than that bound. So clearly, the code is in the wrong place. Right and once again I found myself writing WPF code in a WinForm state of mind. Until you finally said, "All right, we've got to stop. It's nice that we've got it working 80% but everything we've done is wrong." So then you said we need to do a ViewModel and we hear this term more and more because we're hearing it in ASP.NET MVC world and View Model and I'm hearing it in WPF. Maybe explain the concept of View Model versus just the model and just the view within the context of WPF for our listeners. So just to add to the confusion, there's at least two popular languages this thing goes by. Some people call it the View Model, some people call it the Presenter and more generally, you sometime hear this bright idea referred to as a separated presentation, I think that's the term that Prism guys use for this exact same concept. And what is Prism? Prism is the, I think it's technically application guidance but it's actually a bunch of code that you can download for doing composite applications in WPF and Silverlight. And for those who don't speak English, composite would be composite applications that are composed of other controls. It's particularly aimed at teams where you've got a lot of different teams putting pieces into a single application. You want it all to work in concert to try to deal with those sorts of integration problems. So it's not unique to that style of app though, the ViewModel concept appear, works in pretty much any UI and the idea is this, your model typically contains things that a specific job demands, so whatever you're trying to work with, that battle is, whatever ideas your applications tries to deal with those live in the model but most user interfaces have stuff that has nothing really to do with the model. It's much more to do with the interaction. Some of the classic example is the drawing program. You take something like Adobe illustrator that has the model which is the drawing, the shapes that are in the drawing but also the program has the ability to let you select an item in the drawing and it lights up with adorners and other things you can drag around. Things in the tool bar will change and that's more to do with the structure of the interaction, what happens when the user starts to push a mouse button down? What state changes occur because you have state machines and things like drag operations, if you look at something like multi-touch interfaces where you're dragging a bitmap around with your finger then you put a second finger down to resize it to do that kind of squeeze thing. Your interactions are going between different states and you've got to have somewhere for that state to live. You've got to have somewhere for the extra information that used to appear on screen during the interaction that doesn't belong in the underline model. There has to be a place for that to live and people seem to default to putting it in the view because nothing really drives them to put it anywhere else and this is the thing that is not really understood but there has to be a place for that to live and that's what the ViewModel is for, it's a separate class that is the home for those sorts of things. So one of the words that you've mentioned a couple of times that we haven't defined yet is an adorner and there's really, this word is really overloaded because there's the notion of an adorner in WPF but then there's also the general concept of something being adorned like you made a comment in, about Photoshop that I've got some item on the screen and when I click on it, perhaps there's going to have resize handles or it's going to have a little lollipop sticking at the top that I can grab and then rotate where I've adorned this item, it's not a part of the model... It's not really part of the view or is transiently part of the view. The view has to show it but the view shouldn't be the thing that knows that it's supposed to show it. view model. Hence, a model for the view or Exactly, that's exactly it, yeah. And just to talk a little more about the adorner thing, I mean in general what you said is the basic idea of an adorner, WPF happens to provide some infrastructure to solve some of the common problems because you want the adorners to float at the top but you also want Page 3 of 12

4 them to follow around the things they're adorning as you zoom in and pan and rotate and it just provides a little infrastructure to try and make that easier but it's a more broad concept than that, it's just like most programs that support interactive selection have something like that. So about an hour into our exercise working on our little scanning application which I'm going to put up on Code Blitz and I've had a number of other people help me with on Twitter. It's still not quite there, I think that you actually said I was basically screwed and... Pretty much, yeah. Pretty much. What am I going to have to do to fix this? Right now, you and I ended up with a thing about five different functions that were all on the code behind and then we d really gotten close and the point where you said I was in trouble was where, we have our scan and the scan looks great, I can drag rubber bands or what I'm calling rubber bands or what I'm calling rubber bands is I mean user scalable, rotatable, transparent rectangles that I could say, "Scan this area and this area and this area and then we started dragging it around, we had a little preview window that was showing how this was going to get cropped and then we drag it right out of the form and kind of opted to non-client area and you said, "Uh oh, I could see the wheels turning in your head and you're like yeah, this, constraining this, getting this to behave correctly is going to require you, you said re-write and I'm hoping you meant re-factor this application." I mean it's a restructuring... It's not going to be a complete rewrite and really it's a question of moving the logic around but quite a lot of that logic is probably going to have to change and the good news is it's going to look simple when you're done because the problem is right now you've got decisions the code is taking which is thoroughly intermingled with stuff you only had to do because you were dealing with the visual tree. It is very, I would describe the code you and I wrote is very intimate and that we are very much poking around inside the view, trying to bend it to our will. Yes and that's absolutely what we don't really want to do. So this is one of the things I think that is holding WPF back is that it's unclear to a lot of people at least from the point of view of the tooling. I mean when you say file a new WPF application, there's nothing that says and here now make a ViewModel right. So there's no guidance there. How is someone supposed to know this? Unfortunately I don't have an answer to that other than maybe we could record podcasts talking about this sort of thing... And maybe produce better applications that show how it's done. Isn't this holding WPF back? I think it may be although it does sort of depend on what kind of thing you are building with it. I mean Dev10 has got stuff that's coming, that's going to make some of the classic line of business application type data binding scenarios easy to use. I think actually, probably in that world, while carrying on working like you think you're in Windows Forms may actually work just fine so long as you're building the kind of application that would have worked the same way as it does in Windows Forms. Is this my problem? Is this an issue that I'm writing apps that aren't typical apps, I mean I'm not writing data binding HR, human resources management applications I'm writing either Baby Smash or obscure scanner application, am I picking the exact wrong scenarios for WPF? Well no, this is the interesting thing, I think you're picking exactly the kinds of scenarios that WPF makes possible so long as you set about it in the right way. This is the kind of thing that would be really difficult to do in Windows Forms because of the kind of graphics stuff you require. What you would have ended up doing is writing your own small version of WPF... Ah... Part of the reason that people like me are very enthusiastic about WPF because you Page 4 of 12

5 look at it, "Wow, this does all the sort of stuff that I've had to write time and time again in my own Windows Forms." You know, I will give you that, that's a good point. I haven't had to do a lot of thinking about graphics until the very end of this scanner thing. I mean ultimately my image control was handling resizing of the image, we ve dropped the resizable rubber bands on top of it and they really kind of just worked. place, yes. Once we got them in the right Once they were, so we'll talk about that, actually that's an interesting point, that the notion of the visual tree and we had these adorning layers on top of an image, these rubberbandable, scalable areas on top of the image. Yeah and we had asked WPF to resize the image for us but we haven't manage on ask it in such a way that it knew that we also wanted the adorners resized at the same time. So what was happening was, I'd have a scan and say like Ian's head shot and then I would resize the application, the head shot would resize but all my selection rectangles stayed small. And I said to myself, "Gosh, isn't this the kind of stuff WPF is supposed to do for me and you used the tool called Snoop." Snoop also let's you just go in and look at the visual tree and application, while it's running. So you can see what you've got because you end up, the visual tree changes... You initialize it with a XAML, with a whole bunch of stuff can happen at runtime to add new things and it's often difficult to know where things are in relation to each other but with Snoop, once you attach it to a process or a process for your American audience, we can just, you can just move the mouse point to over the thing you want, hit control+shift and it will expand this tree view. Showing you where you are and how you got there. C++, this is Spy++... So for the MFC people in the For WPF and was funny is that I've been pounding my head against the monitor for a number of hours over a number of weeks in my spare time, you popped out the right tool and said, "Oh" and within 5 minutes you realized that the thing that was doing the resizing did not know about my rectangles... And you just changed the XAML, you copied them in and suddenly things just worked. And that's one of these things where, with WPF I'm finding that it just works until it completely doesn't work. There was actually also an extra gotcha there which is probably worth talking about very quickly which is we had two elements, both of which were sort of doing that very polite British English thing of standing by a doorway and going, "No, after you." "No, after you." We had the image element and the view box were both offering to be as big as they needed to be. They're both saying, "Well, I could stretch to fill whatever space you've got and then you go on saying, well I can resize you to make you fit whatever space we've got and we actually had to tell one of them, "Look, just be this big." Do you know how to make the possible out of the impossible? Well the.net ninjas at Telerik do. They just released huge pack of web controls all built on top of ASP.NET Ajax that will help you build impossibly fast and interactive applications in no time at all. It made the impossible possible in desktop element, if you think you can't have a Carousel component in WinForms, well you can. Their Windows Forms suite features a super powerful grid view control and 32 other crazy desktop components that will give you dazzling WPF-like features but in WinForms. They do the same thing in reporting solutions with a new design service like nothing else looks just like graph paper. It gives you advanced page layout capabilities makes it feel more like a graphic design software than a reporting solution. Go check them out at telerik.com and be a.net ninja, thanks for listening. So that actually brings up an interesting point, we should talk a little bit about some of the basic elements in XAML, the ones that are most useful and I'll enumerate what I think they are and I'd like to understand, if someone were going to sit down in an application, they should think about the grid... Page 5 of 12

6 The view box. View box is important if you're dealing with kind of dynamically resizable stretchy things... does. fundamental... specific scenarios. canvas... If you're not then that's all it Oh okay. And I would not have that as Really? That's extremely useful for Okay, so then the grid and the Yeah, the canvas is also important I'd rank it below the grid, it's still important. Right now, I'm letting this, the grid hold all of my little selection items. Is that right? And I have no other data structures that know about that, I don't personally have a collection of selected photos... The view is holding this for me and I figured that was convenient. And when we want to find out what selections you actually have, we have to walk through the view to go and find all the controls in there. data... Since I don't own the I have to interrogate my view and hope that nothing horrible has happened. missing here? Okay, so what else am I I would say items control. And you're saying that the items control, maybe an item template would be a more appropriate way of doing that which would really split that logic... those. Items control, so let's talk about It's usually important and we're not using it yet and we should be. Uh huh. Okay, let's talk about the grid and the canvas and then talk about the items control and how that would change the structure of my application. So the grid is the single most important of the layout panels and panels are elements in the, elements that do layout, they contain multiple children and decide where to put them, that's their job. So the grid let's you basically carve the space up into rows and columns and position stuff and it may not sound like much but that turns out to be enough to do a huge range of different styles of layouts. Canvas is a different scenario where you don't want dynamically adaptable layout, that's when you want to say exactly where something is. So in the case of your little rectangle things, you want them to be in a precise location because the user drew the map and you don't want that to move just because the window changed size, so the canvas is great when you need to be in control. The showing and the knowing. Yes and the way I tend to think about it is, in terms of a projection, I was of two minds about using that term because there's something of the kind of computer science degree about it and it may scare people off but it is an important concept. But isn't it just Document View like we learned 20 years ago? It is but the relationship between those two things is a projectionist, taking information in one form and converting it into another form which is to say the view and it's understanding that it is a projection is important thing that is the nature of the relationship between the document and the view, so yes it is the same idea. I used the word projection partly because that also gets used in things like LINQ, LINQ to SQL, you project data from the query into the target. Page 6 of 12

7 It's essentially the same idea, you're running a transformation and the critical thing is you have some underlying information and then you transform that to get into the view. You sort of, rather than having the two be closely intertwined, to be unpleasantly intermingled to the extent that they are now. The data just is and then you're able to project that onto the screen, that's the job of the view. And Items Controls are important when you're dealing with multiple things because they won't let you take any collection and projects that into some things on the screen. Okay, so what you're saying is that I need to have a data structure that is not automatically drawn to the screen that actually says, "All right, selected items or selected photos or some appropriately named thing." They might have coordinates, they might have rotation and then they might have size and things like that really and whether or not they're selected I guess, even. And don't say anything about how they are to be displayed. Although it has no dependency on the view, it is very specifically for one particular view. That's a really interesting point, we should kind of talk about that for just a second, if it is intimate to the view, it is for the view, it is for no one else but the view but it has no dependencies on the view. Exactly. Okay, all right. So then, I've got this list that describes what I want to show but not how to do it? Yes and to be a little more specific and precise about that, it's not saying how it should be rendered, it is making certain commitments about what sorts of information will be visible. I like that, it's making commitments. It knows it's in.net, it knows it's going to be on the screen at some point, it may make a commitment just like, let say a coordinate system. Correct. They're just collections of numbers, basically a list of structures. Is that a reasonable commitment? Exactly, that sort of thing. And then what do I do? Actually, one thing that I want to point out there is the slightly tricky thing about this idea is that the, this thing which I would call the ViewModel does not depend on the view, it never goes and looks in the view, it never expects to find a bunch of controls, it's more passive than that, it provides... I can test it, I can talk to it, I can do whatever I want. Exactly. It's just a list of stuff. So you can fire up a unit test and you don't need to have the window there for it to work. How far should it go before it's committed too much? answer, actually. That's a very tricky question to An example would be like, let's say I'm going to display myself as red, do I use brush objects and different things that are specific to WPF and store those and hold those or is that knowing too much? I would say that is right on the margins, I certainly have done that and I have yet to come across a situation where I've regretted doing that and yet it makes me feel slightly uneasy. Because suddenly you're not just committing to basics like location but now you're starting to get into... You are bringing in user interface types... Page 7 of 12

8 To what you are exposing. Should I have my own, like what if I was to decide that, could I hold a button if I made a see? Now you're getting uncomfortable, I can tell in your face. enjoy it. I have done that and I didn't And actually the reason I did that was to work around an interesting feature of Silverlight where it was unable to do something for me but forgot exactly what that was. soul? But really; what price you're Yeah and actually for me, I think the big difference there, the reason the button pushes me over the edge is that the button is an interactive user interface entity. Unarguably. A brush is not, a brush is more of a descriptive thing, a brush says how you would like something to be painted in. And the view still has the freedom to decide what to do with that brush, where to paint it, it's a slightly different character of thing. own entity. A button is a bit too much of its Okay, so that gives us a sense of where to stop. So I've got this list of stuff and I want to describe exactly how to show it. Now in our example, I've got a list of selected rectangles and I want to display them all over this larger scanned image, how do I tell in the XAML to lay this out appropriately? I know how I did it at Baby Smash, I used an item template and I did some data binding. It was fairly inscrutable though the data binding syntax, I found it to be a little bit difficult. Okay, well, I would say in your application, a fundamental idea of the application to part of the whole purposes is to pick out points and regions on the image right? Exactly. I think it will make sense for your ViewModel to be exposing coordinates at some kind. And possibly, one of the jobs the ViewModel is going to have to do is to bridge between your underlying domain concept of this piece of the photograph and deal with specific issues like which kind of dots per inch are we dealing with? I've got a photograph of a 400 dots per inch resolution and I know that my view is going to be working in WPF's 96 dots per inch coordinate system. It's probably the ViewModel's job to bridge that kind of a gap, so probably makes sense for the ViewModel to be exposing numbers in WPF's coordinate system. That will represent where it is, what is the rotation angle is and how large it is? Then in the XAML, you actually would use a combination of an item template and also an item container style. And this is just kind of a technical trick that you have to do because the structure would be this, you have an items control bounds to your collection of selection areas in the photographs, so... Whatever that list is and then it's going to generate a child of the items control for each thing it finds in that data source. And you want to position that's based on whatever the coordinates coming out of the ViewModel say. controls is... So the XY of this item s Exactly and that's not a job for the view to decide. Now, generally speaking you'd say the position would be the views responsibility to decide. Right but in this instance, it's not because my model is this scanned photograph. I want to find the selected areas mapped into this Page 8 of 12

9 photograph and then I want to save off these walletsized photographs. Exactly, so this is definitely the domain of the model end through that the ViewModel. So you need to make sure the position is handled and the slightly complicated thing with the items control is that it generates the child items directly into whatever panel you tell it to, it could be a grid, it could be a canvas, in your case it would be a canvas because you need the precise positioning. But then it wraps them, it always has a kind of a wrapper type, each items control has a corresponding wrapper type. The list box has a list box item, the tree view has tree view item and so on. Okay, it makes sense. Because each different items control has its own behavior for its own generated items. Which gives you a problem, where do you set the canvas.top and canvas.left properties that determine where the thing appears in the canvas. Those only work one level up in the tree, you have to set them on the thing that is the child of the canvas. You can't set them on any old descendant of the canvas. So if I set the position on something on my item template, that's not going to work because my item template is actually hosted... I see, so where I appear is really within the context of my parent, my immediate parent? So if I want to put all these rectangles, I can't tell the rectangle go to the left here, I have to tell it go to the left within the context of your bounding parents. Exactly. So, essentially, what you need to do is tell the bounding parents where it's going to be. And you can do that at there's a thing called an item container style that lets you do that. The item container style basically says, "I want to be able to set properties on the things you're adding to my canvas." And that's where you do it. So that goes in one direction in the sense that I've got a collection of these things, I guess it would be an observable collection... Yup. And then I can describe in my styles and do some data binding and this will say that if I programmatically change the location of these, from the code behind kind of pointing upwards towards the screen, then they would move and then I've got interactions, I want to go and hook up mouse downs and mouse moves, I want to drag one of these controls around, how is that going to work? I pick up one of these selections and I drag it from left to right, is its coordinate really going to change? So that's going to have to start in the view, first of all, so you're going to add an event handler in the view because that's the only place where you can begin to get those events and then you would have your ViewModel expose a function that you call every time you get a mouse down, a mouse up, a mouse move. So my mouse move event is going to have one line which is go over here and tell that guy?. Which makes him annoying and pointless but tat means you can do exactly that same one line of code to fake up mouse input during unit testing, it makes it very easy to pretend, just give it fake user inputs. Ah, oh, it is interesting okay, good because I'm going to be delegating that, then I can fake mouse moves and test this. Exactly. Nice. Okay, so then what am I going to do then? I'm going to take from that mouse Page 9 of 12

10 event args, I'm going to take the new XY and I'm going to poke it back into the ViewModel? Which will then flow naturally back to the view automatically. Exactly, yes. Oh. And assuming I'm using observable properties with the INotify property change stuff... Okay, so... That will not just happen. I mentioned in our talk earlier that observable collection was just like the best thing within WPF, that's the thing you're going to find so useful all the time, what is it that's so great about observable collections? The really nice thing about it is that it means that if you've got just a collection of objects that are meaningful to your application and you add or remove or change the order of those things, you don't have to do anything to make the user interface update itself because WPF is able to capture all those changes. It just hooks up to the event handler, the items controls know how to do this and then go, "Oh, look." You just added a new item. I'll generate a new child, I'll build a new instance of the item template add it to the screen, so you just do one thing that makes perfect sense, add a new object to selected items and it just takes care of the rest. There's no need to do that manual sort of invalidate hwin stuff you used to have to do before. There must be a catch though, I mean, observable collection seem like magic, I've never had any threading problems with them, I'm always adding stuff, removing stuff from them and I could be and it just works. That will be because you've never tried to add another object from the wrong thread. Oh, I see, I'm getting lucky. Yes, if you try to modify an observable collection on a worker thread, you will get an exemption that says, this kind of collection view does not support changes on a thread other than the one that created it. How many threads are there in WPF and where are they living because I know how this works in WinForms? Very similar model. Oh! It's almost an identical model, in fact, there's one thread that even has to be an STA thread, the old COM single threaded apartment model thread because WPF interacts with things like ActiveX controls, the clipboard, it just has to be and that's the thread that all your events will be raised on, that's the thread that your constructors will be called on when the XAML is being loaded. Basically, WPF only ever shows you things on that thread. So WPF is intrinsically a single threaded model, if there other threads it's because you created them dispatcher? I see. So then, what is the The dispatcher is essentially the message loop. If you're coming from a Win32 background, it is the object that presents the programmable phase of the message processing in WPF. So it's not the actual win32 message but it is the, or is it? There is one under the covers, it's a little more complicated than that because WPF actually maintains two cues. There's the win32 cue which is an ordinary win32 message loop, and WPF pools messages off of that and puts them on it's own cue and then deal with it on it's own sweet time, partly because it wants to be able to reorder the events as they come in. It will prioritize certain things above input processing, for example, and that, by the way, is why you get the slightly bizarre repaint handling on resizing WPF applications, you may have noticed you get a little bit of blank space appearing temporarily when you resize a window it's because it's acknowledging the resize event before it actually really does anything with it and then the paints happen slightly out of sync with what's normally there. So there is a win32 message queue but it's not actually the main message queue in WPF and that s all sort of implementation details the dispatcher tries to hide as much about it as possible. But WPF I mean, how much of it is all new, fresh? I mean is it truly the windowing system for the future because if Explorer in Windows 7 isn't written in WPF and Office isn't written in WPF and Zune isn't written in WPF and Media Center isn't written in WPF, then what's it going to take for people to really believe that this is the next new thing? I mean is it going to take us writing Office 2020 in WPF Page 10 of 12

11 before people go, "All right, now they're serious. Look, Explorer is written in this thing." Well maybe you could at least try the develop tool in WPF. Oh, we are doing that, that's true Visual Studio 2010 is WPF. That's a pretty good start. But you know what I'm saying? I do. I mean there was, there were a couple of questions you kind fall in that... Sorry, yeah, I apologize. That was WPF credibility but also is WPG genuinely new. Which I think applies kind of, to it's credibility, I mean like I know for example that WinForms itself is a managed kind of thunking layer on top of win32 itself. forms? Is WPF a lie on top of Win No. Or is it a whole new thing? Well, it's a lye on top of other things, so the input handling is still the same because there is only one way to get mouse, keyboard, stylus input from Windows and that's through the message queue. So it has to interact with that but it does not use the GDI rendering system or the GDI plus, it doesn't use device context, instead it's a lye built on top of DirectX. Okay and that's why I can get faster if you have a better video card? Yes and it also has a completely different approach to composing over different pieces of the UI on to the screen which is why you can do things like sort of partial transparency and overlap, all those sorts of things that were a pain to get right and visually interesting applications in Windows Forms. So it is a genuinely new rendering engine, the user, event input processing is based on what was there before because otherwise, they couldn't go to work on Windows XP fundamentally. Oh, I see. So, as for the credibility, I think Visual Studio being built in WPF is going to be a big deal not just for WPS credibility but also for WPF's own good. The fact that the developer division for Microsoft is building their own stuff on top of WPF means that there's a lot of work is going to have to be done. They'll find problems they probably would not have found otherwise by working through it. Making something this big and this complicated and then the entire, the editor is all WPF... Yup. The menus are all WPF... Add ins are going to be in WPF, it's really going to make WPF better. I assume that they're finding error, I think there was some discussion about performance, they're improving font rendering, all of this is just going to make WPF and.net 4 and going forward better, I hope. I mean it really has to and it is interesting if you look at what's new in WPF, on the face of it in version 4 there doesn't seem to be a big kind of over-arching theme and I did a talk here this week and I felt a bit embarrassed because I was basically talking about 15 unrelated things. But on the other hand, it's kind of the sign of it maturing as a platform... of needed doing. I see. It's many little things that kind I mentioned it too, I was like, "Hey, there's a grid control!" And then silence. things on the inside. But there are a million little There are lots of tiny things. Page 11 of 12

12 So there's text rendering, there's graphics performance improvements, better integration with DirectX and XNA, there's the ribbon control, better shell integration so you can get hold of the properties of stuff and define stuff and find out what icons there are. You can interact properly, at last, with Windows Vista and Windows 7 dialogues. All right. This is now to be known, I want to let all the listeners know that this is the Griffiths WPF book and you're also a WPF consultant and people can find you on the web. So I have a blog IANG, that's short for Ian Griffiths; IANG on tap is what my blog says, so you can find it. IANG on tap? It's fit and finished, polished. Exactly. There's all sort of stuff where you probably would go, "Oh, did it not already do that?" But this is exactly the sort of thing you would expect once Microsoft starts building real applications on top of it and I would say that probably if you look at it from products like Office's point of view, that team in Microsoft could easily say, "Well, we're not going to do it until Developer Division has built their own stuff on top of it." Well thanks so much IANG on tap for sitting down with me here and talking with me about WPF. It's been a pleasure. This has been another episode of Hanselminutes and I'll see you again next week. yeah. order. there. Sells. That's a good point, okay, So it has to happen in that Chicken and the egg, situation So you wrote a book? I co-wrote a book with Chris With Chris Sells. Which is known slightly annoyingly as the Sells WPF book... Yeah, all right, I apologize. Yeah, it's a problem, you wrote a lot of it. than half of it. I wrote slightly more And that book is called? That is called, Programming WPF, it's published by O'Riley, it's currently in the second edition we will be doing a third edition for WPF Version 4... I'm working on that later this year, I don't have a ship day for that yet. Page 12 of 12