Archive
XAML Formatting in Visual Studio
A question came up last night at RVNUG about manually editing XAML, something I avoid as much as reasonably possible. When I have to edit XAML though, I almost always jump over to Visual Studio, so I was asked why I prefer to edit XAML in Visual Studio over the Blend editor. Besides the fact that I’ve always just done it that way because originally we did not have Intellisense in Blend, I have two other reasons.
The first reason is that I use Blend to write XAML and Visual Studio to code XAML. It sounds like splitting hairs, but let me explain. Blend is the best darn XAML Editor ever written, primarily because it allows me to write and edit XAML without actually typing the XAML. It magically translates the design I have on the screen into it’s XAML representation: that’s what makes it so awesome. When I find a situation where I actually need to code the XAML and make textual changes to it myself, then I use Visual Studio, because it is the best darn Code Editor ever written. To sum up: Design = Blend, Code = Visual Studio.
The second reason is far less highbrow: I dislike the default XAML formatting that Blend produces. Don’t get me wrong, the XAML code itself is wonderful, almost pristine, but it compresses it to as few lines as possible. That means lots of properties on a single line, which becomes an issue when you have a bunch of properties full of Binding references and more complicated structures. So my preference is to see one property per line in the XAML. This makes it much more palatable on those rare moments when I must code the XAML manually.
Setting up Visual Studio
I saw the question today on the Expression Blend forums about how to get Blend or Visual Studio to do exactly that, so I thought I would put up a quick post for the archives.
While Blend cannot format the XAML in this fashion, Visual Studio can:
- In VS2008 or VS2010 go to Tools –> Options
- Expand Text Editor -> XAML -> Formatting –> Spacing
- Under "Attribute Spacing" check "Position each attribute on separate line".
- If you prefer, you can also put the first attribute on the same line as the tag by checking the box. I use this setting because it isn’t offensive and still saves a little space.
Now, whenever you edit XAML in Visual Studio, press "Ctrl+K+D" and Visual Studio will reformat the XAML as desired.
Enjoy!
Is The Blend 3 Trial Worth The Download?
If you’ve spoken with me at any time over the last year at a technical conference or User Group you’ll know that I can’t go more than a few minutes without mentioning Microsoft Expression Blend.
I was first introduced to WPF in 2006 and I was stunned by the results. I couldn’t wait to try it myself, but at the time all I saw was XAML, and frankly I had no desire to develop business apps in markup. Fortunately, in 2007 I saw Blend 1.0 and the flood gates opened: I had to have it, and I soon did. Since then I have become a Blend evangelist. It is my mission to preach the rich chocolaty goodness of Blend to all the people of the land.
OK, that may seem overkill, but in all honesty I cannot see developing WPF or Silverlight apps without Blend. If I had to code strictly in XAML I would still be a Windows Forms developer. Don’t get me wrong, plenty of people have done meaningful work without Blend, but I would never be one of them.
Is the Blend 3 trial worth the download?
Naturally, Blend is my current topic of choice for presentations, and I get plenty of questions about Blend from fellow developers. This morning I received a question that I thought deserved sharing:
Are the blend 3 features worth the trouble of installing the trial version? Or wait for the official release?
This is a great question! The requestor is currently using Blend 2 and wants to know if the updates from Blend 2 to Blend 3 are so awesome that they must have them now, or can they wait until GA.
My answer is, in typically non-committal fashion, “it depends.”
If you are dabbling with Blend and WPF or Silverlight 2, then you do not need to rush out and try Blend 3. Don’t get me wrong, you could still benefit from it, but I wouldn’t consider it urgent. You can wait for the RTM.
[NOTE: If you are working on Silverlight 2, be sure to read all the warning labels before moving to Silverlight 3: you can’t go backwards once you install the Silverlight Tools for VS 2008. In your case, you need to wait for VS2010, which is supposed to allow both environments.]
If you are a dedicated WPF or Silverlight developer/designer, by which I mean the bulk of your projects fall into one of these two categories, then by all means you should be using Blend 3 already. You can install Blend 3 alongside Blend 2 with no ill effects.
My Favorite Features
I spend a great deal of my time in Blend, and now even more so with Blend 3. Here are the list of features I use the most in Blend 3:
- Vastly improved Data tab (including SampleDataSource and easier databinding)
- VSM for WPF (mostly built in, still need to add a reference to WpfToolkit.dll)
- Artboard integration is finally usable – you can actually click on
the element you want to use - The BreadCrumb makes working with Templates a lot easier
- Code Editor – now you can edit C# inside Blend, including Intellisense. I don’t advocate it for serious coding, but simple changes and events are quite feasible
There are probably more, but these are the ones that seem to most enhance my daily experience. There are, of course, some bigger fish to fry that I have yet to really take advantage of like Behaviors and SketchFlow.
Conclusion
If you are in a position to do so, I would try Blend 3. Trial downloads of Expression Studio 3 are available for 60 days, and pre-order purchasing is currently available.
I’ll be writing more about these features in future posts. I’d like to add some Video Tutorial too, so feel free to leave requests in the comments below.
WPF Visual State Manager
Last night at RVNUG, a friend of mine pointed me to The WPF Toolkit. The toolkit is a collection of controls and features that extend the current WPF offering from Microsoft. Chief among these is the DataGrid control, but something more appealing caught my eye: Visual State Manager.
Basically, the VSM is a very easy to use feature of Blend 2 SP1 that supports Silverlight 2. It allows the developer to easily set the visual state of user controls and control templates based on the current state of the control, such as MouseOver and Pressed. I had seen this when I was exploring Silverlight 2 in Blend 2, but I’ve been focusing on WPF and was curious as to why I didn’t have the same functionality I had seen in Silverlight. Of course, now I know: VSM is currently only included as part of Blend 2 for Silverlight 2 development. But, if you install the WPF Toolkit and follow the instructions in the link above to update your Registry, you can gain access to the same basic functionality for WPF Applications.
Using VSM in WPF
Previously, these state changes could be accomplished using Storyboards and Timelines, and then assigning their beginning and ending to Triggers. The Timeline tool in Blend is robust and feature rich, but I think for a non-graphically oriented developer it can be more than a little daunting. And it seems to be overkill for simple animations. That’s where VSM comes in: it greatly simplifies the task of adding small animations to element states.
The Silverlight implementation is very nice and intuitive right out of the box: the states are already defined and all you have to do is activate one and make your changes to the art board. Unfortunately, the current version for WPF is not as straightforward. In WPF, once you have the State manager visible, you have to create the State Groups and define the Visual States you wish to modify. Once I figured out what was going on, this is not painful by any means, but it took some trial and error to get it working right. Don’t forget to add a reference to %Program Files%\WPF\WPF Toolkit\…\WPFToolkit.dll to each project in which you wish to use VSM. Trust me, it will save you a lot of heartache!
So first things first, we need something that VSM can interact with. Since VSM cannot be applied to the default template of a control, we need to create our own. For this article, I created a button and then created an empty template. Once you create the template, either by ‘edit a copy’ or ‘create empty’, the States Manager will appear under the Triggers Manager on the left hand pane. At this point, the only item visible in the States Manager is Base. You can go ahead and create the default look of your template at this point.
Set up the State Manager pane
To begin with we need a Visual State Group to hold our Visual States. In the Top Border of the States Manager pane on the far right side is a small icon with a plus sign on it. Hovering over it will reveal that this is the “Add state group tool. Pushing it will create a new Visual State Group header under Base. Click on the title (VisualStateGroup) and rename it as you see fit. I’m not sure that the group names matter, but to be on the safe side I followed the same scheme that Silverlight reveals and called my first one “CommonStates”.
Now that we have a group to hold our collection of Visual States, we can start adding states. On the CommonStates header bar is another icon with a plus symbol: this is the “Add state” button, so press it to add a new state. Rename VisualState to the desired state. The state names do matter if we are to get the desired result, so I added three typical states: Normal, MouseOver, and Pressed.
Altered States
Now that we have all the missing pieces defined, we can use them just as we do in Silverlight 2. Clicking on the desired state in the State Manager pane will turn on State Recording [as indicated by the red border around the art board and the header message “State recording is on”]. Now you can easily adjust the display elements of the content to whatever you want them to be at that particular state. A classic example would be brightening a button on MouseOver.
When you are done editing the visual elements, click on Base in the State Manager pane to exit state recording mode. It is important that you do this, because otherwise you could easily alter just a given state when you think you are altering the control template itself. Take it from me, this is very frustrating when you do not receive the results you expect. And then, of course, to correct it you need to back all of your changes out and reapply them outside of state recording mode.
Adding transitions
If you have done all of the above, your button should be changing its visual appearance when you mouse over or press the button. You may think this is the end, but wait, there’s more! Leaving it as above will force the change from one state to another to happen immediately. While we have become accustomed to such UI, it is not the most pleasing effect. Instead, users react much better to very slight, more realistic animations. In other words our users will find our software more appealing if it takes a little time to change from one state to another. These quick, smooth changes from one state to another are very short and simple animations called “Transitions”.
To add a Transition, find the Visual State (such as “MouseOver”) in the State Manager pane and look to the right side of the header bar. There you will find an arrow icon adorned with a plus symbol (notice a pattern developing here?) Click on that and a helper window will appear with a collection of Transitions you can modify. In my case, I chose the two with the ‘*’. The one with the * on the left side indicates the transition from any other state to the selected state, and the one with the * on the right indicates the transition from the selected state to any other state.
Clicking on the desired Transition will add it beneath the selected state. On the Transition you will find a text box that lets you enter the desired amount of time you wish the particular Transition to take. The available range is 0 to 1 second. It doesn’t take much for our Transition to have the desired effect, so try .1 or .2s at first to get the feel for it, then adjust as you desire.
Conclusions
Now when you run your project, you should detect the pleasing effects of Transitions. Overall, I find this much much easier than Storyboards and traditional animations. I’m sure that eventually the tooling for WPF Applications will improve to match what is in Silverlight, but overall it is a minor complaint. I want to thank the CodePlex guys for letting us in on this great secret!
My first real WPF and Blend 2 application
I’ve been familiar with WPF since December 2006 and the release of C# 3.0, and I’ve had Expression Suite installed for almost a year. While I’ve toyed with it here and there, I have never devoted the time and effort necessary to really begin to become proficient.
However, since last week’s Silverlight 2.0 release, I have been burying myself again in learning new technologies. I finally decided to take the plunge, so I installed Silverlight 2.0, the Visual Studio updates, and upgraded to Expression Suite 2 SP1. I spent a couple of days going through ScottGu’s tutorials and some others on Silverlight.net. I followed along and built the samples, some in Visual Studio and some in Blend.
Most of these have been around for a while, so I’m not claiming any kind of leading edge stuff here. What I wanted to do was to share some of the insights I’ve had in attempting this project.
What’s the big deal
XAML marks a sea change in how user interfaces are developed. The end result of XAML is still .NET objects, and as such they can be created and managed programmaticaly, but the ability to simply describe what you want is very attractive. For a long time, I did not like XAML itself, and one of my reasons for putting off learning WPF was that I wanted to wait until something like Blend made all XAML interaction obsolete. After diving in for a few days, I no longer feel that way, but I’ll share more about that later.
What really makes all this so attractive is the ability to do basically whatever I can imagine for an interface. More importantly, I can do it without a ton of hand coded control drawing, something I never liked doing in the first place. The behavior of a control truly is separate from its presentation, and the presentation can be altered or replaced in any number of ways. In other words, you can achieve some pretty cool effects with a reasonably small effort.
Visual Studio or Blend?
I’ve been having an ongoing discussion with a friend of mine at RVNUG about the usefulness of writing WPF applications within Visual Studio. Having seen some demos and had some training on Blend, I was staunchly in the Blend corner on this one. While you can drag and drop controls in Visual Studio, it takes a lot of hands on XAML coding to get anything more than a rudimentary window up and running. As I mentioned previously, after seeing some XAML presentations I really wanted to avoid that as much as possible, which is what makes Blend so intriguing.
But, having gone through ScottGu’s Silverlight tutorial and building an application in Visual Studio, I have a better appreciation for it now. One thing I do like about using Visual Studio is that it is keyboard centric. As a classic Midrange developer I have always shied away from using the mouse as much as possible, so it appeals to my keyboard-philia. And of course, Intellisense is still the killer feature and makes it much more palatable. Also, as a seasoned and grizzled web developer who still likes the occasional dip into VI and Notepad, it only took a little time with XAML to feel comfortable with what was going on. Anyone familiar with XHTML and CSS should find XAML completely doable. It is, of course, a lot more complex, with numerous options and quirks, but it is still familiar territory.
Now, all that being said, I still prefer Blend 5 to 1 over Visual Studio for Visual XAML development. I have only run into a few things that I couldn’t accomplish easily through Blend, and I’m new enough to it that I still chalk it up to just not knowing the tool well enough. Applying and developing styles is still one of these areas: I so far have not figured out how to do them in Blend, so I revert to XAML editing.
Which brings me to my question of the day: “Should I use Visual Studio or Blend?” The answer is a resounding “both!” OK, I’m sure you saw that one coming, but let me explain my position. If you are a developer, there is no question that you are going to use Visual Studio. After all, it is our bread and butter, and all the real code will still be developed in our beloved IDE. But designing serious WPF solutions in Visual Studio would be far too painful, even with great Intellisense support. There are simply too many options to have to code them by hand.
It reminds me of my first Windows application: a Java Swing application that I wrote in Wordpad. Believe me, the pain of that experience made me instantly recognize the value of Visual Studio and is largely responsible for my shift to Microsoft technologies. On the same order, as soon as I saw Blend I knew that this was the tool I needed to design good WPF applications. So, for layout and Visual Tree management, use Blend. When you find a problem that you think you must solve using XAML editing, switch over to Visual Studio and take advantage of Intellisense, which Blend does not have.
Quirks
A couple of things so far have jumped out at me. While Blend and Visual Studio do a pretty good job of keeping each other in synch, there are a couple of irregularities.
The first real problem I had was in adding existing projects to my solution in Visual Studio. I started my solution in Visual Studio and then opened it up in Blend to work on the design. Later in the same session, I went back to Visual Studio and added several projects. Now that I had some CLR objects to work with, I wanted to try Data Binding, so I followed one of the online tutorials but no joy. No matter what I did, I could not get Blend to find the objects. Every time I tried, I received a slew of “file could not be located” errors. Finally, I restarted Blend and when I opened my solution, there the missing objects were.
Second, there have been several times when I’m not sure that I am being properly prompted to reload. I could be imagining it, but I feel pretty strongly that I have made changes in one without being prompted by the other to reload them. Perhaps this is just a matter of timing Saves.
Conclusion
Well, I don’t really have any as of yet. I do think that a lot of developers are going to struggle against the designer learning curve, yours truly included. But I think in the long run we will be much better off. So far, I am pleased with my efforts. I like the combination of resources the two applications provide me, and I amd getting more comfortable in deciding which to use for certain scenarios.
I’m not quite ready for a tutorial series, but I will try to share some of my learning with you all as I go. In the meantime, give it a try yourself and let us know what you think. Happy Coding!
Developing For .NET 