NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
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.
visad
archives: