Re: non-static ROIColor?

Posted by Jim Cant on May 08, 2007; 12:23am
URL: http://imagej.273.s1.nabble.com/non-static-ROIColor-tp3699554p3699557.html

If you're willing to resort to writing code, you could override Roi, give each instance a color, override the draw() method:
class ColorRoi extends Roi
{
    Color myColor = <something nice from the rainbow>
         public void draw(Graphics g)
     {
         Color foundColor = getColor();
         setColor( myColor );
         super.draw( g );
         setColor( foundColor );
     }
However, this is hard to use since there's no way (that I can see) to make the toolkit use ColorRoi instead of Roi.  I resorted to having ColorRoi _contain_  a Roi instance and then have methods that would call into that instance rather than 'super'.  You also have to know whenever ImageJ creates an Roi so you can grab it and build your own ColorInstance from it.  It's a bother but it works.  (I had to do this  because I had some extra state I had to keep with each Roi.)
    If anyone an easier way, PLEASE let me know.

jim
p.s.  Would anyone agree that this seems like a good place for a design pattern.  ImageJ could call a factory method in an RoiFactory class that would return an object implementing an Roi interface.  That way, one could pass a factory to ImageJ and it would get your very own incarnation of an Roi whenever it needed one.  ImageJ's Roi class could then be used as a 'default' which would be sublclassed by the factory.
   


<quote author='William Beaver'>
Hello all,
A question about ROIs I hope someone can shed some light on:  I'd  
like to assign colors to ROI objects.  The problem: ROIColor is a  
static attribute of the Roi class.
...snip...