Hi Kevin,
> For my application, I want the user to be able to rotate a line. I have
> long been using Curtis Rueden's "AnchoredPoint" method to do this,
> however, if my user zooms in, or translates the display to where the
> DataReferenceImpl/Cell is no longer visible, then they can no longer
> rotate the line (unless they reset the display). So I am trying to make
> it so the user can click anywhere on the line to rotate it.
>
> I saw that you can directly manipulate a FlatField (Test40) and was
> hoping to do that with the line. However, in Test 40, you really only
> manipulate one of the RealTuples in the FlatField (if that's the right
> way to thik about it) and the line is no longer straight.
In Test40 and in other applications of D_M_R_ to Fields,
the user changes the values of one Field sample at a time.
What you want is changes to any to cause consistent changes
to all the other, for example to maintain them in a straight
line.
> In my example, ( FlatField: (radius)->(longitude) ) I was hoping to
> obtain the longitude that was being selected and changed and set the
> rest of the range values of my FlatField to that same longitude making
> the line rotate. I first tried this with just the Dir.Manip.Rend. and
> the DisplayRenderer.getDirectAxisValue(), but it seemed to throw the
> CellImpl.doAction() method into an infinite loop.
Yeah, DisplayRenderer.getDirectAxisValue() is for internal
call by DataRenderers, calling it from an application is
probably going to cause trouble.
> I've considered two other ways to approach this:
>
> 1) Create an array of DataReferenceImpl's that do pretty much the same
> thing (redraw the radial when moved - like the AnchoredPoint method) and
> space them so that the user should (almost) always have one visible no
> matter how they manipulate (pan/zoom) the display.
This is the approach I would take. I'd use a straight line,
possibly as a Gridded2DSet, displayed with a DefaultRenderer,
and a set of RealTuples for a series of evenly spaced points
along the line, each displayed with a D_M_R_. Each RealTuple
would also have a CellImpl that would recompute the values
for the straight line and all the other RealTuples, to keep
them all consistent. The tricky bit is to avoid event loops
(i.e., one CellImpl changes the value for other RealTuples,
so their CellImpls all start changing values, ad infinitum).
The way to avoid this is to have these CellImpls record the
new values for all the RealTulpes in an array. Then when a
CellImpl is triggered, it compares the values of its
RealTuple to the value recorded in the array. If they are
equal, do nothing. Note also the CellImpls should all put
there code bodies inside:
synchronized (data_lock) {
...
}
where data_lock is just some:
private Object data_lock = new Object();
> I imagine that I can kludge something together to get the behavior I'm
> looking for, but was hoping to find a more elegant way. ;-)
I wouldn't worry about this - practical applications
usually end up somewhat particular, i.e. kludgey.
Good luck,
Bill
