Binding DataGrid columns to DataContext items

The WPF DataGrid is a fantastic component. It’s flexible and can serve in a lot of different scenarios. Recently I was using the DataGrid in a project and had the need to dynamically hide certain columns via a users selection in a configuration section.

The idea is the user would check a box to hide a corresponding column represented in the DataGrid and the column would not appear.

 image image

I implemented the XAML as below, binding the columns visibility flag to the checkboxes IsChecked value with the appropriate converter. I was surprised to find that this didn’t work at all. Toggling the checkbox did nothing.


Looking in the IDE’s Output window I noticed the following binding error message:

System.Windows.Data Error: 2 : Cannot find governing FrameworkElement or FrameworkContentElement for target element. BindingExpression:Path=IsChecked; DataItem=null; target element is ‘DataGridTextColumn’ (HashCode=19699911); target property is ‘Visibility’ (type ‘Visibility’)

After some digging around, I found that the DataGrid columns aren’t actually in the Visual Tree of the window as you can see from the screenshot below.


This is the source of our error, as the DataGridTextColumn we are trying to bind to things isn’t participating in the Visual Tree.  To work around this we can implement the DataGrid’s DataContextChanged event and “forward’ the DataContext to the individual columns.

This would allow the individual columns to be able to be bound to items within the DataContext. Below is a quick and dirty implementation of how to perform this forwarding.

A more elegant way to do this would be to override the DataContextChanged property on all Datarid’s using  a metadata override.

Here’s the code behind to handle the DataContextChanged event and forward the context to the columns. Notice that I’ve also implemented a property with change notification to be used by the checkbox to store it’s “IsChecked” value so that it can be retrieved via the DataContext.


And here’s the modified XAML showing the Checkbox now bound to the new property and the DataGrid’s first column bound to the same value using the DataContext.


Because the DataGridTextColumn is not part of the visual tree I don’t believe there is any way to perform direct element bindings.

If someone figures this out, drop me a note.


Nuggets from Interviewing – Interviewer Techniques

Interviewing candidates for an open job position is hard. Period.

No matter what process or methodology you use, in the end it comes down to trying to summarize a persons skills, personality, work ethic and team fit within a relatively small allotted time. Not an easy task.

As an interviewee I’ve participated in many different interview styles that companies had ranging from a brief single discussion with the hiring manager to the grueling eight hour interview with standardized testing, five one on one  interviews and a case study.

What I’ve found is that, along with most things in life, a style somewhere in between both extremes works best. Keeping in mind the damage hiring the “wrong” person can cause – lower productivity, morale problems, inter-team social issues, etc – we can immediately see that any extra effort needed upfront to setup a process that works will yield greater results in finding the “right people” and pay us back in the long run.

The Interview Process

There are many ingredients you can choose from when thinking about what to include in your interview process. The list below contains some of the techniques I use in interviews I participate in as well as some that others might be familiar with.

  • One on one interview

A individual discussion between the candidate and a key team member. To be most effective this should be someone at least technical enough to distinguish between someone who knows the technology or area being discussed and someone who is good at talking around an area.

My opinion is that the interview must be with at least one individual that would be considered a “peer” or have a close working relationship with whoever is hired into the position.


  – Lower stress than a group interview

  – Can get multiple reads on the same areas from a candidate


  – Time can be a factor if there are several individuals on the team you want the candidate 
    to speak with

  – Need to reconcile each interviewers perception of the candidate. More difficult when
    there are discrepancies in perceptions of the candidate.

  • Group interview

The group interview is one of those techniques that if done correctly works well and if not done correctly is a complete disaster. The idea is to have several key team members in the interview at once all taking turns interacting with and asking the candidate questions.


  – Allows multiple team members to evaluate the same answers given by the candidate

  – Can leverage the experience and specialties of many individuals

  – Allows those not currently interacting with the candidate to focus more on the responses
    from the candidate

  – Less chance of difficult reconciliations since all interviewers hear the same response to


  – Higher stress environment for the candidate

  – Can feel like a “firing squad” or inquisition if not done right

  • Standardized testing

Standardized testing usually takes the form of a non-technical assessment of a candidate usually focusing in on behavioral, reasoning and logic questions.


  – Easy to compare results across candidates

  – Useful if your team believes there is a direct correlation between the success in the job
    position and the generalized knowledge being tested


  – Some people aren’t good at taking tests, especially under pressure. May result in loss of
    qualified candidates

  • Written or Verbal technical assessments

