MHender Rambles On

I'm Hanging Up My Crossbow

mhender — Wed, 10 May 2006 00:43:00 GMT

My Dear Loyal Readers,

That's right, I'm moving on to other projects here at Microsoft. The Crossbow runtime is pretty well locked and loaded and on a glide path for release with WPF so I am shoving off for other shores. Not to worry, Crossbow is in good hands and like I said it's pretty much in the can at this point.

I have enjoyed stuffing my bits into your RSS readers and appreciated all the great comments and lively discussions.

Good luck and I'll most likely be blogging about some other topic soon...

Crossbow Web Cast

mhender — Wed, 05 Apr 2006 23:28:00 GMT

I did a web cast, well really I guess it was a Live Meeting, today on Crossbow. I received numerous requests to post my demos and my slide deck. I'll do ya one better, I'll even post the recording of the event so you can watch it again and again. Heck, ice down some brewskis and invite the whole freakin' neighborhood and make it a party...yeah a CROSSBOW party...that's the ticket! Maybe...maybe...I could even get one of the networks to run it in prime time...maybe I could get my own CROSSBOW CHANNEL..huh, huh...yeah...that would be cool...huh, huh...MAYBE I COULD LAUNCH MY OWN SATELLITES THAT BROADCAST ALL CROSSBOW ALL THE TIME!

