So, I'm ramping up on XAML. In the smart client version of CMS, we'll allow the users to modify the content metadata on a two-column display (description on the left, text/check/combo box on the right). If the value is changed, a tooltip will show the previous value.

But there's a problem. According to the docs, ToolTips can't have a Parent; they're a brand new window without the hierarchy. So how do you bind it?

I posed the question to our internal Avalon Discussion alias, and recieved several replys. Figuring I'm not the only person to have experienced this problem (and having a known propensity towards tooltips), I thought I'd share them. But first, the setup:

I have a UserControl that wraps the behavior of description/___Box/Tooltip, so that the main page just drops one of these controls whenever it has a new textbox. This control is named "SGT", which has a dependency property OriginalValue. Here's what it looks like when I started out (note that it doesn't work-- ToolTip will not have access to SGT):

<UserControl x:Class="CMS_Client.Controls.SubmissionGridText"

    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

    x:Name="SGT">

    <Grid>

      <Grid.ColumnDefinitions>

        <ColumnDefinition SharedSizeGroup="Col0SizeGroup"></ColumnDefinition>

        <ColumnDefinition SharedSizeGroup="Col1SizeGroup"></ColumnDefinition>

      </Grid.ColumnDefinitions>

      <Grid.RowDefinitions>

        <RowDefinition></RowDefinition>

      </Grid.RowDefinitions>

      <TextBlock Name="Descriptn" Grid.Column="0" Grid.Row="0" Text="{Binding Description,ElementName=SGT}"></TextBlock>

      <TextBox Name="ValueTextBox" Grid.Column="1" Grid.Row="0" Text="{Binding Value,ElementName=SGT}" ToolTipService.InitialShowDelay="500" ToolTipService.ShowDuration="60000">

        <TextBox.ToolTip>

          <ToolTip Name="PreviousValue" Placement="Right">

            <TextBlock Text="{Binding OriginalValue,ElementName=SGT}"/>

          </ToolTip>

        </TextBox.ToolTip>

      </TextBox>

    </Grid>

</UserControl>

The first suggestion (Neil Kronlage) was to set the DataContext on the UserControl to be itself, and then the ToolTip would inherit that context:

<UserControl x:Class="CMS_Client.Controls.SubmissionGridText"    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Name="SGT"
    DataContext=”{Binding ElementName=SGT}”>
…
        <TextBox.ToolTip>
          <ToolTip Name="PreviousValue" Placement="Right">
            <TextBlock Text="{Binding OriginalValue}"/>  <!--this uses the datacontext -->

A second suggestion (Neil and Adam Smith) was that we could use PlacementTarget in the binding. This is nice, as I am actually inheriting the DataContext already from the page that hosts the DataControl, and this would allow the ToolTip to gain access back to the origial control. As Adam noted, though, you have to be aware of the parent/child structure off your markup:

          <ToolTip Name="PreviousValue" Placement="Right" 
           DataContext=”{Binding RelativeSource={RelativeSource Self},Path=PlacementTarget.Parent.Parent}”>
            <TextBlock Text="{Binding OriginalValue,ElementName=SGT}"/>

Hope that helps someone out there. Appologies if the formatting comes out odd; I pasted snippets right out of the emails.

I made my way over to Gamefest was this week, a conference geared to game industry professionals (developers/testers/marketers). I was rather hoping that my manager would agree to cover it as a training expense, but that was a no-go. Fortunately, I was hooked up with a Microsoft discount code by a fellow employee.

What an amazing event. The catering was fantastic. The party on Monday was great (complete with a Segway slalom course). But the true excellence was the content of the conference itself. Sessions covered designing multi-core applications, managed code performance tricks, Direct3D 10 analysis, XNA (wow!), and over a hundred more distinct talks.

One of the best sessions for me was Taming the CLR: How to Write Really Fast Managed Code by Rico Mariani. I understand he has covered a lot of what he presented in his blog, and can't wait to check it out. I also found out he's in the same building as I am... I plan to chat with him about the talk when he gets back from vacation.

Just before I went on vacation, I picked up the Motorola Q, which runs Windows Mobile 5 Smartphone. Microsoft is working with Verizon Mobile to offer a pretty hefty employee discount, both on the hardware as well as the service plans.

I downloaded the 900MB Windows Mobile 5.0 Developer Resource Kit, the Windows Mobile 5.0 SDK for Smartphones (possibly not necessary), ActiveSync 4.2, the Motorola Q Developer Guide, and the Emulator Image for the Q (makes the smartphone emulator look just like a Q).

The first thing I did, of course, was try my hand at writing a game. I threw together something on my first day in Oregon, loosely based on geometry wars and implemented using GDI. A square is moved around on the screen, chased by circles that must be shot down.

