Today I encountered a pretty annoying exception while playing back some coded ui tests. I had a grid control, with multiple rows. On one row, I could perform a mouse click. But on another row, I consistently got a FailedToPerformActionOnBlockedControlException. Yet nothing was blocking the row.

public void ClickRow()
{
    WinCell firstRowCell = GridControl.Row1.Cell1;
    WinCell secondRowCell = GridControl.Row2.Cell1;

    // No problem!
    Mouse.Click(secondRowCell);

    // FailedToPerformActionOnBlockedControlException!
    Mouse.Click(firstRowCell);
}

It took me a while to figure out that this was only a problem on the first row of the grid – regardless of other factors. The same code that worked on rows greater than 1 failed on row 1. Thus, what I needed was a workaround. The solution was nice and simple:

public void ClickRow()
{
    WinCell firstRowCell = GridControl.Row1.Cell1;
    WinCell secondRowCell = GridControl.Row2.Cell1;

    // No problem!
    Mouse.Click(secondRowCell);

    // Works!
    Mouse.Click(firstRowCell.BoundingRectangle.Location);
}

Since firstRowCell.BoundingRectangle.Location returns the absolute location of the control on the desktop, I can pass that value into the Mouse.Click() overload that only takes a single Point parameter. That overload performs a click at the specified screen coordinate, as opposed to a position relative to a specific control. I still don’t understand why I was getting that exception to begin with, but I’m becoming increasingly convinced that coded ui testing is just inherently quirky.