OK, this title is not meant to be taken too literally. But the fact remains that the Blend IDE does have some useful ways to perform Venn-like operations on graphically rendered data.

First question: Why would you care?  Well, as it turns out, many custom UserControls begin life as simple vector-graphics which are rendered with the Shape tools (pen, pencil, line, etc) and tweaked using the Properties window.

As you are building such a rendering, the IDE will capture pen and pencil strokes using a <Path> element, and members of System.Windows.Shapes for rectangles, circles and lines.  For example, assume the following collection of objects on a WPF main window:

If you were to examine the XAML, you would find something such as the following:

Now, using Blend, you can select multiple shape objects (via  Shift + Click) and then activate the context menu on your selection.  Here you will find a Combine menu tem, which exposes a series of Venn-like operations:

For example, if you were to pick the Unite option for each selected shape, your resulting image would appear as so:

And the previous three elements have been combined into a single <Path> object:

Blend is plump-full of useful shortcuts like these, and I'll post other tidbits over time.

Happy Blending.

About 1 year ago, Intertech began offering "blended classes".  This training mode allows us to hold a class which is attended by folks in our physical classroom (in lovely Eagan, MN) as well as people from around the US.  Those who are attending remotely typically use a land-line phone system (or in some cases, VOIP) to hear the lecture, and webex to view the slides, demos and quizzes.

At first, I was fearful that this mix of student types could hurt both groups of people. My first fear was that the remote attendees could become isolated. However, since Intertech has training rooms equipped with SmartBoards (you know, the cool white boards you can control with your hand, write on with "virtual pens" and so on), the remote folks have much more engaging eye candy- far more than a bunch of random PowerPoint slides. The use of the SmartBoard seems to keep the remote folks more connected than I realized. The local folks also seem to have a fair share of "oohs" and "aahs".

I was also fearful that local and remote students might have problems hearing each other.  Thankfully, our training rooms are equipped with built in speakers / mics, so again, things are fairly smooth.

To be honest, teaching a blended class feels little different than teaching a class where all students are local to the classroom.  These days, I tend to feel like something is "missing" if we don't have at least 1 remote student.  The mixing of student types tends to make everyone a bit more interactive, which is fantastic.

Not everything is flawless however. We have had a few times where we lost connections to remote students due to oddball issues in the area.  Once, some city workers basically took down our internet connectivity more much of a work day.  Obviously this was no good for anyone.  Beyond such issues, the core infrastructure (webex, mics, land-lines, etc) has been quite solid.

So, as an FYI, if you are interested in a standard Intertech class, but don't live in state, do be aware that any of our classes can be attended remotely. This can be very beneficial to the attendees.  Not only do they reduce some travel and hotel expenses, but they can be "close to home base" to respond to any fires at work which pop up.

And, I suppose you *could* attend class in your PJs if you really want to (don't worry, we don't bother with any web cams).

The Blend IDE can be a strange and mysterious place for many developers. As you most likely already know, Blend, in general, is a tool to generate XAML for WPF and Silverlight applications, using a fancy graphical environment.

Similar to Visual Studio, Blend maintains a pallet of controls which can be placed on the visual designer surface, after which point they can be configured using the Properties window.

Naturally, as you are creating a UI, you may need to relocate or reposition items on the designer, and this simple task smacks you right into the odd distinction of a "Selection" and "Direct Select". If you examine the Blend Tools pallet, you will see two selection icons to represent each possibility:

Now, assume you have placed a Button control and a rendered geometry (via the Pencil tool) onto the designer.

If you wish to simple select an item for the purpose of resizing, moving or rotation, you will want to use the Select option (press the V key as a keyboard shortcut).  Once you have done so, you will be able to tweak the selected item as you see fit:

This being said, what is a "Direct Selection" used for (press the A key as a keyboard shortcut).  Well, the answer is "it depends".  If you perform a direct select on a rendered vector graphic, it will allow you to redefine the path itself using a set of pull points:

If you perform a direct select on a ContentControl derived item (such as a Button) it provides a way to drill into the internal content of the control. This can be helpful if you have (for example) a Button which set the Content property to a layout manager (a Canvas perhaps) which contains some number of sub items. In this case, a direct select will allow you to edit the internal aspects of the Button, rather than its general dimensions and placement.

Enjoy!

As odd as it may seem to those new to WPF and Silverlight development, ?brushes? are a key aspect of these programming APIs. These seemingly uneventful objects serve as building blocks for interactive geometries, custom styles, custom control templates, resource items and whatnot.