I implemented it with techniques from a Design Patterns course I took earlier in the month. Shape objects have behavior objects (Decorator pattern) that can modify the owner (such as a Sin/Cos behavior, which alters the parent's course in an elliptical pattern, or a MoveToShip pattern that moves the shape towards the ship). The Shape object itself is an abstract class, with a GDI-specific implementation (Strategy pattern). Factories and adapters, oh my! 

A testament to patterns
Later that week I got around to adding a Managed DirectX implementation of the various objects, and it only took a couple of hours. This week I added black hole, which modifies all other objects on the screen to move towards the owner; it took less than 30 minutes to implement the new Behavior and add the code to instantiate it. Design patterns rock. :)

There will be a post soon about a couple odd problems I ran into.

Today I went over to the conference center and watched a presentation put on by Dale Dougherty, Editor and Publisher of Make, and Phillip Torrone, Associate Editor of Make Magazine.

It was a pretty interesting show. They had shirts and free magazines (gone by the time I got there), and a lot of sample made stuff. The presentation itself went into the reasons why they thought there was a maker resurgence, and the thinking behind what they did. Tidbits like: The trim size of Make was based off the 1959 Popular Science magazine, and the prescience of the Craft Manifesto.

He also brought his portable rotary phone. The first caller to ring his number (206-355-1XXX) received a gift. It was pretty odd hearing the old-school phone ring wirelessly. Over and over again as different callers made it through.

At the end, Microsofties had the opportunity to tell what they were making. Personal projects ranged from robots, to 30' working pirate ships with the kids for the back yard (complete with 50-calliber canons), to a compass that always shows the direction to the nearest starbucks.

Finally, a few links I picked up:

• Phidgets USA, providers of lots of project parts.
• Spark Fun Electronics, "Where most of my disposable income goes." -- Torrone
• Instructables, step-by-step project recipes and collaboration

"The best way to predict the future is to build it."

When I got back, I was telling Lance about the presentation. In the course of the dialog, he mentioned that he wanted to pick up C#. I pulled out one of the better C# books, Inside C#... and he said, "Doesn't that name look familiar?   You sit next to him." Sure enough, Tom Archer joined our team a few weeks ago, and sits in the office next to mine. I just hadn't made the connection yet. Small world!

Last week I attended a two-day course on performance engineering. It was really high-level, and covered a lot of common-sense items, but it was still rather interesting. It looks like the "free ride" of processor speed improvements is coming to an end, and Microsoft is embracing the need to focus on performant features. This is a heartening decision, one that I hope sticks.

I took more than five pages of notes in Word, but a few takeaways were:

• You will be wrong more often that when you are right on your first guesses as to performance problems. The secret to greatness is weeding out the bad guesses as fast as possible.
• An L1 cache miss is now as expensive as what a page miss used to cost to go to disk. -- If a register access took a second, a disk access would be a couple of weeks, and the internet would take most of a year.
• Inefficiencies can happen in the app, but others can be in the OS or Hardware. Almost all of these can be reduced by changes in the application.
• Amdahl’s Law: The performance that can be gained by using a faster mode of execution is limited by the fraction of time that does not execute faster.
In other words: Focus on where the application is spending the most time.

Training
Speaking of training, there is a lot of it available. For example, just one of the several training websites available internally has 20 events coming up next week, ranging on topics from Secure Software and Developing with Design Patterns to ITIL Essentials and Designing for Performance on SQL Server 2005. And this doesn't include the hundreds of courses that were recorded and available as a webcast.

Town Hall
I started this post while waiting for the Employee Town Hall webcast to start, which is also being broadcast to nine of the Cafe's. There was a lot of good stuff in it. The first 1.5 hours brought us up to speed on what the different divisions were doing; the last half hour was the best, though, discussing changes to the review system. It is mostly moving away from the curve-based highly competitive ranking that existed before into the realm of individual performance-based rewards. This, in combination with the on-site/home-based perks announced (towels are back!), is very good news indeed.

The website that I coded has been holding up well; I'm still waiting for people to review the latest changes before I can roll them out. In the interim I've added a few feature requests, and spent most of my time studying. It's very nice to have the time to keep your skills up-to-date.

Every quarter or so the team goes on a morale event. This time out we went miniature golfing. I haven't been to a miniature golf course in probably 8 years. This one was at the Willows Run golf course (aerial pic), and didn't have all the props that I grew up expecting (windmills and the like). Even though I was quite bad at it, it was still a lot of fun to hang out with the guys.

In this group there have been two developer managers. One is moving on to another position in Microsoft, and my current boss (Mike M.) will be managing all of the developers. In my experience here, reorganizations happen at least yearly, though they rarely have a direct impact on the project you’re working on.

