I'm a developer for the Micro-Manager project, which builds extensively on
ImageJ. Recently I started an effort to refactor much of our
display/control logic. As part of this, I replaced the default
ScrollbarWithLabels in our descendant of StackWindow (the cSelector,
tSelector, and zSelector objects) with our own custom controls.
Unfortunately, this breaks the "Orthogonal Views" command, because it
expects the components in the StackWindow to come in a specific order:
Component[] c = win.getComponents();
((ScrollbarWithLabel) c[1]).addAdjustmentListener (this);
(There is similar code later to call removeAdjustmentListener)
I believe it's doing this so it can repaint when the channel is changed.
Naturally this code breaks when it tries to cast our AxisScroller class
(which is now the 2nd component in the array returned by getComponents())
to a ScrollbarWithLabel. I've tried to work around the problem by
overriding our getComponents() function to give this code what it expects,
but this causes the window layout code to break horribly -- as should
probably be expected.
Ideally there would be a better-supported way to access the selectors so
this code doesn't need to do this (though there's some question as to
whether outside code should have direct access to the selectors to begin
with). I generated a patch that adds a "getCSelector()" function to
StackWindow to expose the component that the Orthogonal Views plugin
requires; it seems to work:
http://pastebin.com/1xwmeU01It would be very helpful if this change or a similar one, removing
Orthogonal View's reliance on component ordering in the StackWindow, could
get adopted into the official codebase. Thanks!
If there's some other place where I should send this request, please let me
know.
-Chris
--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html
Locked
