The Team Prima Donna

with 7 comments

This post is part of my series on Managing Developers – How not to suck

We’ve all worked with them at one time or another – the loud, opinioned, argumentative, authoritative, hardworking, smart capable, type A developer. The guy that always seems to have an opinion… on everything. The guy who’s code review feedback is usually something like ‘that code doesn’t look like my code’. They dude who wrote the super-complex-only-he-can-understand-it code your entire product depends on. You know, the code everyone else is forbidden to touch. The code that has no comments because it is all ‘self documenting’. He tells you he doesn’t have time to write comments anyway(1). The guy that must use every esoteric odd language feature he can find because coding it simply is too ‘verbose’. This is the guy that gets loud and upset at the drop of a hat. The guy that has to use the most complex (beautiful he says) algorithm for even the most mundane tasks. They guy that writes his own debugger because existing one just isn’t good enough. The guy that wrote his own domain specific language (using complex regular expressions) because “there was no other way to solve the problem”. They guy that uses LINQ expressions for everything because they are ‘fluent’. They guy that gets impatient when other people can’t instantly understand his code. This is the guy that to fix a bug, works straight through a weekend and completely re-writes a big chunk of code because ‘the code needed to be re-written anyway.’ This is the guy that always expects an ‘A+’ performance review – every single time.

You know – the team prima donna: a vain, undisciplined, egotistical, obnoxious or temperamental person who finds it difficult to work under direction or as part of a team, and although irritating, cannot be done without.

The Big Problem™ you likely face with your prima donna is that he is probably is also a genius or a 10X developer. The team depends on him. You depend on him. He gets a lot of work done, and he works a lot of hours. He is also very likely visible to your management chain, CEO or other Important People™.

Let me ask you three questions about your team prima donna.

  1. How much time do you and the rest of your team spend dealing with the prima donna?
  2. Is his code really that good?
  3. What would your team look like if he quit tomorrow?

In my experience the team prima donna soaks up an awful lot of other people’s time. I’ve spent way too much time cajoling, soothing, arguing with, and otherwise dealing with the team prima donna. Think about it this way – compared to other people on your team how much time do you spend dealing with the prima donna compared to others on your team? How much time do other team members spend dealing with the prima donna? If your experience is anything like mine, it is disproportionally much higher.

How much does the genius annoy, frustrate or simply piss off others on your team or people on other teams? How often have you had to sooth another team member and make excuses for the genius? Do others on your team avoid working with him? Do they walk on egg shells around him? Are they careful what they say to him in meetings? How about yourself? Are you happy to see the genius in your doorway? Or do you cringe when he walks in your door? Can you trust the prima donna talk to customers? Does the prima donna get his way because it is simply too costly and disruptive to argue with him?

Think about his code, is it really genius code? Or is it merely over designed and over implemented? Did that problem really require the use of C# expression trees? Or a hand rolled recursive decent parser? Did he really have to write his own debugger? Did he really have to write his own custom template based XML de-serializer? Really? I’ll bet if you went back and looked at his work you will find it to be over designed, difficult to debug, difficult to understand, fragile, and challenging to maintain for anyone but him. Very likely the problem could have been solved in a more simple manner.   Does he get his work done on time?  Or is everything always done right at the last second?

Think about the third question – what would your team look like if the prima donna quit tomorrow? Your first reaction is probably ‘Oh crap! We’re screwed!’. But think about it some more… would the quiet guy who is often overshadowed by the genius be able to shine? Would the frustration and friction levels on your team go down dramatically? Could that smart kid form the test team who really wants to be a developer now step up? Would you have more time to coach and mentor your other team members with him gone?

If your experience is like mine, then the prima donna is likely not as nearly as beneficial as you or others may think. Its likely that he is really quite disruptive and the technical value he brings to the team not really that super-awesome.

As manager, your job is to help the prima donna maximize his benefit to the team while minimizing or eliminating his disruptive behavior. You must help him understand that the high costs of having him on the team are only a little lower than the benefit he brings to the team. Help him see how much time he costs everyone else. For example, help him see that he cost the test team two weeks of regression testing by re-writing that big pile of code over the weekend and he forgot to re-write all the unit tests. In short, your job is to help him mature.

This isn’t easy. The team prima donna doesn’t take constructive criticism well. He is volatile, stubborn and will almost never agree with you. But you must try anyway because there is a chance you can help the team prima donna become a solid team member. That’s a great outcome.

Even if this doesn’t work, your efforts will benefit the rest of your team. They will see you as helping them by minimizing the prima donna’s disruptiveness. This can do wonders for team moral and the team’s trust in you.

The really hard part comes if the prima donna simply doesn’t come around. If this happens, you need to get the prima donna off the team – they are just not worth it. Disruptive people are death to an otherwise good team, even if they are a genius. While painful in the short run, both you and your team will really be much better off without the prima donna.



(1) I actually had a developer tell me this many years ago. It just took too much time to write comments.

Written by foredecker

June 12, 2011 at 8:55 am

Your Job is NOT Telling People What To Do

with 15 comments

This post is part of my series on Managing Developers – How not to suck

I’ve had many people tell me they would like to be a manager. The first question I ask is ‘why’? The absolute worst answer is any variant of ‘Because I want to tell people what to do’. Any thing remotely like this is the wrong answer. These people are not ready to be managers – they are far from ready. Organizations that make people like this managers are making a huge mistake.

Much of your job as a manager is to enable your team. You are paying them to think, solve problems and get stuff done on time. Let them do it. Your job is not telling people what to do.

Enabling your team means setting them up for success, making sure they do their best work with good continuity over time, not just at crunch time, or ‘when it counts’. If you are thinking, "Yes! A managers job is to make people do their best work." Then you are not understanding this advice.

Merriam Webster defines enable like this:

  • to render able as in enable a person to
  • give power, strength, or competency to
  • to make possible, practical, or easy
  • to give the opportunity to

The term make is defined like this:

  • to cause to act in a certain way. To compel

Making people do things is telling them what to do. Enabling them is an entirely different thing. There are lots of ways to do this. I cover some of them in this series of posts. Here are a few in no particular order

  • Don’t forget what its like to be an individual contributor (post)
  • All developers shall have good equipment (post)
  • Don’t treat people fungibly (post)
  • Know when to shut up and just listen.
  • Depending on Heroics is "Epic Fail"
  • Praise in public, criticize in private
  • Make sure people know what to accomplish, by when and what ‘done’ looks like
  • Be your team’s champion, not their defender

This may not sound too hard. But let me make it harder – you can’t do this sometimes, like just at crunch time, or just when the bug count is high, or when the requirements change. Your job is to help your people deliver their best work all the time. It sounds impossible, but the closer you come, the better it is for everyone.

Now, this doesn’t mean you can avoid making decisions.  Part of your job is defining constraints, specifying requirements, setting expectations and defining direction. 

You will also sometimes need to be directive or proscriptive.   Yes, you will sometimes need to tell people what to do. But remember, there is a big difference between reluctantly doing this when necessary, and with good reason and explanation – and being a tin pot dictator.

Here is what I’d like you to remember. If you feel your role is to help your team, you are on the right track. If you feel a visceral need to order people about, then you will suck as a manager – not matter how good you are at everything else.


Written by foredecker

March 13, 2011 at 8:12 pm

All Developers Shall Have Good Equipment

with 2 comments

This post is part of my series on Managing Developers – How not to suck

In 2011, the minimum primary development machine is a quad core system with 8GB of memory, a 64-bit OS, a fast boot drive, a 1Tb secondary drive, a gaming quality graphics adapter, and two 1900 x 1200 monitors. A system with an SSD boot drive is even better.  Providing people a mouse and keyboard they like is groovy.

Many developers should have a good lap top like the Lenovo W500 – with an SSD.

None of this is expensive and your developers will get more work done and be happier if you make sure they have good equipment. There really is no excuse for your team to have poor equipment.

You can do more as well. Many developers will need a couple of test systems. These are systems they can re-image at will, configure for debugging and diagnostics, or install test versions of an OS or other software. These should be on a KVM system so their desk isn’t cluttered with monitors and keyboards.

Its good if one of these test system is "low spec", something like an old P4 system with 1GB of memory, an Intel 945G graphics adapter and an old 4,200 PRM mechanical disk drive. This lets your developers make sure your software will run on low performing systems.  Intel Atom based systems are also good low spec test systems

Want bonus points? Let your developers use the code editor of their choice – even if this means buying it for them. Developers love their favorite editors and will be more productive when using them. Many good ones are free, the others are not expensive.

Get them extra tools they ask for.  For example, RedGate’s Reflector is an essential tool for .NET development.  Its only $35.

Sometimes developers will need special equipment. Get it for them. If they need this throughout a development cycle, get them their own gizmo – don’t make them share. Sharing works only if people need something rarely. If they needed it more than once or twice a week, or for a few days at a time, then sharing is just a pain – it is very inefficient. You want your developers to be efficient, right?

Don’t suck – make sure your team has the equipment and software tools they need to get their job done.


Written by foredecker

March 5, 2011 at 1:56 pm

Posted in Managing Developers

Tagged with

Status Reports Suck and Everybody Hates Them

with 5 comments

This post is part of my series on Managing Developers – How not to suck

When I worked at Compaq, we had an executive that just loved status reports. They were executive crack. His idea of managing was making sure everyone did their status reports on time. He was ultimately fired in a very public and very satisfying way. We had a party – really.

Every week he had the whole team stop what they were doing and write status reports. We had a very well defined status report format. Each team member would send their report to their manager, who would then combine them into a team status report. He would then send them on up the chain, they would be summarized again, and eventually they would all get to the executive.

Here comes the hilarious part; a few days later we’d be in a meeting with various folks – and the executive – and someone would ask a question. The reply was invariably “well, that was in my status report…”. This theme occurred with great regularity. Even though we had status reports, managers would ask questions as if we had no status reports. The executive was the worst.

Awesome. We spent a whole bunch of time, effort and energy running a process that caused us to write stuff nobody read.

It was really even worse: a pretty significant number of people didn’t get their status reports to their manager on time. Why? Because they were busy doing real work. This resulted in nag mail. Nobody likes nag mail. Relatively often people wouldn’t get their report in at all. Missing a status report got you on the execs radar – always a bad thing.

Why do status reports suck? Two reasons:

  1. Because status reports are always required to be short summaries – often bulleted lists with brief descriptions. The idea of course is people will read them if they are short.
  2. They are always done on a weekly deadline. This is a massive team wide synchronizing event.

Software development work is complicated. There are rarely simple issues. Simple bullets just lead to questions that need to be answered in detail. Proponents will point out that the status report let managers “drill into” interesting things and “manage by exception”.

That’s not managing by exception – it’s managing by being random. In this system, developers just get jerked around. They have no way to know what is interesting or exceptional because it always changes from week to week and is different for different managers.

People are not mind readers – unless you tell them ahead of time, they will not know what you think is important. So, people go in two directions; blowing of the status report off, putting the absolute minimum work into them they can get away with; They know they will get ask the same questions either way. Or, they will put too much work into it, wanting to be prepared for questions with detailed answers.

Status reports are disruptive: There is always a weekly deadline. This means that once a week, everyone stops what they are doing and writes their status report; all at the same time, no matter what else is going on. Each week – this makes status reports the single most important thing everyone is doing. This is just dumb.

Status reports also add latency: at best it takes two or three days for all the status reports to be written, rolled up and sent up the chain. It takes more time if there is something controversial or problematic happening; then the status reports are vetted and often sent back for revision, or edited heavily so they “express status in a measured manner” (e.g. spun). So, by the time the people that want them need them, the information is already old and things have changed.

If those reasons were not enough to avoid status reports, carefully note that developers hate them. Why? Because they are something that you (Mr. Manager) are making them do that doesn’t help them get work done; status reports are intended to help someone up the management chain they rarely talk to or hear from. You don’t need a status report because you talk to your team every day – right?