If you require a simple solid colored brush (say, a ?red? brush to fill in the background of a widget), your job could not be any easier. Simply assign a string value to a brush-compatible property:

<Ellipse x:Name="myCircle" Fill="LightGreen"
         Stroke="DarkGreen"
         StrokeThickness="4"
         Height="50" Width="50"/>

Here, the Stroke and Fill properties have been assigned to string values that map to a built in set of known colors. Behind the scenes, these string objects are transformed into a corresponding SolidColorBrush object using a built-in type converter.

Now, if you require a more exotic brush (such as a LinearGradientBrush or RadialGradientBrush), typing in the required markup is much more taxing. Consider the following update to our Ellipse object, now making use of a RadialGradientBrush object, containing a set of gradient stops.

<Ellipse x:Name="myCircle"
 Stroke="DarkGreen"
 StrokeThickness="4"
 Height="50" Width="50">
    <Ellipse.Fill>
        <RadialGradientBrush GradientOrigin="0.65,0.61">
            <GradientStop Color="#FF83D688" Offset="0"/>
            <GradientStop Color="#FF74D47B" Offset="1"/>
            <GradientStop Color="#FF14721A" Offset="0.491"/>
        </RadialGradientBrush>
    </Ellipse.Fill>
</Ellipse>

As you might imagine, it would be a massive pain in the neck to type in GradientStop object data manually using Visual Studio (even with this relatively simple RadialGradientBrush):

Thankfully, Expression Blend has a wonderful brush editing experience. Using the Properties window, you are able to easily add, remove and configure GradientStop objects using a dedicated editor. Assume you have added an Ellipse object to the Blend designer surface. Once you have selected this item, you will find the following editor.

Notice the location of the mouse cursor in the previous screen shot. This row of buttons allows you to select which brush category you are interested in working with (no brush, solid colored brush, gradient brush, etc). Beyond the ?no brush? option, the remaining options allow you to use the color editor (located below the ?brush selection row? area) to select ARGB values.

When you select the ?Gradient brush? option, the brush editor changes just a tad. Most specifically, you have a new area below the color editor, which allows you to add, remove and configure GradientStop objects.

By default, you will be given two ?thumbs? that represent your first two gradient stop settings, which are set to the colors black and white. Below this editor, you will find a few small buttons on the lower left which allow you to toggle between radial or linear gradient brushes:

When you click on either of the gradient stop thumbs, you can change the underlying color (and the generated HEX value in the related markup). Likewise, if you slide these thumbs on the gradient editor, you are able to control the Offset property of the current GradientStop.

If you wish to add additional gradient stops, simply click within a blank area on the gradient stop strip. Removing a gradient stop you no longer require is a bit unintuitive (if you ask me?); you cannot ?right click? on a thumb to activate a ?delete? menu option. Rather, you simply drag a given thumb off the gradient strip editor. Once you have done so, it will vanish from view (and markup).

Once you have defined your gradient stops, you may then wish to change GradientOrigin property of the RadialGradientStop (or LinearGradientStop) object, which controls when the color blending will begin rendering. To do so, you will move off the brush editor itself, back to the designer surface. Ensuring the item using your brush is selected (the Ellipse in this example), press the G key (not Ctrl+G mind you, just G). This will add a gradient origin editor to the surface, which can be moved around to control the starting point:

Last but not least, Blend makes it very easy to store that ?perfect? brush as an application object resource. You?ll notice on the Brush editor of the Properties window, a button which reads ?+ Brush?. Once you click on this option, you are able to specify a new named resource, and the location you wish to store it (application level, resource file, etc).

That wraps up this (long overdue) blog entry. Hope you have gained a bit of insight regarding very useful (and often mysterious) Blend IDE.

Hey all. A while back, I gave a public talk at the Microsoft offices here in Minneapolis on Expression Blend. It was a talk that illustrated a number of features that developers would need to know to get up to speed on the tool.

Given the shorter work week (happy Fourth of July!) I don't think I'll be able to get the first "real" blog post on Blend posted this week. So, please enjoy the following tutorial on some Blend basics.

You can view it online here.

I'll follow up with more Blend coverage next week.

Enjoy!

When WPF first appeared on the programming landscape, (and once SL moved to version 2.0 and became something we could be proud of), it was clear that typing gobs of XML was in our future. 

Now, if you are anything like me, you may have thought that you could muddle through and simply leverage Visual Studio has you XAML editor of choice.  While you COULD do so, you would soon get massive hand cramps, as earlier versions of VS had very limited support for XAML editing, beyond simple code completion. 