...(Note to self: don't forget to take your medication on time)

Okay, I'm better now...enjoy and bring me some T.P.!

Presentation Slide Deck
RecipeBrowser Demo
DatabindingDemo
Recording of the Presentation

P.S., you will need the Feb CTP of WPF and Crossbow to run the demos.

Have You Checked the Children?

mhender — Tue, 04 Apr 2006 21:10:00 GMT

He says in his best maniacal voice...

I assume you know that the fairly recent movie "When a Stranger Calls" is a re-make of the 1979 original which starred Carol Kane as the babysitter. You may remember Carol Kane as Simka, Latka Gravas' (Andy Kaufman) wife in the TV show Taxi. Andy's dead now you know...sad really...he kind of went off the deep end when he started wrestling women...

Blog reader: What the hell are you talking about?

Sorry, my mind wanders like that from time to time. Don't know if it's because I'm a product of the 60's or if I'm just getting old or that I'm just plain out of my FREAKIN' gourd!

Okay, I'm better now. So anyway, I wanted to give you a heads up that there is a breaking change coming in the Crossbow API for Beta2. There used to be a Children property on WindowsFormsHost control. You would use the property to add your subsequent Windows Forms control to the host via the Children.Add() method. We'll it ain't there anymore. We replaced it with a Child property. This was done because we felt it was kinda stupid to have a collection property that limited you to one item. (You may remember that even though we implemented this property as a collection, we enforced a limitation of a single item in the collection). So now there's just the single Child property and you simply assign some Windows Forms control to it.

   WindowsFormsHost host = new WindowsFormsHost();
   System.Windows.Forms.Button wfButton = new System.Windows.Forms.Button();
   wfButton.Text = "WFButton";
   host.Child = wfButton;

Likewise on the ElementHost control, we used to have the Controls collection property where you added your single top-level element. Now we have replaced that with a Child property as well. Once again, we just wanted to remove the collection and replace it with a singleton and maintained consistency with the naming.

   ElementHost host = new ElementHost();
   System.Windows.Controls.Button wpfButton = new System.Windows.Controls.Button();
   wpfButton.Content = "WPFButton";
   host.Child = wpfButton;

Note that this change goes into effect in the Beta2 drop of Crossbow.

<ManiacalVoice>
So next time when the compiler calls and tells you something's wrong...remember to check the children...
</ManiacalVoice>

Localizing a Hybrid Application

mhender — Thu, 30 Mar 2006 19:00:00 GMT

I'm blogging to:

KEXP

Live Stream

Have you ever done one of those things where you search all over the house looking for your glasses and after hours of searching you walk past a mirror and see that they are sitting on your head! Makes you feel kinda stupid doesn't it? Well, that's how I felt when I finally figured out how to localize a hybrid application yesterday. I'd been struggling with this for some time and just couldn't get it to work and then finally it dawned on me which led me to utter the ultra-famous Homer Simpson phrase...D'oh!

Here's the situation...You are building a Windows Forms application that you want to contain some WPF content as well. Now you also want to localize this application so that it can be used in multiple locales. Normally, you would want to create a main assembly for your default language and satellite assemblies for the localized content.

So you set off on the journey, a regular Bilbo Baggins leaving theShire behind as you head toward your destiny.

To frame this discussion, we will develop a useless little application purely for illustrative purposes. Lets create a Windows Forms app called SimpleLocTest that contains a single form. On that form, let's put a label and set its text to some English text...we'll use "English".

Next we'll use the Windows Forms designer to localize our form. Of course there are other ways to localize the form, but this way is easy. To do this, set the Localizable property of the form to TRUE and change the Language property of the form to say Spanish (Spain). Now change the text of the label to contain some Spanish text, yep we're going to use "Spanish". Yeah, I'm clever like that.

Okay, that takes care of localizing the Windows Forms stuff, now let's work on the WPF stuff. First we need to add an ElementHost control to our form to host the content. Next we will add a WPF UserControl item to our project. Do this by adding a New Item to your project and choosing WinFx UserControl from the dialog. This will create a UserControl1.xaml and a UserControl1.xaml.cs file in your project.

Next let's modify the xaml of our UserControl to simply add a WPF Button to it.

Build and run the application and you should see all Englsh text.

Okay, now we want to set ourselves up for the case where we are running on a Spanish localized version of the OS. We'll simulate this by changing the UICulture of our application's thread so that it thinks we are running on a Spanish OS. To do this, add the following line of code to the form's constructor BEFORE the call to InitializeComponent():

System.Threading.Thread.CurrentThread.CurrentUICulture = new System.Globalization.CultureInfo("es-ES");

Next we need to go through the localization procedure for the WPF content. To do this, we will follow the steps oulined in the WinFx SDK documentation for Localizing an Application under the WPF node in the docs.

The first step is to add

<UICulture>en-US</UICulture>

to our .csproj file. Wanna know a cool and easy way to hand modify your .csproj file while it is loaded in the Visual Studio IDE? Just right-click on the project name in the Solution Explorer and choose Unload Project from the context menu. Then right-click again on the project name and choose Edit SimpleLocTest.csproj from the context menu. Now you can use the XML editor to work on the project file while still in the IDE.

So we'll add this UICulture tag to to the top ProperyGroup which will mean it is for the debug configuration since we'll stay in the debug mode all the way through. Of course you can add it to any of the configurations.

<PropertyGroup>
   <Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
   <Platform Condition=" '$(Platform)' == '' ">AnyCPU</Platform>
   <ProductVersion>8.0.50727</ProductVersion>
   <SchemaVersion>2.0</SchemaVersion>
   <ProjectGuid>{828F16E3-20A4-4EC4-A8F4-CD95B8ED44C9}</ProjectGuid>
   <OutputType>WinExe</OutputType>
   <AppDesignerFolder>Properties</AppDesignerFolder>
   <RootNamespace>SimpleLocTest</RootNamespace>
   <AssemblyName>SimpleLocTest</AssemblyName>
   <UICulture>en-US</UICulture>
</PropertyGroup>

Adding this tag will tell WPF that we want to generate satellite assemblies. Now save the file and then right-click again on the project name and choose Reload Project from the context menu.

Next we need to a Uids to our XAML file. This makes it easy to identify each element and makes it easy for them to be localized. To do this, you simple use MSBuild to build the application using the following syntax:

msbuild /t:updateuid SimpleLocTest.csproj

After running this command, your XAML file will now contain Uids.

Okay, rebuild the application.

Time to do battle with an Orc or two. Now we need to user the LocBaml tool to extract the resources that we can localize. Go to the obj\debug directory of our project. Run the following:

LocBaml /parse SimpleLocTest.g.en-US.resources /out:foo.csv

This will read in the resources that were generated as a result of adding the UICulture tag to our project file. Note that these are the English resources. This command will create a .CSV file that will allow you to use an editor like Excel or Notepad to edit the strings to change them to your localized language.

Edit foo.csv. You will find the string "Hello". Change this to "Hola" and save the file back out over itself. Next you need to merge the Spanish resources back into the English resources by running LocBaml again:

LocBaml /generate /trans:foo.csv SimpleLocTest.g.en-US.resources /out:c:\ /cul:es-ES

This will generate a file called SimpleLocTest.g.es-ES.resources in the location c:\. You can specify a different output directory, but I'm lazy at typing long paths so I just put it at the root. Now I need to copy that file from c:\ to where the rest of my resources live just for convenience sake. So copy c:\SimpleLocTest.g.es-ES.resources to our obj\debug directory.

Next we need to merge the Windows Forms Spanish resources with the WPF Spanish resources to create our Spanish satellite assembly. To do this, we use the linker (Al.exe):

Al.exe /out:SimpleLocTest.resources /culture:es-ES /embed:SimpleLocTest.Form1.es-ES.resources /embed:SimpleLocTest.g.es-ES.resources

This will generate a file called SimpleLocTest.resources.dll in the obj\debug directory. We need to copy this file to the bin\debug\es-ES\ directory writing over the file of the same name that is already there. Note that the file that is there is a satellite assembly that only contains Windows Forms Spanish resources that gets generate as part of the build process. We can get rid of that file because we need the merged satellite assembly file.

Now let's RUN the application, DONT REBUILD IT or you will write over the Spanish satellite assembly that we just worked so hard to build.

You should now see the Spanish text for both the Windows Forms label and the WPF button:

THE PRECIOUS! Okay, we made it unscathed! And as you can see we were able to create a single Spanish satellite assembly that contains both Windows Forms and WPF resources. Kinda like "...one satellite assembly to rule them all..."

We Don't Need No Stinking Mapping PI!

mhender — Tue, 28 Mar 2006 19:26:00 GMT

I'm blogging to:

The Yeah Yeah Yeahs

Show Your Bones

I just wanted to make sure eveyone was aware of this little fact. First of all, in more recent builds (at leas the Feb CTP and beyond) you no longer use Mapping PIs to reference external assemblies. Instead, you simply use the xmlns attribute by itself. So using "old school" syntax you would have something like:

<?Mapping XmlNamespace="wf" ClrNamespace=System.Windows.Forms" Assembly="System.Windows.Forms" ?>
<Window x:Class="MappingPIChange.Window1"
     xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presentation
     xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
     xmlns:wf="wf" >

Now you would loose the Mapping PI altogether and just use the xmlns attribute in the following manner:

Furthermore, you do not need to do this at all for the things in WindowsFormsIntegration such as WindowsFormsHost. These are now part of the standard schema and no longer need to be prefixed.

Dude, Where's My Control?

mhender — Mon, 27 Mar 2006 19:40:00 GMT

I'm blogging to:

Johnny Cash

The Legend of Johnny Cash

I have received numerous emails from people who are using the Feb CTP version of Crossbow and have run into the bug that we have in ElementHost where the hosted WPF content does not show up until you resize the Form that contains the ElementHost control.

While this may be a small enough issue, many people have requested a work-around for the problem. Well, you would think that all you have to do is force a repaint by calling Invalidate() or Refresh() on the Form, but alas this does not make the content appear. So how can we fix this?

Don't fret my little Crossbow consumers...Uncle Mike is here to hook you up. Here's what you need to do...At the end of your Form_Load() event handler, hook the Shown event and change the Form's size. So, something like:

private void Form1_Load(object sender, EventArgs e) {
     ElementHost host = new ElementHost();
     host.Dock = DockStyle.Fill;
     UserControl1 ctrl = new UserControl1();
     host.Controls.Add(ctrl);
     this.Controls.Add(host);

     // Here's the magic line of code
     Shown += delegate { Width++; };
}

This little hack will at least get you up and running so that you can see your hosted WPF content when the Form loads. Generally, this will suffice until you get the version of Crossbow that has this fixed.

Help me fix my CSS!

mhender — Wed, 22 Mar 2006 19:11:00 GMT

I'm blogging to:

Sirius Satellite Radio

Left of Center

Okay all you CSS studs and studettes out there...help me out. I'm having a CSS crisis! If you are a regular reader of my blog you notice that I try to give you some insight into my strange mind by telling you what music I am listening to while I blog. I created a schema for describing this information and then built some CSS that I thought would render it nicely over in the right hand margin of the page. It works fine when you go to one specific post, but if you go to the page where all the blog posts are listed one after the other, the CSS doesn't work correctly. So each post will have an entry for the music, but I only want it to show up for the top most post...you get what I'm saying? So here's an example of the schema:

<DIV id=NowPlaying>
<DIV id=Intro>I'm blogging to:</DIV>
<DIV id=Image><A title="Check out the Beatie Boys" href="http://www.beastieboys.com"><IMG src="http://images.amazon.com/images/P/B00021LRWM.01.THUMBZZZ.jpg"></A></DIV>
<DIV id=Artist>
<H5>The Beastie Boys</H5></DIV>
<DIV id=Album>
<H5>To The 5 Burroughs</H5></DIV></DIV>

Here's the CSS I'm using:

#NowPlaying {
        position: absolute;
height: 200px;
width: 170px;
background-color: #DDDDCC;
        right: 0px;
        top: 400px;
        border: 1px;
        border-color: #770000;
        border-style: solid;

}