We won! It was a Swiss-style championship, 12 teams facing off with another team with a similar record for seven rounds. We started out with five wins in a row... the last two got tough. The sixth game was a tie with a very good team (neutral bomb assault on Sanctuary). With a tie there, we had to win the last match or would face a tie breaker. We started out Slayer Pro on Burial Mounds, and our team kind of fell apart. At around 21-30 we started to turn it around and coordinate better. We won 50-39.

The fastest match was the 5th round (3-flags to win CTF Classic on Elongation). It took us three minutes to cap all three flags against a team with only one loss.

Loot for winning: Kameo Pen, Lanyard, XBox 360 button, a gift certificate... and a 360 faceplate signed by J. Allard. Not to mention bragging rights having taken on all the Developer Division's finest. And we keep the trophy for 6 months. :)

Stair Climb Challenge
Less interesting to most, but I did win the challenge. I climbed the equivalent of 2+ Sears Towers in the last week, 130 flights Friday night alone. I was extremely sore, but ended up winning by 25 flights. Loot for winning: A cheap exercise radio. Could have used that a week earlier. :)

and.... Work
Much more work than play these last few weeks. We shipped the first version of the Content Management System on Monday. It's been a long four months, but contributors are finally using it. There's been a lot of feedback, and some of the pain points I expected to have time to address this week are already cropping up. But once the early-adopter kinks get worked out, it should really improve the process.

Oy. It's been a crazy few weeks. First there was the big push to get everything done while the manager was out, and ready for an internal preview release.

The website was fully functional, and had been for a week or so. I was planning to spend the remaining time incorporating user feedback and wrapping up some edge-case bugs. What I didn't count on was that the other developers needed changes. A lot of them.

So, I spent most of my time working on those. No worries, we're a team, and I was happy to provide support for our efforts. I would have liked to have been more finished with the front end, so that I could help them out with the back end and workflow stuff, but I didn't mind having my hands full keeping the front end operational as the back end shifted around.

Well, Mike got back last Monday, and the software wasn't ready for an internal preview release. It was disappointing to have put in the extra effort and have the call be made to delay the release a week, but we understood.

I took the extra time to talk with the PMs that would be using the software/coordinated the users of the software. In these one-on-one walkthroughs I had quite the eye opener! Now, granted... some of the comments they filed were duplicates (the ones that I had planned to incorporate earlier); but I ended up with a list of over 55 changes. This necessitated yet another product slip, only a few days after Mike had to announce the earlier slip to our group... this time on my side.

We had a big triage meeting late last week to cover these change requests, in which we broke the single dialog that supported file addition into six different dialogs, dependent on the user need. It's a lot of work in a short amount of time, but I really do think that the changes will be for the best. The users will have a much more intuitive interface, and the PMs will receive higher-quality submissions.

A few takeaways:

1. Schedule one-on-one time with your stakeholders. Don't assume that they have the time to review the product on their own whenever you send out update mails; walk through it with them. Keep notes, especially whenever they ask questions for clarification: If they don't know what something does, the users won't either.
2. There is a reason for specifications. Now, this particular project was undertaken with full knowledge of the potential pitfalls of spec-as-you-go... but I think we actually hit most of them.
• Client & Server side developers had requirements that were not apparent to each other during initial development.
• Late-breaking changes required much more time to rework than if they had been made at the beginning.
• Late-breaking changes necessitated less clean code. Rather than completely refactor a component and introduce instabilities, I made the decision to have slightly less maintainable (and consequently much more commented) code.
• Customers are (usually negatively) surprised when their vision of the product doesn't conform to what was implemented.
• Due to the number of stakeholders, there were often conflicting feature requests. Working with stakeholders one-on-one prevented group resolution.
3. There are advantages, time-to-release being the main reason for choosing this method of development: 
• We've been able to create a product from scratch that will heavily automate a massive amount of workload in around three months. It would have probably taken than long just to finalize specifications and create the first mockup.
• The ability to create mockups on-the-fly provided for very fast feedback.
• Whenever problems were discovered with the design, the small number of developers involved could quickly meet, discuss alternatives, and make a choice. This resulted in very little time spent in blocking issues.
4. Having professional coworkers really makes a huge difference (i.e. I work with some great guys and gals). It's amazing to be able to discuss technical problems and solutions without having politics or ineptness get in the way. Though some of the things we have to do for our legal people can be quite demanding. :)
• For example: We have to store every bit of information about the files, and who can be contacted if there are problems with the files, even after they are "deleted." And this information must be quickly accessible.

There's probably more I should put in here, but I'm working late and coming down with one of those achy colds. So... good night, and see you next week. Hopefully I'll tell you how the first roll-out went.