Now that Visual Studio 2010 is here, many folks assume that this version of the IDE has ALL the features you could possibly need, it is simply not the case. VS2010 does have a number of improvements to be sure.  You can now extract resources, define complex brushes, establish (some) data bindings and so on, all from the comfort of your Properties window.  Furthermore, the WPF and SL designers have true drag-and-drop control placement.

But...

If you want to define animations, 3D graphics or generate UserControls on the fly, Visual Studio is not enough. And that is where Expression Blend comes in.

When Blend was first released, it was marketed as a tool for graphical artists. Now, I am not so sure. It seems that the line between programmer and graphical artist is blurring. While nobody should expect a programmer to generate top-notch graphics (anymore than a graphical artist should not be expected to generate C# code), it is clear that the modern day WPF/SL programmer *should* know the basics of the Blend IDE.

As suggested, Blend is a very elaborate XAML editor. Unlike VS 2010, Blend *does* allow you to work with complex animations, extraction of UserControls from graphical data, edit default styles, define visual states for custom controls, generate 3D effects, apply animation easings and dozens of other feature that VS 2010 simply does not support. 

So. the short answer is, unless you *really* like typing XML, you will need to flip between VS 2010 and Blend when you are building a WPF / SL program.  

Given this, the next several blog posts will address the key features of Blend from a programmer's point of view.  If you don't have your own personal copy of Blend, be sure to download an evaluation copy here.

My next blog post will start at the very beginning of working with Blend.  Look for it in a few days!

My coworker at Intertech (Jim White) wrote an interesting blog post which addressed the "10 topics advanced Java programmers need to know" (he's a Java-guy, but don't hold that against him ;-). I liked his article, so I thought I'd offer up a .NET version of the same post.  Here it goes, and thanks Jim for the idea!  By the way, these are *not* any any specific order...

10) LINQ

At first, LINQ was seen by many to be a interesting shortcut for grabbing data from a container.  Nowadays however, LINQ is everywhere.  LINQ to XML, LINQ to EF, PLINQ and LINQ to Objects are common place.  If you want to show your team mates you are up to speed on core .NET technologies, understanding LINQ should be on the top of your list of ToDos.

9) WPF (and therefore Silverlight)

Regardless if you are a "Web Person" or a "Desktop Person", Microsoft's current GUI APIs are quickly replacing older frameworks, especially Windows Forms.  Both WPF and Silverlight use the same core body of tech, so when you understand 1, the other is close behind.

8) The Blend IDE

I was a man who was fearful of Blend early on.  In fact, I wore my fingers to the bone typing in XAML by hand.  Trust me, if I can get over the Blend fear-zone, any one can.  If you are doing WPF or Silverlight, usnig Blend makes your work much easier, especially when working with templates, animations or graphics.

7) TPL

The Task Parallel Library is a new .NET 4.0 threading / multicore API.  Using TPL (and PLINQ) you can very easily add multithreaded functionality to your applications, using a framework which hides a good number of the low level details. Thanks thread pool!

6) Lambdas

The C# => operator, or the VB Sub/Function statements, can seem to be quite terse at first glance. However, lambdas are a great shortcut for working with delegates.  If you are serious about learning LINQ and the TPL, you *need* to be confortable with lambdas.

5) WF 4.0

OK, I know.  WF 3.0-3.5 had some warts.  But honest, WF 4.0 is a massive step in the right direction.  A whole new assembly stack, new designers, new engine and new activities make the process of modeling business processes clean and simple.  And, WF 4.0 is based on XAML!

4) Knowing if you REALLY need That Pattern

Design patterns *can* help you write easy to maintain code....or they can add layers of unnecessary complexity.  We programmers love the latest and greatest to be sure, but I have seen too many people cram patterns into projects that just don't need them.  Case in point?  ASP.NET MVC.  Yes, it is great for testing web sites, but there are ways to do so without MVC.  Don't use a pattern because it is the latest buzz word.  Use it because it will make your life better.

3) ADO.NET EF

The Entity Framework is a slick object model over relational database logic, which favor LINQ queries over T-SQL queries. While the connected and disconnected layers are certainly still part of the picture, the EF model can really simplify common database activities....and the VS 2010 designers are very solid.

2) Use of Dynamic Data

The DLR allows you to opt-into scripting like functionality, within a statically typed language. If you are doing any sort of COM interop, dynamic assembly generation or reflection tasks, dynamic data can reduce the amount of code you will need to write by a *great* deal.  Just watch your typing...

