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.