There are many ways to avoid status reports, all of them are better than having status reports. Here are four:

  • Have a system that sends “check in mail” to the right people. Check in comments should have useful information in them. Such as: “Initial check-in of the XML manifest schema checker”. Look ma! No status report needed.
  • Use your bug tracking system to keep track of the state of bugs and work items. All good bug tracking systems do this. Then, have a system (often included with said bug tracking system) that can automatically generate reports of progress and status. Bonus points for doing this with a web page. This is really easy to do. If you don’t have one of these for your team or organization then write one – you are all software developers… you can do it.
  • Use a project tracking system (like Microsoft project, Team Foundation, FogBugz, or one of many others, and let people update progress and task completion as they work. This goes into a database that managers can query when they choose.
  • Create an effective and light weight process for managing exceptions, problems, and blocking issues. Problems (say a newly discovered bad bug) need to be communicated right away, and not wait for a status report. The most important thing about this system is that problems shouldn’t be treated like fire drills. If you find that problems regularly put your organization into fire-drill mode then your managers have something they need to fix.

There are probably many others examples. Good management systems share three important characteristics

  • They are all asynchronous and timely. Developers can update the information at appropriate times such as when they complete tasks, or they are at natural stopping points.
  • Its easy to use – for everyone. Developers can easily update information – anytime. Managers can easily get reports any time. Anybody, not just managers, can query the system at any time to see where things are – they don’t have to wait on anybody.
  • Its automatic. Nobody has to do any manual work. Dashboards simply show the current status People are notified of problems right away.

Believe me – this kind of system works really, really well. Developers like it, managers like it. Everyone is happy. It’s also really efficient.

You invest in good computer systems for your developers, version control, and a bug tracking system. You should also invest in an effective work tracking systems and processes. It will make everyone’s lives easier – really

So, don’t suck. Don’t make your people write weekly status reports.


Written by foredecker

March 5, 2011 at 1:51 pm

Posted in Managing Developers, Uncategorized

Tagged with

The word you are looking for is “People”…

with 6 comments

This post is part of my series on Managing Developers – How not to suck

My wife says I have too many pet peeves. Oh well, we all have our crosses to bear. One of my peeves is calling people ‘resources’. Managers do this all the time: “How many resources will project banana need ?”, “Our resources are all subscribed.”, “Our team doesn’t have enough resources to do any additional work”.

Resources are ‘things’, including computers, tables, chairs, graphics cards, solid state disk drives, the lab. Money, and time can be resources too, but are important enough to treat separately.

Short story: people are not resources. Don’t ever forget that the people that you mange are people, not resources.

Treating people as ‘resources’ leads to all kinds of manger mistakes. The biggest sin is assuming people are fungible. We all know this isn’t true; developers (people) have a wide range of skills, aptitudes, aspirations, and experiences: people vary – wildly – in many dimensions. This means they cannot all be assigned the same tasks while expecting the same results.

Of course, we expect all developers to share some basic skills; using the source code control system; building the code; using the debugger; etc. It is also fair to expect more from more senior developers; sometimes this is more work, or the ability to solve tougher problems, or to be responsible for more code, or drive things in broader ways. We also often expect more senior people to provide more leadership.

But beyond the fundamental expectations, developers are almost always very different. They are almost never interchangeable and – most importantly – given the same task, will almost never solve problems the same way, write the same code, or otherwise do things the same.

One thing a good manger spends time on is assigning the right work to the right people. Treating people fungibley screws this up. You can’t just smear work around like peanut butter on a bunch of crackers and assume it will all be done well.

Work to understand the people on your team: read their old reviews; talk to them; understand what motivates them. Learn what they find interesting and challenging. Observe what they do well, where they struggle. Understand their experiences and where have they had successes and failures. Ask them where have they struggled and where they feel they can grow. Understand how they best like to hear constructive feedback. To the extent possible, make sure you have well matched the task to the person.

If you understand your team as people, then you can more effectively help them do their best work with good continuity over time. This is 80% of your job.

Don’t treat people as resources – that sucks.


Written by foredecker

March 5, 2011 at 1:48 pm

Posted in Managing Developers, Uncategorized

Tagged with

Don’t forget what it’s like to be 10

with 10 comments

This post is part of my series on Managing Developers – How not to suck

Remember what it was like when you were 10 years old? I do. In the summers our mothers kicked us out of the house in the morning and didn’t expect us home until dinner time, or later. We spent all day riding around on our single speed bikes causing minor trouble. We usually had lunch or dinner at the friend’s house we were closest too when hungry; our mothers treated us like a pack of wolves. We found cool junk, built forts, had dirt clod fights; shot each other with BB guns, swam in the pond, fell out of trees, blew stuff up, shot turtles, played in the mud, and got chased out of vacant lots by old men. It was a blast.

I often ask people "Do you remember what it was like to be 10?” By far the most common answer is something like ‘No, not really…” Bummer.

This applies to development managers too. I often ask them “Remember what it was like to be an individual contributor” or "a new developer on a team"? The usual answer is "no, not really", or something worse – a bunch of hand wavy manager talk. Bummer.

This is a huge problem – especially for first line managers who often forget this stuff the day they are made a first line manger.  Its like they went through a manger brain wipe in some evil lab.

If you don’t remember what it’s like to be an individual contributor then how can you manage them? Forgetting this leads directly to many dumb manager mistakes (many of which are discussed in these posts).

Do you remember how interruptions screwed with your concentration? No? You should. Context switches and interruptions are disruptive and expensive when a developer is in the middle being thoughtful and creative.

Do you remember how annoying it was to go to poorly run meetings with no agenda, where nothing was discussed that pertained to you, or where the meeting always resulted in ‘action items’ consisting of needless bureaucratic work?

Do you remember how disruptive it is to have your manager, or your manager’s manager ask "are you done yet", ever time they saw you?

Do you remember that its really hard to predict how long some things will take?  Bug fixing is a great example.  Managers ask “When will bug 2372 be fixed?”  The developer thinks “Man, I don’t know, if I could tell you when it would be fixed, I would know how to fix it.  If I knew how to fix it, it would already be fixed!”

Do you remember what it’s like for everything your manager asks you to do was of the "highest priority" or needed to be done with the "highest quality… tomorrow!" ?

If you don’t remember what it is like to be an IC, you will suck as a development manager no matter how awesome you are at everything else.

So, don’t forget what it’s like to be an IC; don’t manage your team… help your team. Your job isn’t telling them what to do. 80% of your job is understanding what your team does, and what they need to accomplish their job; then helping them do it.


Written by foredecker

March 5, 2011 at 1:44 pm

Posted in Managing Developers

Tagged with

Managing Developers – How not to suck

with 10 comments

I’ve been a development manager for 15 years. I have had the privilege to manage some great people – many of whom have become lifelong friends. I’ve also managed people I never want to hear from again. I’ve had some good mentors along the way and I’ve worked for some great mangers, a couple of crummy mangers, and one psychopath. It’s been both a rewarding and challenging experience. People who have worked for me tell me I’m a pretty good development manger.

Along the way, I’ve gotten to know many other development mangers. I’ve seen a few really good ones, and many bad ones. I have enjoyed working for a world class manger at Microsoft. I’ve also seen a couple of mangers who have been fired for how badly they manage people.

Managing developers is really hard. Why? Because software development is fundamentally a creative activity, like music, art, architecture, math and writing: Yes, yes yes…. there are strong engineering and scientific aspects to software development. Good engineering, and sometimes a scientific approach makes good developers better. But at the end of the day writing good software is a creative exercise and managing creative people is simply hard.

We pay developers to do two things: think and be creative. Good thinking and being creative cannot be mandated, both must be enabled. 80% of a development mangers job is enabling people to do their best thinking, and be creative, with good continuity over time. Its is impossible to plan, manage or schedule thinking and creativity.

The other 80% of our collective job is shipping stuff.  At some point in time we need to ship our software to the people who will use it.  Shipping can be engineered, planned, scheduled and managed. The challenge is that enabling people to think and be creative is requires a very different skill set than shipping.

If you want to be a good development manger, then your first task is to simply not suck.  Sucking at some management aspect is like a golfer who can’t putt.  A golfer can have a miracle drive, long and straight, a great approach game, but if they can’t putt – their drunk buddies who can putt will beat them.

This series of posts is my advice on how not to suck as a development manager.

I hope you enjoy this series as much as I enjoy writing it.

Best Regards

Written by foredecker

March 5, 2011 at 1:40 pm

Posted in Managing Developers, Uncategorized

Tagged with

C# IShellLink COM Interop Example #1

with 2 comments

I recently needed to use C# to programmatically create a shortcut (.LNK file) to a console executable. This is easily done in native C/C++ using the ShellLink CoClass, the IShellLink interface and their related interfaces.

I looked around and couldn’t find a good C# COM interop example for the related native COM interfaces so I wrote one.   This was a good excuse for me to learn a litle bit about C# and COM interoperability.  You can find the source code here, provided under the Microsoft Permissive License.

This first cut provides a set of C# classes and related values for manipulating Windows Shell Links.  The public methods, properties and enumerations (or just publics) are C# style – I didn’t let the underlying native names leak through.

For example, an important native enumeration is the native SHELL_LINK_DATA_FLAGS enumeration.   I’ve seen some interop examples that expose the native names of things publicly in C#.   This works, but doesn’t follow the .NET Design Guidelines for Class Library Developers (in hardback on Amazon).   Exposing the native names is a bit ugly in .NET languages, and in C# in particular.

In the public aspects of my C# I provide the native functionally in a modern C# manner.  For example, I  provide a .NET enuneration named ShellLinkFlags which provides the values in SHELL_LINK_DATA_FLAGS.   These enumerations have C# style names like RunAsUser instead of SLDF_RUNAS_USER.

Another important attribute is that all of the publics are CLS compliant.  This enables all .NET languages to easily access these classes, not just C#.

There are some limitations to this code.  I built this so I could create shell links to EXEs – primarily console applications.    This code does not yet support the IShellLink.GetIDList() and IShellLInk.SetIDList() methiods.  So, it can only be used to link to things in the file system, and not shell objects such as printers.

The Project

This code is provided in a Visual Studio 2010 project built with C# and .NET 4.0 using the client profile.

The actual shell interop code is built in a separate class library named Eidos, which is the name of my general purpose C# library.   The namespace is Eidos.Shell.   You can use this directly, or easily incorporate it into your own code.

I’ve also included a couple of basic unit tests – you can extend these as needed.

There is also a simple program that will dump the contents of a Shell link file to the console.

The Code

The primary public class is ShellLink.  This provides a set of properties and methods that provides the functionality of IShellLink but in a C# manner.

One of the biggest differences between the C# APIs and the native COM interfaces are how Data Blocks and IShellLinkDataList are treated.    These are not exposed in the my .NET classes.  instead, they are wrapped using standard properties on the C# ShellLink class.

This works really well.  It means you can simply get and set property values just like you would with a “normal” .NET class.   The IShellLink class handles all the work of creating, writing and reading the data blocks using an internal IShellLinkDataList interface.

Download the Source

You can find the source code here, provided under the Microsoft Permissive License.

Written by foredecker

December 5, 2010 at 5:21 pm

Posted in Coding

Advice to a Younger Man

with one comment

I ran across Ted Dziuba’s post Advice to Old Men from a Young Man.   I though I’d return the favor:

  1. Unless you are dating Scarlett Johansson, we don’t care about your girlfriend.
  2. Stay out of the left lane unless your car is faster than mine, and you are actually going faster. See #3, its likely I make way more money than you so I probably have a better/nicer/faster car; unless I spent that money on a big boat.
  3. Yes, things will always get more expensive – we make lots more money than you so it really doesn’t matter.
  4. Can do on the war stories – glad you like them.
  5. That’s good advice 🙂
  6. We don’t own you anything either – especially a job.
  7. Respect your elders – if it wasn’t for us, you wouldn’t be working on whatever you are are working on. You’d be working on what we already did.
  8. The right way to respond to advice form a more experienced man is.
    * Thanks dude
    * Thanks man
    * Cool, thanks
    * Pretty much any phrase containing the word ‘thanks’
  9. No problem. Vegas is a short flight away. First round is on me.
  10. That kind of victory can be really, really expensive. Beware the ruby lipped tonsil sucker; they are fun – for a while. Then they turn into soul leaching psychopaths. That’s advice by the way…

Written by foredecker

November 25, 2010 at 6:52 pm

Posted in Miscelaneous

Tagged with

WPF: Styling the Expander Control

with one comment

I recently needed to style a WPF expander control for a prototype project. Our team’s UX designer came up with a nice visual design.    So, I began to build my prototype and match his visual style (mocked up in Visio) in WPF.   I thought it would be easy…   it was, once I spent all morning  figuring out how to do it…

Here is screen shot of the prototype – it is pretty close to the mock up.


I started off with the Expander Control Template example on MSDN.  This wasn’t a bad start – it showed me how to change expander toggle button – nice.

But, I also needed to change the font used in the expander header.  That wasn’t shown in the example.   Ok, no problem – just use a setter in the style like this – right?

    <Style x:Key="MainViewExpander" TargetType="Expander">
        <Setter Property="FontSize" Value="18" />
        <Setter Property="FontWeight" Value="Bold" />
        <Setter Property="Template">
                <ControlTemplate TargetType="Expander">

Example1Bzzzztttt… wrong.   That set the font appearance in the Expander header like I wanted, but all the controls in the Expander content property inherited the font appearance.  That’s not what I wanted at all.

I needed to style the appearance of the Expander header and its contents separately.

So, i dug around in MSDN a little more.  The key information turned out to be in the documentation for the Headered Content Control class.

This is an important class as it defines the base functionality for controls including the Expander, Group Box and TabItem controls – all very commonly used controls.

They key to getting the look I wanted is using Data Templates.   I’ve seen this used in many MSDN examples and WPF blog posts but until now, I never really understood them.

In short, data templates are like control templates but instead of defining how WPF structures the visual tree for a control, data template defines how WPF displays data.

We’ll, you might say “Duh Richard!”  That’s what the docs say….  Ya, Duh! For sure…  I didn’t grok exactly what this meant until now: they key for me was finally understanding that the data template is bound to the data it is intended to display.

All data template intentions are bound to a property on an object instance.   You can refer to this binding by using the simple most binding which is “{Binding}”.  You can see how this is used below.

The key is that all Headered Content Controls have a data template for the header content.    So, setting the font appearance for the Expander header was a simple matter of adding this setter to my style

        <Setter Property="HeaderTemplate">

This worked great!  As you can see in the screen shot at the beginning of the post, I set the text appearance to the white, 18 size bold text I wanted.   Most importantly, the appearance of the content was not affected by the header’s appearance.

Now, in one case, I do want to determine the font appearance of all the children in an Expander’s content property.   As you can seen in the screen shot, the commands are in a larger, bold font style.

To accomplish this, I simply created a style derived from the main expander style -like this:

    <Style x:Key="MainViewExpanderCommands"
           BasedOn="{StaticResource MainViewExpander}"
        <Setter Property="FontSize" Value="20" />
        <Setter Property="FontWeight" Value="Bold" />

Then, in the MainView.xaml file, I used the derived style like this:

            Style="{StaticResource                   MainViewExpanderCommands}"
                <Label Content="Open"    Foreground="#FFB4B4A9" />
                <Label Content="Save"    Foreground="#FFB4B4A9"/>
                <Label Content="Save As" Foreground="#FFB4B4A9"/>
                <Label Content="Close"   Foreground="#FFB4B4A9"/>

This worked fine – mostly.  If you look, you will see that each of the labels has the foreground set to a grey color.   I tried to do this in the derived style, bit alas, this didn’t work because the the intervening stack panel (which is the content for the expander) does not have the foreground property, so it is not inherited.

Here is the source code download

This code builds with the release candidate version of Visual Studio 2010.   It does not need any additional components (like NUnit).

Installing and building the project is easy:   Just download and run the installer.   It will put the project on your desktop.  Note, it doesn’t really ‘install’ anything – there are no shortcuts and it doesn’t write to the registry.  You can move the sample directory wherever you would like, or just delete it when you are done.  No un-installing is needed.   The contents are licensed with the Microsoft Public License.

Credit – I’d like to thank Josh Smith for his excellent examples of using the MVVM design pattern.   All my new WPF projects are MVVM and I learned the ropes from his blog posts.  The MVVM classes in this example are inspired by Josh’s MSDN article here.   I’m still a noob with both WPF and MVVM – the learning curve is very steep, and long.  But Josh’s blog and articles have been hugely helpful (as have many others…)

Written by foredecker

March 28, 2010 at 5:48 pm

Posted in Coding

Tagged with ,