#Intro, #Artist, #Album{
text-align: center;
color: #770000;
}

#Image{
margin-left: 50px;
}

How can I make just the top most "NowPlaying" div render and ignore any subsequent ones? What happens instead is the bottom-most entry gets displayed (the last one) instead of the top-most entry (the first one).

A Bitmap By Any Other Name...

mhender — Fri, 17 Mar 2006 21:10:00 GMT

I'm blogging to:

The Greencards

Weather and Water

As I typed the title to this post, I wondered just how many people over the years have butchered "Billy the Bard"'s line from Romeo & Juliet? I'm sure it's ridiculously high and here I go contributing to it. Sorry about that Bill, you can roll back over in your grave now...

In the spirit of interoperability, I thought it may be interesting to take a look at a scenario where you want to write a WPF application that uses resources that are entered and stored via the Resource Editor in Visual Studio.

Let's create a cheesy little application that shows off how to do this. First we need to create a WPF application using VS. Then we add some resources using the Resource Editor. To do that we just go over to our Solution Explorer in VS, expand the Properties node and double-click on 'Resources.resx'. This will launch the Resource Editor.

In the Resource Editor, let's add a string resource and an image resource. For the string, we will use some lyrics to one of my favorite Soul Coughing songs 'Screenwriters Blues'.

