Hi Kevin,
Bill has a good point that you can avoid the manual conversion of
coordinates by using a DirectManipulationRenderer with a very high
picking threshold. You would have to analyze the picked coordinates in
the CellImpl, and decide to either put the point back where it was (if
the click was too far away) or move the line to match. If you make a
single pixel visually, you wouldn't even need to force the point back to
the line's endpoint anymore.
Both ways have pros and cons. If you are working in 3D, Bill's way might
be easier, because manual picking in 3D with a ray is more work than
simple 2D picking (the methods I wrote for RadialLine only return the
ray position, not the vector, so it wouldn't work well in 3D).
-Curtis
Bill Hibbard wrote:
Hi Kevin,
Any idea whether this is more efficient than mulitple D_R_M's?
It is. Curtis's solution could of course be cast as a custom
direct manipulation DataRenderer, but it occured to me that
you could do the same thing using the existing
DirectManipulationRendererJ3D (or J2D), by setting a large
value into DisplayRenderer.setPickThreshhold(). Specifically,
you'd have just a single DirectManipulationRendererJ3D and a
single RealTuple with MathType (x, y) and ScalatMaps
x -> XAxis, y-> YAxis. BY setting a large enough value into
setPickThreshhold(), and only a single RealTuple displayed
via direct manipulation, that RealTuple would jump to whatever
location the user clicked the right mouse button on. This would
trigger a CellImpl, which would use the (x, y) values of the
RealTuple to compute the line direction, as in Curtis's code.
And you wouldn't need his code for converting screen x and y
coordinates into data x and y.
