We will implement the following version of the HitTest function in a future release:

https://msdn.microsoft.com/en-us/library/ms608753(v=vs.110).aspx

Meanwhile, if you are interested, I can show you a tricky (and inefficient) way to simulate that behavior using the available HitTest(visual, point) function.

Yes, I would like to know about it. Big thanks.

Here you are:

public enum HitTestResultBehavior

{

// Continue hit testing against the next visual in the visual tree hierarchy.

Continue,

// Stop any further hit testing and return from the callback.

Stop

}

public delegate HitTestResultBehavior HitTestResultCallback(HitTestResult result);
public static class VisualTreeHelperExtension

{

public static void HitTest(Visual reference, Point point,

HitTestResultCallback resultCallback)

{

List<KeyValuePair<UIElement, bool>> visible =

new List<KeyValuePair<UIElement,bool>>();
    HitTestResult hit;
    Visual lastHit = null;
    do
    {
        hit = VisualTreeHelper.HitTest(reference, point);

        if (hit.visualHit != null &&
            resultCallback(hit) == HitTestResultBehavior.Continue)
        {
            lastHit = hit.visualHit;

            // Make this child invisible for HitTest, so other elements can be hit
            UIElement e = lastHit as UIElement;
            if (e != null)
            {
                visible.Add(new KeyValuePair<UIElement, bool>(e, e.IsHitTestVisible));
                e.IsHitTestVisible = false;
            }
        }
        else
        {
            lastHit = null;
        }
    }
    while (lastHit != null);

    // restore IsHitTestVisible
    foreach (var item in visible)
    {
        item.Key.IsHitTestVisible = item.Value;
    }
}
}

+1 for this fix. We do all kinds of workarounds to keep code efficient and working as expected (hardcoded naming for grids, using custom bounds to determine hit test, tagging elements in XAML.)