[ImageJ-devel] @parameter choice update in component callback

[Adrian Daerr]

Hi Curtis,

>> I have parameters a, b, c whose initialisation depend on a common
>> calculation (depending on the image gotten through a previous
>> @Parameter ImagePlus imp): can I do this calculation in the
>> initialiser for the first parameter a, and then in the initialisers 
>> of b and c rely on the fact that the calculation was already done ?
> 
> Perhaps simplest at the moment would be to give your command a 
> global initializer -- i.e., set the initializer method in the
> @Plugin annotation itself, rather than on specific parameters.
> The ImagePlus will be populated by a preprocessor _before_ the
> initialize method is called, so when your global initializer gets
> called you will already have access to the ImagePlus.

Thanks for the suggestion, which almost does the job, except that the 
initialization also depends on a parameter

@Parameter(persist = false) private RectangleOverlay roi;

which appears to be populated only after the initializer is called 
(its value is null in the initializer and valid in the run() method).

I am not sure how to solve this: do I have to write a Preprocessor of 
some sorts, or can the initializer 'manually' call the code which 
normally harvest the RectangleOverlay parameter later on ? Somehow the 
fact that ImagePlus is populated by a Preprocessor but 
RectangleOverlay isn't, seems linked to issues that I mentionned in 
another post[1], but even after some reading of the tutorials and the 
scijava source code around org.scijava.command.CommandInfo my 
understanding of how the plugin initialisation works is still poor.

[1]
(e.g. that the Overlay appears in the harvesting dialog, or that an 
Exception is thrown because of the overlay after command execution)
http://imagej-devel.54429.x6.nabble.com/Masking-Parameter-from-GUI-harvesting-td1098.html

> But again, scijava/scijava-common#181 is very relevant here.

Would it make sense to distinguish (by an annotation ?) parameters 
that are to be initialized from the context (i.e. services, active 
image, roi etc), and whose lack should be immediately fatal to the 
plugin (no UI harvesting, and in exchange can be assumed final for the 
rest of the command execution), from parameters that, if they cannot 
be populated from already available data, should be harvested through 
a dialog (and may change several times) ?

cheers,
Adrian