The team blog of the Expression Blend and Design
Today at PDC, we made a few announcements that would be of interest to you! First, Scott Guthrie announced the availability of the Silverlight 4 Beta. This version of Silverlight contains some cool new features that many of you have asked for, so read the What’s New document to get an overview of some of the new features.
To coincide with the release of Silverlight 4 Beta today and the release of Visual Studio 2010 Beta 2 a short while ago, we are making a version of Expression Blend available that allows you to work with .NET 4 and Silverlight 4 based projects.
Download it from the following location now:
This release of Expression Blend works well alongside Expression Blend 3, so you can continue to work on your WPF 3.5 and Silverlight 3 based projects at the same time.
As always, we love to hear from you. Please feel free to comment below or use our forums here.
- The Expression Blend Team
Ok, pop-quiz time. Below, you will find two screenshots I took from two different applications:
[ Screenshot 1 ]
[ Screenshot 2 ]
Can you tell what is different between those two images? If you said that the button in the second image seems a few pixels off from the image on the top (or something similar), you are wrong. The UI depicted in both of the screenshots is exactly the same. Yes, it was a trick question.
While both applications look almost the same when run, let’s look at both of these applications when opened in Blend. Here is what the application depicted in Screenshot 1 looks like:
The application depicted in Screenshot 2 looks as follows:
As you can tell, there is a major discrepancy between the first and second screenshot when viewed in Blend. More specifically, the second version of the application seems to be missing some UI and the button is not styled at all.
What Happened? The source of the discrepancies have to do with what Blend actually shows on the design surface. By and large, Blend is a XAML editor. Anything defined in XAML, we will do our best to display it on our design surface. For visuals defined in your code-behind files, you may not always be able to see them in Blend.
This is where the differences between the two apps stems from. In the first app, everything was defined in XAML. In the second app, some of the visuals were defined in XAML, but a many of the visuals were not. That is why Blend is only showing an incomplete subset of what your application actually looks like when you view it on the design surface. This is a problem.
Why is this a problem? The word “problem” may be a harsh word for this, but the outcome is less than ideal if your application is a collaborative effort between someone technical and someone less technical. If you are a developer, being able to visualize code and make changes may be straightforward. If you are more design oriented, looking at code to define the look and feel of an application is not natural. You would prefer something that looks like the application depicted in Screenshot 1 where everything is exposed in Blend’s design surface and you can make changes visually without writing code.
Some Solutions The first and obvious answer that I have is to have you resist the temptation to add controls, define layout, or perform other visual tasks using code. The reason is that, as you saw in the screenshot of the second application, Blend’s design surface won’t be able to help you out.
Of course, there are many cases where such an extreme solution will not work. It is common for many applications to fall into a gray area where visuals are partly defined in XAML and partly defined in code. Fortunately, there are some simple steps you can take to make designers more productive while still giving developers the flexibility to develop the application.
Use UserControls If you have visual content that needs to be added programmatically, make sure that content is defined as UserControls. The reason is that you can define the UserControl and make changes entirely within Blend. Programmatically, you can add this UserControl – which may have been edited inside Blend – to your application without sacrificing the designability of the UserControl itself.
Create Styles in XAML, Apply them Programmatically Sometimes, UserControls may be a bit excessive. For example, in the second screenshot, I have a button that is unstyled:
Instead of having a dedicated UserControl to wrap your styled button, you could just define the style in Blend and programmatically apply the style. Let’s say you have a style called GreenButtonStyle defined in your Resources panel:
To apply this style to your button, use the following code:
This allows you to still define the look and feel of your Button using Blend, but its application is handled entirely via code.
Conclusion Hopefully this post helped give you some ideas on how to ensure the visuals of your application have the ability to be modified by Blend. I didn’t enumerate all of the various cases, but if there is something clever that you do to enable developers and designers to work together, please comment below.
Cheers! Kirupa :-)
One of the goals of Silverlight’s Visual State Manager technology is to let you do quite a bit of control customization without needing to use Blend’s Timeline, nor even having to know what a Storyboard is! Feel free to test-drive the Silverlight Button below, and then read on for a run-down of how easily it can be built.
I started out with some vectors (Paths) depicting the face in its normal resting state. Then I used the Tools > Make Into Control command to make the artwork into a template applied to an actual Button. After deleting the ContentPresenter from the template, I selected the MouseOver state in the States pane, so that the changes I was about to make to the existing elements (to produce a face that looks alert and ready) would be recorded only in the MouseOver state. I moved the head and the features upward a little, and the rest of the changes involved using the Direct Selection tool to move Path points around.
Because I wanted the Pressed state to be a variation on the MouseOver state, I used the Tools > Copy State To command to duplicate all my changes into the Pressed State. Then, with the Pressed state selected, I adjusted one eye and the mouth to make the wink.
For the Disabled state I decided I needed new graphics instead of adjusting properties of the existing graphics. So I created a simplified grayscale version of the face and made that version opaque only in the Disabled state.
For transition timing, I created a number of transitions to and from various states and set their durations to taste.
Finally, so that each Button instance can customize some aspect of the template, I used template bindings so that Brush colors used in the template to draw various pieces of the face are bound to properties of the Button instance. So for example I selected shoulders, then selected Fill in the property inspector, and then clicked Advanced property options > Template Binding > Background. So now, by setting a value for Background, Foreground, BorderBrush and OpacityMask, a Button instance with this style set on it can determine the colors of the shoulders, face, hair, eyes and nose.
You can download the sample project files here.
Hi everyone, When using Expression Blend, a common task you probably engage in is working with layout. Tasks I commonly associate with “working with layout” involve moving things around, rearranging the order of elements, ensuring everything flows when resized, changing your layout container, etc. For the most part, the changes you make to the layout of your application are pretty harmless…except when it involves DataContexts.
In a nutshell, data contexts allow you to specify the data that elements can inherit and work with. Seems pretty harmless so far. Data contexts can be set on pretty much anything, but because the data is inherited, data contexts are often placed on parent elements (such as a layout container) whose children will inherit the data:
What seemed harmless earlier now has the potential to cause trouble. Because data contexts are often placed on a layout container, and because data contexts primarily benefit any children listening in, you need to ensure that any layout changes you make do not cause your data context to break. The common ways your data context can break are:
Today, Blend does not let you know when you perform a layout operation that breaks data context. It is up to you to be vigilant, and you can see which element has a data context set on it by looking at its DataContext property:
If this property isn’t empty, it means that a data context has been set on it. While having a data context set should not imply that data is actually being used, it is a good gauge on whether a layout operation you perform will have any negative side effects on the children involved.
Cheers! Kirupa =)