Written or verbal quizzes on the applicable technology areas your team uses. Can cover a range of topics and skills levels from basic knowledge to advanced concepts.

This should not devolve into a syntax assessment, as most programmers rely heavily on documentation, Intellisense and reference material for syntax, although the more familiar with the syntax a candidate is, the likelier they are to have been using the technology more recently and frequently.


  – Easy to determine whether the candidate has used the technology and has a firm
    understanding of the underpinnings


  – None

  • Reviewing of code

The intent of having the candidate read code is to determine a few things:

      – Do they understand the programming language being used.

      – Can they understand someone else’s code. A good portion of your product is
        likely written already. If the candidate can’t read and understand this existing code
        that may be a problem. Most companies can ill-afford the employee who needs to
        rewrite / refactor every area they work in so that they can properly understand it.

      – Can they intelligently talk about a piece of code and what some of the characteristics
        of it are – Usage patterns, good things, things to be improved, etc.


  – Good read on the candidates ability to understand code. Something not obtained
    through verbal/written technical assessments.


  – Stressful for the candidate as they will feel pressured and “on-stage”

  • Spot the bug / Troubleshooting Exercises

This technique usually involves having the candidate review a piece of code or application that has a bug in it. This exercise can be tailored to be very light or more complex.

A light version of this would be to have the candidate review a set of short code blocks with issues or bugs in them. These could be highlight core mistakes in the understanding of a concept to a more esoteric ones. These also should not include syntax problems that would be easily picked up by a compiler as most developers tend to rely on this.

For a more complex exercise, the candidate could review the companies actual product where bugs have been introduced into the code. Since the code would need to run to be worked on by the candidate these bugs would not be syntax related.


  – You get the candidate doing exactly what you are hiring them for- working with code.

  – Provides a good insight into a candidates ability to troubleshoot, identify and correct
    code. What a concept!


  – Candidates might feel stressed having to work with code in the interview. This can
    be alleviated by leaving the room, or by interacting with the candidate as they work –.
    answering questions and guiding them (although not directly to the answer!).

  – Depending on the bug introduced and the subtleties / complexities of the scenario the
    candidate might not be able to identify this. Make sure the bug is relatively apparent, or
    better yet have multiple bugs ranging from easy to more complex.

  • Design Problems

The technique referred to here are programming design problems, not esoteric ones. Usually involves describing a hypothetical system or problem that needs to be designed by the candidate giving them just enough details to start – barely.

The exercise usually involves the candidate coding the problem on a provided computer.

The premise behind this technique is that you want to be able to gauge how well a candidate can take a set of instructions and break them down into a well designed program. The main takeaway from this technique is the thought process and decisions that the candidate makes along the way and not the final outcome.

In fact we usually don’t have the candidate finish whatever problem was chosen. Observe things like:

     – Did the candidate ask clarifying questions on the requirements/premise of the problem

     – How did the candidate approach the problem – dive right in coding, draw it out, ask

     – Did the candidate consider the appropriate tradeoffs in design – speed, performance,

Remember that the focus is not on the end result but on how the candidate approaches the problem and works through it.


  – Provides insight into how a candidate thinks about problems and design considerations

  – Can be used as a gauge of experience, familiarity with tools, language/project choices, etc


  – Pick an area that is unfamiliar to the candidate. Make sure the problem is a fairly well know
    concept so it doesn’t require and explanation aside from the intended requirements.

  – More stressful than direct interview discussions since the candidate will feel like they are
    “on-stage”. Be sure to explain the intent of the exercise is to see their approach to the

  • “Try before you buy”

Pairing the candidate up with a team member for a time period on a current project and let them code together. This appears to be more applicable when the team is following an Agile methodology.


  – Useful to see the candidate in action. Coding style, thought processes, etc.

  – Able to get a rough gauge on team fit, personality.


  – Time. This requires a long time commitment by the candidate

  – May not work well with a candidate that is not familiar with the Agile methodology. Most
    non Agile shops don’t have programmers pairing together.

  – May be difficult for candidate to participate and demonstrate anything useful due to lack
    of knowledge of the feature, code, etc.


In the end what you choose to be a part of your process must be based on what works for your team and business culture and the amount of time you can invest in each interview.

Some of the techniques I find the most useful in interviews I participate in are the “hands-on” techniques. If I am hiring for a developer, then I want someone who can read and write code. If I’m in the interview, you will need to convince me you can code.

Let me hear from you if there are techniques you find work better than others for your team, or if you have any ones I haven’t listed here.

Related: Nuggets from Interviewing – Tips for Developers and just about everyone