Just thought I'd explain why I'm interested in this, in case there's a better way to deal with the situation.

I want to give feedback to the user during a arrow-manipulation, and need to know whether a particular control-point on an arrow (in particular first and last) is over a particular box.

With the arrows set to snap-to-border, the getboxat(arrow-end-point) work at random, seemingly depending on rounding differences.  So simply making sure that the end-points when snapped-to are absolutely within the boundary would solve my problem.

Anyway, if I'm approaching this in the wrong way, please let me know.

Paul.

No, the snapping is working perfectly.

What I think is the problem is that the snapped-to point might be x=0.99999 on one side and x=1.99999 on the other where the edges of the item runs down at 1.0000 and 2.0000 respectively, which means that on the left side getboxat will return null, and on the right side getboxat will return the box.

This is only subjective and I may be wrong.  But it reliably does this (one side works, one side doesn't and curved edges are seemingly random.)

My first thought was that if I could set an optional parameter in getboxat in the same way as I can currently in getarrowat (it's called maxDist) it might solve the problem.

Paul.

I've emailed updated dlls to the address you have registered with us. That version adds a GetBoxAt(point, threshold) method to let you find a box at some distance from a point. Enable the SortGroupsByZ property to have group items sorted by their Z order when they are drawn.

Stoyan