Test Screen Name wrote:
Thanks, I had missed PDEElementIsAtPoint and can see its use in a hit tester, even though it may not always reflect what people think of as being at a point (because of clipping and transparency).
In my [admittedly recent] experience, the main problem of using PDEElementIsAtPoint() for my "copy&paste" plugin is as follows. It turns out that the PDF producers are a very unruly and undisciplined crowd, when they create Paths. See the following image:
As a user, I have tried to do the logical thing, which is to rubberband-surround the left part or the right one separately. However, they are internally part of the same Path and therefore, I always get both. But it gets much, much worse! Sometimes margins, and very remote sub-paths are part of the same path.
I gave up on the idea to use PDEElementIsAtPoint() as a discriminating function. I have a list of segments ('l' and 'c') to be pushed into the Windows Clipboard and once they are completely ready (the whole page), I am doing simple arithmetic to determine which are inside the drag rectangle.
This latter approach is frustrating because I have to do all those matrix operations on hundreds of thousands of points, when the user only needs a very small subset. Before putting them into the clipboard, I may end up discarding some 95%+ of the segments.
-Ramon