I've been with the team for 6 and a half years now, and Blend continues to be something I'm very passionate about. To be completely honest, since I wasn't a big Silverlight fanatic, the jump from Blend v1 to Blend v2 didn't feel like a huge jump. Yes, there were TONS of under-the-cover changes that went into the product, so it could support Silverlight and things like that... but the jump from v2 to v3 is TREMENDOUS. Sketchflow is awesome. Silverlight support is awesome. Behaviors are awesome. Sample Data is awesome. I can go on for days, believe me. (In fact, if you look at all the training classes and things I've done internally, I *HAVE* gone on for days).

Grab it. Check it out. Let me know what you think.

Time to change the world. Again :).

First off, what is a DrawingBrush? It's one of the three kinds of TileBrushes that WPF recognizes (along with ImageBrush and VisualBrush). Simply put, it allows you to use a Drawing as a brush, to use on any arbitrary shape.

So, what's a Drawing? A Drawing is simply a set of Visual Elements. You can use pretty much any visuals, rectangles, buttons, Images, etc... but once they become a Drawing, they are no longer interactive. In other words, you can use a Button in a Drawing, but it becomes a 'picture' of a Button, not a real button that can take events, rollover effects, etc... A Drawing is also static. You can't really change it after the fact (Ok, you MAY be able to do it withing code, but I've never tried that).

And, well, since Blend is my area of expertise, I'll demonstrate how to do it with Blend.

(Advance warning... as of right now, Silverlight doesn't support Drawing Brushes, so until they do, this post is only for the WPF crowd, but since we keep seeing more and more of WPF's capabilities moved into Silverlight, it wouldn't surprise me to see DrawingBrushes over there eventually. Also, no, I don't know of any specific plans to move DrawingBrush into Silverlight, and it's possible they never will... I can't tell the future, and I'm not actually on the Silverlight product team).

So, go ahead and fire up Blend and create a WPF Project.

Using the Rectangle Tool, create a rectangle that is 200x100 pixels. Remove the Stroke and set the Fill to a 50% Alpha Red. (#7FFF0000).

Copy and Paste that rectangle, and place the new rectangle adjacent to the first, so it looks like you have a square. Set the Fill of the new Rectangle to have a Fill of 50% Alpha White (#7FFFFFFF).

You should have something like what I'm showing here:

Ok, now group those two rectangles into a Canvas. (You can do Grid too, if you prefer. It really doesn't matter).

Copy and Paste the Canvas, then rotate it 90 degrees. You should start to get an idea of the effect we're looking for here. (Anyone want to go out for pizza?)

To create a DrawingBrush, you need a single base element, and Blend will take all the children and move them into the DrawingBrush for you. At the moment, the two Canvas elements are siblings, and their only parent is the LayoutRoot, which isn't going to work. So, group the two Canvas elements into another Canvas. The visual tree should look like this:

Now, select that base Canvas (the one I have selected in the image above), and in the Tools Menu, select "Make Brush Resource" and "Make Drawing Brush". You're going to get the "Create Resource" dialog, since TileBrushes are handled, by Blend, as resources. Go ahead and set the name and scope to whatever you want and hit Ok.

If it looks like nothing happened, that's Ok. What it did was copy all of the contents of the selected Rectangle and create a Drawing out of them, and create a resource for you. If you don't believe me, switch over to the Resources pane, and look for the Drawing Brush.

In fact, now, we don't even need the original canvas any more, so go ahead and delete it.

Now draw a nice big rectangle (or you could even use your LayoutRoot, if you wanted to).

Go to the Property Inspector, and set the Fill to the new DrawingBrush. It should paint your rectangle with our red cross hatch. Grab the BrushTransform tool, and your rectangle's corner adorners will show up, just as if you were going to resize it. However, when you grab the bottom right adorner and drag it up, you'll see that you're resizing the BRUSH, and not the whole rectangle. That's exactly what you want. In the Image below, I've given my rectangle a thick, black stroke, so you can see that I've resized the FILL, and not the whole rectangle.

You'll also notice that as soon as you do this, you'll break the connection from the DrawingBrush resource. That's Ok. The Resource is of the two rectangles at a specific size, and in this case, we want to have our brush tile for us.

The final step is to set the TileMode on the Fill to Tile. You can also use the BrushTransform tool to mess with the Brush a bit more... maybe rotate it or give it a skew, and you'll get something like this:

There you have it. You can continue to experiment... try taking the Stroke off the rectangle you just made, and convert *IT* into a Drawing Brush, and reuse it. Maybe try with a FlipXY, and you can get wild pretty quickly. Here's a quick example of something I threw together using two rectangles and an ellipse, and just keep reusing the "Make Drawing Brush" command with the Brush Transform tool.

Now, a feature that some folks probably don't know about, is that you can actually edit a DrawingBrush after the fact. To do so, follow these instructions:

Switch to the Resources pane.

Drag the DrawingBrush that you want to edit to the artboard. You'll get a context menu as normal, but there's an option to "Copy DrawingBrush to Canvas". When you do this, you'll get a Canvas with your DrawingBrush exactly as it was before you made it into a DrawingBrush at the beginning.

Go ahead and make any changes you want. (Maybe if you were following the steps here, you'll want to change the 50% white rectangle to a completely empty rectangle, which will change the visuals slightly.

When you're done, right click the BASE canvas that was created, in the Timeline, and you'll find commands for "Move into Source DrawingBrush" or "Copy into Source DrawingBrush". If you choose Move, the canvas that was created will be destroyed, but the information will be moved into your resource. If you choose Copy, it will update the resource, but not delete your Canvas. This latter option is helpful if you just want tweak your brush, see how it looks, and so on.

Remember, though, that as soon as you used the Brush Transform tool, it broke the resource connection, so if you followed THESE steps, you're not going to see it update immediately in the full tablecloth, but you should be able to take the updated DrawingBrush and go through the last steps pretty easily.

Have fun with it!

Last month ago, I got the opportunity to present at the Cre8 summit in Orlando. I gave two presentations, one on Sketchflow in Expression Blend and one on Blend in general. I was also given the chance to give a keynote during lunch on the second day to show off Sketchflow.

I have to say, that this was one of the most nerve wracking things I've done, speaking to a community of Designers who are still only starting to look at Microsoft products seriously for Web Design. Every eye was on me, and I'm quite happy with how Blend behaved for me. I had plenty of folks compliment the speech, and they were shocked when they heard it was my first.

Blend is really starting to take a serious turn toward being a real competitor. I can feel that by the questions I get asked when I'm talking to folks. We're getting less of the "So, what is this all about?" questions, and more people asking about specifics like Silverlight penetration and the relative complexities between making a prototype in Sketchflow versus working in Visio or Powerpoint. It's building a lot more excitement, and that's just awesome to be a part of.

Recently, I also got a chance to go visit ZAAZ here in Seattle. These are folks who do both Silverlight and Flash development, but they're looking at Sketchflow for doing prototypes in either environment. The most priceless moment was when I was showing off Behaviors in Sketchflow, and one of the designers looked up and said "That f***ing rocks!" It's one thing to work six years on a product, and know in your heart how great it is, and how much it's going to change the landscape, but to have someone looking at it for the first time put it into words... it's a real thrill.

We're doing more internal training classes. More folks are getting interested, and the momentum is really building. I can't wait to unleash this one.

And yes, I'm going to get back on the technical tricks very soon. I've been getting some good questions on DrawingBrush, and there's some functionality that isn't as discoverable as I'd like.

We’ve been talking a lot to designers about what they want, and one thing I keep hearing is a desire for Tracking and Kerning. Currently, Silverlight doesn’t really support those, and there really isn’t an easy way to do it.

So, on the bus this morning, I started thinking, and this is what I came up with. As always, feel free to use any code here that you like, but use at your own risk. I’m certainly up for hearing possible improvements on it. Right now, this only does Tracking, but I’m trying to figure out how to do the kerning as well.

So, naturally, I’m doing this in Blend (not a huge surprise), but I want to do this in Silverlight. So, I’m creating a new Silverlight project, and I’m going to be creating a custom control. Start off by drawing a TextBlock, selecting it, and choose “Make User Control”. Blend will ask you for a name, and I chose “KerningTextBlock”.

Here’s my strategy. I’m going to use a StackPanel to take care of lining up all my characters, and create TextBlocks for EACH character. Then, set the padding on those TextBlocks to increase the space uniformly between consecutive characters.

So, get rid of the TextBlock that’s already there, and drop in a StackPanel. Rename that StackPanel since we’re going to be interacting with it in code. I named it “TextDisplay”, since that made sense to me. Also, set the Width and Height to Auto and set the Orientation to Horizontal.

Cool, now I want to create two DependencyProperties on our control, and that means code. So, open up the Solution in VS, and let’s get cracking. I want to implement “ActualText” as a string, so I can set it in one place, and have the StackPanel create it’s TextBlocks, and then a “Tracking” as a double that I can set and see the results.

First, the ActualText:

public static readonly DependencyProperty ActualTextProperty = DependencyProperty.Register("ActualText", typeof(string), typeof(KerningTextBlock), new PropertyMetadata(ActualTextValueChanged));

public string ActualText

{

      get

      {

            return (string)GetValue(ActualTextProperty);

      }

      set

      {

            SetValue(ActualTextProperty, value);

      }

}

private static void ActualTextValueChanged(DependencyObject caller, DependencyPropertyChangedEventArgs e)

{

}

This is all pretty much “boilerplate” code. I can use “ActualText” to get and set the property, and every time it changes, ActualTextValueChanged will get called. I’ll use that later to update the contents of my StackPanel.

Next, let’s go ahead and get Tracking:

public static readonly DependencyProperty TrackingProperty = DependencyProperty.Register("Tracking", typeof(double), typeof(KerningTextBlock), new PropertyMetadata(TrackingValueChanged));

public double Tracking

{

      get

      {

            return (double)GetValue(TrackingProperty);

      }

      set

      {

            SetValue(TrackingProperty, value);

      }

}

private static void TrackingValueChanged(DependencyObject caller, DependencyPropertyChangedEventArgs e)

{

}

All right, we’ve got our DPs, now let’s hook them up. For starters, let’s do the ActualText. Whenever it gets changed, we want to clear out the children of the TextDisplay StackPanel, and add new TextBlocks for each character. Here’s the code, and I’ll go through it after:

private static void ActualTextValueChanged(DependencyObject caller, DependencyPropertyChangedEventArgs e)

{

      StackPanel textDisplay = ((KerningTextBlock)caller).TextDisplay;

      textDisplay.Children.Clear();

      foreach (char thisChar in e.NewValue.ToString().ToCharArray())

      {

            TextBlock newTextBlock = new TextBlock();

            newTextBlock.Text = thisChar.ToString();

            newTextBlock.Padding = new Thickness(0, 0, ((KerningTextBlock)caller).Tracking, 0);

            textDisplay.Children.Add(newTextBlock);

      }

}

So, what am I doing here? First, I’m grabbing the TextDisplay control. Since the method is static, I can’t simply go to “this.TextDisplay”. But, “caller” is the my KerningTextBlock, and all I need to do is cast it to KerningTextBlock and get my control.

Once I’ve got the TextDisplay, I’m going to empty it, with the Children.Clear command.

Finally, I’m going to iterate through each character in the new value, and create a new TextBlock for it. Those TextBlocks are going to get the character as their text, and set the Padding on it to my Tracking property. If you follow the logic, let’s say ActualText is “Dante” and Tracking is 4.0. We clear out the TextDisplay StackPanel, so it’s empty. We then create a TextBlock with only the letter “D”, and give it a 4 pixel padding (to the right). We then add it to the TextDisplay, and continue on with the next letter. We move on to the “a”, add the TextBlock, and so on.

I realize that this could be optimized to only add additional TextBlocks as needed, and changing the text on the characters instead of destroying and recreating them, but I wanted to start simple. When the handler is called, the “e” argument contains both the OldValue and the NewValue, so writing an optimizer wouldn’t be impossible.

So, if I wanted to, I could just tell the Tracking property to call the same method as ActualText. But, I decided that I wanted to clean it up just a bit.

private static void TrackingValueChanged(DependencyObject caller, DependencyPropertyChangedEventArgs e)

{

      StackPanel textDisplay = ((KerningTextBlock)caller).TextDisplay;

      foreach (UIElement thisCharacter in textDisplay.Children)

      {

            ((TextBlock)thisCharacter).Padding = new Thickness(0, 0, ((KerningTextBlock)caller).Tracking, 0);

      }

}

In this case, we’re just iterating through all of the children and resetting the padding. Much less destructive then going through and destroying all the children and rebuilding them every time.

The cool part about all of this is that you can set properties like the Foreground or FontFamily on the UserControl, and they end up getting inherited. So, once you’ve put all this in, rebuild the project in Blend, and instantiate one of our controls in Blend.

Once you’ve got it in Blend, go down to the Misc category, and you’ll see that both Tracking and ActualText show up as properties. You can set them there and see the effects immediately.  Plus, like I said, go ahead and change the Foreground, Font Family, Size, etc… and they’ll update immediately.

I don’t know how to make Blend think that the control is a Text control, so F2 isn’t going to work like a normal TextBlock, but the concept is there.

Now, the part that I’m trying to figure out, is a good way to do the Kerning. Tracking is easy since it’s a uniform spacing between all the characters, but to be able to adjust the positions of individual pairs of characters would be cool. It would be even cooler to automatically detect it, and since you technically can get the geometry of text, it SHOULD be calculatable, but making that performant may be tricky.

Well, hope ya’ll enjoy J.

The current theme is something like "Fire", which I chose because of my love for the elements. You can figure it out... a thought of 'hot software' and the like. But, I'm not saying that Blend isn't 'hot' any more... just that I need to figure out a new 'feel' for my blog.

So, if it seems to change a couple times in the near future, it's just me getting a feel for new looks and such. I will continue to post new thoughts and ideas as I go along. Now that the big thing I was working on (which, naturally, I can't say anything about yet), I should have some more time to play and find new things out. I've been experimenting with font embedding and custom characters, and that should be a pretty cool post coming soon!

For starters, we need to add a couple private variables to our Window... so I added these three lines:

private Point initialDragPoint = new Point(0, 0);

private Point currentDragPoint = new Point(0, 0);

private bool dragging = false;

My naming may not be the best, but what I'm setting up here is to keep track of where I clicked the mouse on my object, and for any mouse event, where I am now. I'm also setting up a boolean flag, just to make the code a bit cleaner.

Now, I've already opened Blend, and created a Rectangle. Also, since I don't really want/need all of the layout power of the Grid, I've changed the layout type of my root element to a Canvas. You COULD do this whole thing with RenderTransforms, but in this case, I think that's just more hassle then it's worth.

We need to hook up three events... MouseDown, MouseMove and MouseUp. We'll start with MouseDown...

private void StartMove(object sender, System.Windows.Input.MouseButtonEventArgs e)

{

      if (!this.dragging)

      {

            this.initialDragPoint = e.GetPosition(this);

            this.dragging = true;

      }

}

Ok, this method won't do a whole heck of a lot, but what it does is remember the point where the mouse came down, then swap the flag to remember that we're now moving. You'll want to hook this event up to the "MouseDown" event on your shape(s) that you want to allow the user to move.

Next, we'll do MouseUp (which is when the user releases the mouse button).

private void EndMove(object sender, System.Windows.Input.MouseEventArgs e)

{

      if (this.dragging)

      {

            this.dragging = false;

      }

}

Again, another simple one... all we do is tell our system that we're done dragging when the user lets go of the mouse button. Finally, the workhorse... MouseMove.

private void Moving(object sender, System.Windows.Input.MouseEventArgs e)

{

      if (this.dragging)

      {

            this.currentDragPoint = e.GetPosition(this);

            Vector dragVector = this.currentDragPoint - this.initialDragPoint;

            FrameworkElement actor = sender as FrameworkElement;

            double curLeft = (double)actor.GetValue(Canvas.LeftProperty);

            double curTop = (double)actor.GetValue(Canvas.TopProperty);

            curLeft += dragVector.X;

            curTop += dragVector.Y;

            actor.SetValue(Canvas.LeftProperty, curLeft);

            actor.SetValue(Canvas.TopProperty, curTop);

            this.initialDragPoint = this.currentDragPoint;

      }

}

Let's look at it piece by piece.

First, obviously, we only want to do something if we're currently dragging. So, we gate the whole method to only act if this.dragging is true.

Next, we figure out where the mouse currently is. e.GetPosition(this) does that for me. For the record, the 'this' as an argument just says that I want the point relative to the window. Since I used (this) in MouseDown as well, both of my points will be in the same scale.

To see how this works, let's say that when we did the MouseDown, we were 100 pixels down and 100 pixels to the right of the top left of our window. Then, when we got the MouseUp, we were 120 pixels down and 120 pixels to the right. So, this.initialDragPoint would be (100,100). The e.GetPosition(this) sets the currentDragPoint to (120,120).

The next step is to calculate our dragging Vector. We want our rectangle to move down and to the right, so the calculation is easy... Now, I could have used a Point just as easily, but I tend to think of this as an actual movement vector, so I used the Vector class instead. dragVector gets set to (120-100, 120-100) or (20,20), which is the movement we want on our rectangle.

Next, I need to get the actor (or the shape that my user is moving), and I need it as a FrameworkElement. By casting it to a Framework element, this same code would work for anything... a Grid with a bunch of elements in it... a single rectangle... pretty much anything.

Then, I just use GetValue to get the current Left and Top (see why I wanted to use a Canvas), adjust them by the dragVector, and then set those values.

Finally, the last thing I need to do, is set THIS point as my new base point, so that the new drag is relative to here. Imagine if I hadn't reset it, and then moved the mouse 20 more pixels to the right. The initial point would be 100,100, but the new dragPoint would be (140,120), so my rectangle, which I already moved 20x20 pixels, would be moved another 40x20 pixels. That's no good. So, updating that base value is important.

Granted, there are still some quirks here... for instance, you could start the drag with the left mouse button, then press the right mouse button while dragging... then releasing EITHER button would drop it. I'm sure there are plenty of refinements... but the point is that this should give everyone a good starting point.

I'm really excited for this, although it's going to be busy for a little while. We need to do dry runs and such. The tentative title is "Unlocking the Creative Genome", but that title may change.

I don't know how many folks who read my blog will be at MIX, but if you are, please stop by and introduce yourself. I'm also going to be in the Expression Blend sandbox, helping folks out with labs and such. I'll send more information as I get it.

If you're not familiar with the MIX, check out https://www.visitmix.com.

CORRECTION: Due to technical issues, my trip to the MIX has been cancelled. My apologies to anyone who was planning on coming to see me there. :(

Run the application on Vista, and click your minimize button. You'll notice that the window just vanishes! It doesn't get the nice minimize behavior like you'd expect (You know, the animation. Minimize any other app, and you'll see what I mean).

One of my teammates, Brian, was trying to get this to work, and he did some research. Apparently, if you set this.WindowStyle to WindowStyle.SingleBorderWindow, it will minimize correctly. He was pretty excited about this, and brought it to me. I'm not completely sure why it works, because when you restore the window, it's still the "none" WindowStyle, but it does work.

Problem is, if you run the minimize behavior a second time, it fails with an InvalidOperationException, and your app comes crashing down.

We tried resetting the WindowStyle back to None after Minimizing it, but that caused a different InvalidOp.

So, we played with it a bit, and it seems (oddly enough) that if you set the property ONCE after the window has been created, that you get the minimizing behavior. You just can't set it twice.

So, try this method:

private void MinimizeIt(object sender, RoutedEventArgs e)

{

      if (this.WindowStyle != WindowStyle.SingleBorderWindow)

      {

            this.WindowStyle = WindowStyle.SingleBorderWindow;

      }

      this.WindowState = WindowState.Minimized;

}

And from our experimentation, this would consistently cause the window to minimize in the "Vista" way, didn't cause a crash, and oddly enough, didn't change the appearance at all. Oddly enough, for grins, I tried putting that line in the Window1.Loaded event handler (Well, without the If statement), and it gives me the InvalidOperation exception.

Well, this is actually pretty easy. There is a property on the Window named ResizeMode, and if you set it to "CanResizeWithGrip", then a ResizeGrip control is placed on your window automatically, and if you run the app, it will, correctly, resize your window.

But, the default grip is six small squares arranged in a SE-pointing triangle. And, if you look in Blend, that control isn't actually in the XAML, so there's no way to modify it. You can't even make it transparent to put a customized control 'under' it. And it's magical, in that it you can't possibly get another control on top of it, even with Bring To Front... So, how do you customize the look and feel of that control?

You'll find that you can create a new ResizeGrip control, and place it in the bottom right, but you will find that it will be rendered under this mystical ResizeGrip, so no customization there either...

Under the covers, here's the problem. That ResizeGrip is not 'technically' part of the Window. Just as WPF is about to instantiate the window, it sees that the ResizeMode is set to CanResizeWithGrip, and it creates that grip for you in the SE corner. It simply instantiates the control, sets the properties to show up in the bottom left, and that's it. Unfortunately, this means that you can't modify any of the properties on it, since it's actually created when the Window is Instantiated.

I suppose, if you wanted to, you could, in code, track down that control by looking at the children of the Window, although I'm not even sure it *IS* technically even there.

You could also create your own custom control (probably inherited from Thumb), and implement all your own MouseDown/Up/Move code to do your resizing for you. 

Thankfully, here's a better solution. Drop a ResizeGrip somewhere on your document, and edit a copy of the template. But, when the dialog comes up to let you know that you're creating a new Template, click the "Apply To All" radio button, instead of supplying a name. By specifying Apply To All, you're telling WPF that any new controls of this type, unless they specify a new template, should use the template that you're creating at this moment. Go ahead and trick out the ResizeGrip however you want in the Template, then delete the ResizeGrip that you created at the beginning of this process.

Now, you've got a new default ResizeGrip template, so now when WPF instantiates that ResizeGrip, it gets your new default template, and gets the look and feel you want.

The obvious question, now, is that once you've done this, what if you want different ResizeGrips for different areas of your window? I.e. maybe my dialogs that show names have a resize grip with a yellow smiley face, but my dialogs for error messages show a little horned devil.

Two points here... First, when you define your new default template, you can specify the scope. So, if you scope your new template to the Application, then ALL your ResizeGrips will look identical. However, if you scope it to individual windows, those windows can have different templates.

Second, there's nothing stopping you from creating a template whose appearance is a transparent block. Then, you can simply put whatever you want your grip to look like at the bottom right, and the real resize grip will be rendered on top, but since it's transparent, you won't see it... you'll just get the functionality. Of course, if you're going to try this route, make sure your little smiley faces or whatever are laid out in such a way that they'll stay at the bottom right :).

Enjoy!

PS: If folks don't know how to set up moving/close/minimize behavior on transparent windows, give me a shout, and I'll put something here for those scenarios.