Since we are using these lyrics, let's use the image of the 'Ruby Vroom' CD that the song is on as our resource image.

Okay, now that we have our resources stored, let's work on the rest of the app. Let's go to our XAML and add a Button and a Label.

What we are going to do is use the string from our resources for the Label and use the image as the background of our button. Now using the string is perfectly straight forward since a string is a string. The bitmap however is a horse of a different color or it smells different or something. (Yeah, I know...I'm mixing my metaphors).

So let's go to the code behind to start doing our thing. We need to figure out where we are going to put our logic to set the label and the button. Usually you do this in some event handler in the code behind so we'll do that as well. However, what event should we choose?Most of the time you see examples using the Loaded event for the Window so that would be normal for us to use as well. BUT, I ain't gonna do that. Why? Well, it's because I want to be different and it's a good habit to get into. Let me explain this a bit. Many times in our code behind, we are doing things like adding controls to our visual tree in a WPF application. And if we use the Loaded event handler for doing this, we can sometimes get undesireable results. For example, if we are using a parent control such as a StackPanel and if we were to handle the Loaded event and put logic there to add controls, you would see that the Loaded event fires more than once due to the re-layout of the window after each control is added. This would result in having the controls added multiple times. If we instead use the SourceInitialized event, we don't have this problem because it is fired only once.

Okay, in our code behind let's handle the SourceInitialized event and put our code there. The first thing we want to do is get our resources.

// Get the resources
System.Drawing.Bitmap resourceBitmap = Properties.Resources.ruby;
String resourceString = Properties.Resources.String1;

Next let's do set our label's content to be the value in our string resource.

// Set the label's content to be our resource string
this.label1.Content = resourceString;

Now comes the part that's just a bit trickier...setting our button's background to our resource image. It's only tricky because the resource happens to be of type System.Drawing.Bitmap and we cannot set our button's background to a System.Drawing.Bitmap. To do this, we have to convert the bitmap to something that WPF understands. Luckly, there is a helper function that makes this a bit easier. The helper function is called 'CreateBitmapSourceFromHBitmap' which can be found in the System.Windows.Interop.Imaging namespace.

// Convert the System.Drawing.Bitmap to a WPF BitmapSource that we can use
IntPtr hBitmap = resourceBitmap.GetHbitmap();
System.Windows.Int32Rect rect = new Int32Rect(0, 0, resourceBitmap.Width, resourceBitmap.Height);

BitmapSource bmpSrc = System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap(hBitmap, IntPtr.Zero, rect, BitmapSizeOptions.FromEmptyOptions());

Let's take a quick look at the function signature for this function:

public static BitmapSource CreateBitmapSourceFromHBitmap (
	IntPtr bitmap,
	IntPtr palette,
	Int32Rect sourceRect,
	BitmapSizeOptions sizeOptions
)

The first parameter is a pointer to our original bitmap as an HBITMAP. In order to supply that we have to call the GetHBitmap() function on our System.Drawing.Bitmap object.

The next parameter is a pointer to the bitmap's palette. Now we have a Palette property on our original bitmap object, but we can't pass it to this function because the function wants the palette as an IntPtr. So to make this happen, you are going to have to write some magic code that will convert the color palette to an IntPtr. (Actually, I tried this and never quite got it right). But the good news is that since our bitmap does not have a specific palette, we can just pass in IntPtr.Zero (null).

Next is the source rectangle for our bitmap. Note that the function want this to be in the form of an Int32Rect and not a System.Drawing.Rectangle object.

I don't totally understand what the final parameter is all about, but I played around with different settings and managed to get this working so I didn't worry about it too much.

Okay, now that we have converted our bitmap to something that we can use, let's set the background of our button to the image and make sure the size of the button is the proper size.

// Set the background property of our button to the converted resource bitmap
this.button1.Background = new ImageBrush(bmpSrc);
this.button1.Height = resourceBitmap.Height;
this.button1.Width = resourceBitmap.Width;

Okay, now let's run the app and see what it looks like:

Okay, just what we wanted huh?

Sharing...

mhender — Thu, 16 Mar 2006 19:03:00 GMT

Okay, now I'm really going to show my age... If you're an old fart like me you remember the classic Cracker Jack commericals featuring character actor Jack Gilford where he succumbs to pressure from little kids to share his Cracker Jacks and the tag line was "Sharing...".

Okay so you don't remember huh? Anyway...the point of all of this is to talk about what else...sharing. Specifically I want to talk about a Crossbow scenario where you may have a Windows Forms application that contains multiple ElementHost controls that each contain some WPF content and you want to use shared resources such as styles.

So here's the deal...In a standard WPF application you usually hang resources off of some parent element and in doing so, child element will inherit these resources. For example, say that we want all Labels in a WPF application to have a certain look. To acheive this we would do something like this:

<Window x:Class="WindowsApplication160.Window1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
Title="WindowsApplication160" Height="300" Width="300"
Loaded="WindowLoaded"
    >
   <StackPanel Name="sp1">
       <StackPanel.Resources>
          <Style TargetType="{x:Type Label}">
            <Setter Property="FontSize" Value="14"/>
            <Setter Property="FontWeight" Value="Bold"/>
         </Style>
      </StackPanel.Resources>
      <Label>Hello</Label>
      <Label>Goodbye</Label>
   </StackPanel>
</Window>

This will define the style for all Labels that are children of the StackPanel. So all Labels that are added to the StackPanel will all inherit the style so that they all look the same.

Yeah, so... Well the issue here is that say we have a Windows Forms application that contains some WPF content and you want to be able to create "global" styles for your elements. Furthermore, you may have multiple instances of this or other WPF content spread across your Windows Forms application and you want them to all share common styles. How do you do it? The problem is that you don't have the ability to have application level XAML file (MyApp.xaml) where you could define global styles.

Well, it's really not difficult, you just have to know how to wire it all up. So here's the deal... What you need to do is simply create a global ResourceDictionary to hang your global styles off of and then point all of your hosted WPF content to that ResourceDictionary.

Let's take a look at this in more detail. Say we have a WPF UserControl that consists of multiple Labels. (Yeah, I know...it's totally contrived and you would never build something so stupid, but bear with me it's just for illustrative purposes). So the XAML for your UserControl may look something like:

<UserControl x:Class="GlobalStyleSample.UserControl1"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
   <StackPanel Name="stackPanel1">
      <Label>Label1</Label>
      <Label>Label2</Label>
      <Label>Label3</Label>
      <Label>Label4</Label>
   </StackPanel>
</UserControl>

Now suppose that we want to host this content on a Windows Form form multiple times and we want to globally define how the labels in the UserControls should look and we want each instance of the UserControl to have the same look.

So let's host two instances of the UserControl on a Windows Form form using a SplitContainer to separate the two. To do this, we need to first create the form and then drop a SplitContainer on the form. Then we will put two ElementHost controls (one on each SplitterPanel). Now, to make this easy for us to do, we're going to put the ElementHost control onto our Toolbox so that it will be easier for us to work at design time.

To do this, right-click on the ToolBox and pick 'Choose Items...'

Then you will see the 'Choose Toolbox Items' dialog box. Here you will need to click the 'Browse' button to find the WindowsFormsIntegration dll that contains ElementHost.

Assuming that you are using the Feb CTP of Crossbow, you will find the dll in the Cider directory.

Next you will see the ElementHost control in the 'Choose Toolbox Items' dialog box. Check the check box for the ElementHost control and click the OK button.

Now you should see the ElementHost control in the Toolbox.

Whew, you probably already knew how to do that anyway, but what the hell...

Now that we have the ElementHost control on our Toolbox, let's put this thing together. Let's drop a SplitContainer on our Form.

Next we will put an ElementHost control on each of the panels of the SplitContainer. Just drag and drop an ElementHost on each from the Toolbox. Now, you will notice that the ElementHost gets rendered with its background color the same as the panels and without any borders. This makes it look as though it's invisible once it is not selected. If it bugs you that you cannot see the ElementHost when it is not selected, just set its background color to something else.

Okay, next lets select each ElementHost control and Dock Fill them so that they take up all the real estate of each panel. Now we can put our WPF UserControls on the form by hosting them in each ElementHost. Let's do this by going to the code behind in say the Form_Load event handler to do this.

private void Form1_Load(object sender, EventArgs e)
{
   UserControl1 uc1 = new UserControl1();
   this.elementHost1.Controls.Add(uc1);
   UserControl1 uc2 = new UserControl1();
   this.elementHost2.Controls.Add(uc2);
}

Run the app and it should look something like:

Now we want to introduce our global Label style so that both instances of the UserControl uses the style for all of the labels. We do this by creating a global ResourceDictionary and adding a style to it.

public partial class Form1 : Form
{
   private ResourceDictionary rd;
   public Form1()
   {
      InitializeComponent();

      rd = new ResourceDictionary();

      Style myLabelStyle = new Style(typeof(System.Windows.Controls.Label));
      Setter fontSize = new Setter(System.Windows.Controls.Label.FontSizeProperty, 14.0);
      Setter fontWeght = new Setter(System.Windows.Controls.Label.FontWeightProperty, FontWeights.Bold);

      myLabelStyle.Setters.Add(fontSize);
      myLabelStyle.Setters.Add(fontWeght);

      rd.Add(typeof(System.Windows.Controls.Label), myLabelStyle);
}

Now we just need to point our UserControls to the ResourceDictionary object:

private void Form1_Load(object sender, EventArgs e)
{
      UserControl1 uc1 = new UserControl1();
      this.elementHost1.Controls.Add(uc1);
      UserControl1 uc2 = new UserControl1();
      this.elementHost2.Controls.Add(uc2);

      uc1.Resources = uc2.Resources = rd;
}

Let's run the app and see what happens now...

Sweet! Now all of the WPF labels in our Windows Forms application share the same style.

Okay, I bet you are saying: "Hey, you could've just added that style to the definition of the UserControl in XAML and each instance of the UserControl in the app would share the Label's style". Yep, in this particular case you're right. However, what if the two instances of the UserControl were in fact two different UserControls for example. In that case, I would have had to define the style in both XAML files. This way I only have to define the style once in code behind and wire-up any WPF content to that style.

"I Love It When A Plan Comes Together!"

mhender — Wed, 01 Mar 2006 21:27:00 GMT

I just had to quote George Peppard’s cigar-chomping-glove-wearing character Col. Hannibal Smith from TVs “The A Team” because it seems so appropriate. One of the beautiful things about the software industry is the ecosystem that develops around it and the cycle of information flow between software companies and their customers. So it is really exciting to see a situation where our customers provide important feedback to us and we are able to act on that feedback to better address a customer need.

If you are a regular reader of my blog, you have heard me discuss our plans for shipping Crossbow in the “Orcas” product (the next release of Visual Studio). Many of our customers were quick to respond to that information by letting us know that we needed to do whatever we could to ship Crossbow with WPF. This makes sense of course since many customers are planning on delivering a WPF version of their application shortly after WPF ships and for some customers the control set of WPF lacks some key controls that Windows Forms has (like the DataGridView) and they need to rely on Crossbow in order to ship.

Well, I’m happy to say you spoke and we listened! We have spent the last several months working very hard on developing and executing on a plan where we could deliver the Crossbow runtime as an integral part of WPF. As of the Beta2 release of WPF, the Crossbow runtime will be part of the WPF redist and reside in the GAC just like all of the other WPF components. And from that point forward we will be on the WPF ship schedule which means that we will RTM with WPF.

Thank you for your valuable feedback.

Crossbow on MSDN TV

mhender — Wed, 01 Mar 2006 20:35:00 GMT

Well my MSDN TV debut finally hit the airwaves. I teased you a while back when I told you that it was coming (I didn't realize that it took so long for these to make it to the site). I know you have been just trembling with anticipation, but tremble no more 'cause it here!

Y'know they tell you that you look 10 pounds heavier when you are on camera? Wow, how many cameras were on me anyway? (Okay, I know, I stole that from a Friends episode) Enjoy!

Good News...Bad News (kinda)

mhender — Thu, 02 Feb 2006 04:43:00 GMT

Hello again my Crossbow lovin' friends! Well, I have good news and bad news...Well not really bad news...you can judge for yourself.

So, first the good news...

We are releasing the Feb CTP version of Crossbow with many new changes. Whether you know it or not, the code that we have been delivering in the CTPs since PDC have all been basically the same code base. We finally we are updating what we are sending out via the CTPs with new up-to-date code. Ah, don't you just love the smell of freshly cut code?

So you may be wondering what new features we have added to the Crossbow runtime in this upcoming release. Well, I'll give you a little tastly morsel:

Improved keyboard handling
Improved focus management
Extensible property mapping
Other important plumbing stuff

Sounds nice, doesn't it?

Okay, so what's the bad news?

Well, we have been trying hard to figure out how we are going to ship Crossbow. That amounts to finding the right ship vehicle and doing all the infrastructure work that is required to "get on a release train" as we say (more on that in a later post). This means that there has been some moving around of bits and such. Yeah, yeah, get to the point... Well what this means is that we are kind of in the middle of sorting some of these details out and we are kind of straddling both sides of a particular ship fence. Therefore, in the Feb CTP, we are not only shipping once, but twice! We are shipping in the WinFX SDK like we have been, but we are also shipping in Cider as part of Orcas CTP ("Fidalgo"). That means that if you install the Feb CTP, you will find two copies of our dll (WindowsFormsIntegration.dll) in two different places on disk.

Note that these are different versions of the dll. For this release, you should ignore the version that is place in the "Program Files\Reference Assembly..." path and instead use the one that is in the "C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Cider" directory.

The SDK version of the dll is out of date code and in fact will not work if you are using XAML to instantiate Windows Forms controls due to a breaking change that was introduced by WPF in this release.

The Cider drop of our dll is the one that has all the new code and should be better behaved.

We chose to live with this situation, because of several reasons. We didn't want to remove our stuff from the product all together for the Feb CTP release...that would just be rude! And we didn't want you to have to deal with old out of date and broken code either...so we compromised.

I promise we'll get all of this ironed out soon.!

Peace, Love and Crossbow!

Crossbow on Dr. Dobbs

mhender — Mon, 09 Jan 2006 20:26:00 GMT

I recently did an interview with Scott Swiggart on the subject of Crossbow and the article ended up on Dr. Dobbs, check it out: http://www.ddj.com/documents/s=9776/ddj1134151231499/swigart3.htm

I also did an MSDN TV segment, but it's not posted yet, but keep an eye out for it (http://msdn.microsoft.com/msdntv)

Okay, I'm a Deadbeat Blogger!

mhender — Wed, 04 Jan 2006 02:32:00 GMT

Yikes, you mean the last time I posted something on my blog was on Halloween? Geez, I'm really sorry about that and I'll try to make it up to you...really I will. You see, there's a few reasons why I've been delinquent in blogland lately... One reason is that I just got too excited and posted too frequently and used up all my good material and then I really didn't have anything interesting to say. The other reason is simply just being busy with stuff...then there's the holidays...you know how it goes. But I'm back and I'll do my best to provide some useful content.

I'm already getting some ideas so stay tuned...

Hosting Windows Forms and ActiveX Controls on a Canvas

mhender — Mon, 31 Oct 2005 20:05:00 GMT

I'm blogging to:

KEXP

Live Stream

Happy Halloween!

I received an email from Keeron today and he was experiencing some difficulties in hosting an ActiveX control in a WindowsFormsHost which was parented to a Canvas in a WPF application. His basic problem seemed to be that the control simply was not showing up in the WPF application at all. So what's up with that?

Let's start off by removing the ActiveX control from the equation since the issue isn't directly related to the ActiveX control, the issue exists for just standard Windows Forms controls as well. So let's assume we have a simply scenario where we want to host a Windows Forms button in a WPF application. Let's first consider hosting it in a Grid element then we will switch it to use a Canvas element.

The code behind would look something like:

private void WindowLoaded(object sender, RoutedEventArgs e)
{
     WindowsFormsHost host = new WindowsFormsHost();
     System.Windows.Forms.Button b = new System.Windows.Forms.Button();
     b.Text = "WF Button";
     host.Children.Add(b);
     this.grid1.Children.Add(host);
}

Run the app and everything works just fine. But now lets change the Grid element to a Canvas element...

And change the code behind to reference the Canvas instead of the Grid:

Run the app again and we don't see our button! What gives? Well, let's think about it just a second. Firstly, I neglected to indicate where in the canvas the button should go. Normally, you would do this is XAML as follows:

<Canvas x:Name="canvas1">
<Button Canvas.Top="5" Canvas.Left="5">I'm a button</Button>
</Canvas>

But I'm working in code so I need to figure out how to do this using C#... Well the Canvas.Top and Canvas.Left properties are actually "attached properties" in WPF parlance and to set these using code you would use the SetValue() method on the object in question and then provide the property and value:

Cool, that should do it right? Let's give it a whirl... Doh! Still didn't work! Why not? Well, the issue is related to how the WPF layout engine works. The problem is that since we did not explicitly set the size of the WindowsFormsHost control, the layout engine thinks that it has a size of 0 and therefore does not layout the control properly. To fix this, we just need to give the WindowsFormsHost control an explicit size:

private void WindowLoaded(object sender, RoutedEventArgs e)
{
     WindowsFormsHost host = new WindowsFormsHost();
     host.Height = 100;
     host.Width = 300;
     System.Windows.Forms.Button b = new System.Windows.Forms.Button();
     b.Text = "WF Button";
     host.Children.Add(b);
     host.SetValue(Canvas.TopProperty, 5.0);
     host.SetValue(Canvas.LeftProperty, 5.0);
     this.canvas1.Children.Add(host);
}

Now when we re-run the application, we will see our button.