1) The .NET Type System

In a rush to get software out the door ASAP, many programmers "skip" over the foundational nuts and bolts, and google for the next "how do I make my grid look like this" sort of answer.  Google is great, but you really owe it to yourself to be solid on the ins and outs of classes, interfaces, structures, enums and delegates. These are the bread and butter aspects of every possible .NET application and API.

So, thanks again Jim for the idea. Hope to see some of you in class where we can learn about these (and many other) .NET topics

When you are building an application using VB, you will most certainly need to hook into various event sources.  While events are very common when you are constructing a GUI application (WPF, ASP.NET, Windows Forms), they are also very important for non-UI tasks such as working with threads, callbacks from database operations, and other tasks.

As it turns out, VB has a few "oddities" regarding how to hook into a given event, so I wanted to do a quick blog post which will hopefully clarify our choices.

First of all, when you are declaring a field of a Class, Structure or Module, you have the option of making use of the WithEvents keyword.  When you do so, you are able to selectively hook into events of interest using the Handles clause on a given class method. One part of this puzzle which is hidden from view is the fact that each and every .NET event is defined in termes of a related delegate.  As you may know, the .NET delegate type allows us to capture, in a strongly typed manner, the address of another method. Given this point, the method that uses the Handles clause must match the underlying delegate definition, or you will receive compile time errors!

Here is a simple example of capturing the Click event of the Windows Forms Button class.  Take note that the method receiving the event notification takes an Object as the first parameter, and a EventArgs as the second, given that the Click event has been defined in terms of a system delegate named System.EventHandler.

 Class MainWindow
  Inherits Form

  ' Inform the Button we are interested in listening to
  ' events.
  Private WithEvents btnClickMe As Button

  Public Sub New()
    btnClickMe = New Button With {.Height = 100,
      .Width = 100, .Text = "OK!"}
    Me.Controls.Add(btnClickMe)
  End Sub

  Private Sub btnClickMe_Click(ByVal sender As Object,
    ByVal e As System.EventArgs) Handles btnClickMe.Click
    MessageBox.Show("Clicked!")
  End Sub
End Class

Now, one gotchya is that the WithEvents keyword can only be used for fields (local variables need not apply). When you wish to handle an event for a local variable, you are required to use the AddHandler statement.  Here, you will specify the event name and method to call (via the AddressOf operator).  However, in this case the Handles clause is not used.  Here is a re-working of the previous class which illustrates these points: 

Class MainWindow

Of course, with the release of .NET 4.0, VB has full support for lambda expressions.  This is yet another way to hook into event sources, which was covered in a previous blog post.

Quick blog post this week to let people know that the 5th Edition of my C# book is in the stores!

C# 2010 and the .NET 4.0 Platform tops in at more than 1700 pages (eek!).

But there are a number of new topics, extended topics, additional examples and other goodies. Here is a hit list of the big topics:

• Coverage of the C# dynamic keyword and DLR
• Coverage of the ADO.NET Entity Framework / LINQ to Entities
• Coverage of C# 2010's improved COM interop
• Coverage of the TPL and PLINQ
• Deeply expanded coverage of WPF
• Deep coverage of Expression Blend
• Coverage of WF 4.0 (which is totally different from the previous WF API)
• The new WCF 4.0 bits.
• etc, etc, etc.

As before, Apress is offering deals for a digital copy of the book if you buy the printed copy.  Check out the following link for more details.

Be back next week with some new tech-posts.  Thinking of starting a long blog tutorial about Expression Blend......hummmm.....

Happy coding,

Andrew

The C# 2010 dynamic keyword can be used for a variety of reasons, some of which are a tad esoteric.  However, there is a very practical use of this new language feature, specifically the (radical) simplification of COM interop programming. By default, when you import a COM library into a VS 2010 project (configured to target .NET 4.0), every COM VARIANT is automatically mapped to a dynamic data type.

This behavior greatly decreases the need to cast data types and drill into low level interop primitives (such as the underlying get_ / set_ methods).

Furthermore, thanks to C# 2010 optional arguments, you no longer need to author reams of Type.Missing tokens when specifying missing values.

To showcase the distinction, assume you wish to map some data in a List to Microsoft Excel.  Before .NET 4.0, you might author code such as the following:

Notice in particular the grimy casting operations (Excel.Range, and so forth). 

Now, here is the same code once again, using the new features of C# 2010:

Nice, eh? I'm sure you'd agree that simplification is always a good thing...