These are chat archives for fiji/fiji

8th
Dec 2015
Richard Domander
@rimadoma
Dec 08 2015 14:42
@ctrueden Yes, I'd like to show an error message to the user, and then stop the plugin
The error message part I've already got handled in the initializer method
Now I'd just need to know, how to prevent the dialog from showing.
In my opinion it'd be annoying for the user to see the dialog after they've been told the plugin can't process the current image. It'd be equally annoying the other way around: the error message popping only after the user has dealt with the dialog
Curtis Rueden
@ctrueden
Dec 08 2015 14:46
@rimadoma Thanks for the clarification. There is a cancelation mechanism available, but it's been so long I forgot how to use it. I am checking now.
Curtis Rueden
@ctrueden
Dec 08 2015 15:41
@rimadoma I think the framework is not currently powerful enough to support your need here. Actually, I am amazed you are the first person to run up against this.
What you currently can do is:
1) Make any ModulePreprocessor implement Cancelable and cancel the execution for whatever reason.
2) Make your Command implement Cancelable and have it cancel the execution during run().
But you cannot cancel during initialization yet.
It would be simple to add that, though.
We just need to make InitPreprocessor react to module cancelation. I'm doing a patch now.
Curtis Rueden
@ctrueden
Dec 08 2015 15:53
@rimadoma Patch pushed. Please test. scijava/scijava-common@b71dc5c
(You can use the latest org.scijava:scijava-common:2.50.1-SNAPSHOT in a few moments after Jenkins finished deploying it.)
In case it's not clear: make sure your command extends ContextCommand and then in your initializer method write:
if (invalidImage(image)) cancel("An 8-bit image is required.");
Richard Domander
@rimadoma
Dec 08 2015 16:10
@ctrueden Thanks, I'll try it! I guess one way of circumventing that issue would be to have the initializer set the value of a boolean attribute, and then cancel the plugin at run() if it happens to be false
Curtis Rueden
@ctrueden
Dec 08 2015 16:17
@rimadoma But then the input harvester dialog would still pop in the meantime. :-(
It is intended that each preprocessor have the power to cancel the module execution. In this case, it makes total sense for it to be possible to cancel during initialization.
The reason this never came up before is because we make a strong effort in IJ2 to support all image types.
There were no ImageJ2 commands up till now that require, e.g., only 8-bit data.
Richard Domander
@rimadoma
Dec 08 2015 16:31
@ctrueden I was sort of thinking that this was the reason. Interestingly enough there are plenty of plugins in BoneJ that don't really make sense if the image is not a 8-bit binary.
Richard Domander
@rimadoma
Dec 08 2015 16:36
@ctrueden I am having trouble getting the patch to work. What exactly do I need to add to my POM?
Curtis Rueden
@ctrueden
Dec 08 2015 16:38
<properties>
    <enforcer.skip>true</enforcer.skip>
    <scijava-common.version>2.50.1-SNAPSHOT</scijava-common.version>
</properties>
Richard Domander
@rimadoma
Dec 08 2015 16:48

hmm still having problems... Here's my initializer method:

@SuppressWarnings("unused")
private void checkActiveImage() {
    if (activeImage == null) {
        return;
    }

    if (!ImageCheck.isBinary(activeImage))
    {
        System.out.println("Not binary");
        cancel(Common.NOT_BINARY_IMAGE_ERROR);
    }
}

and class declaration:

@Plugin(type = Command.class, menuPath = "Plugins>BoneJ>TriplePointAngles", headless = true)
public class TriplePointAnglesWrapperBoneJ extends ContextCommand implements Command, Cancelable

I do get "Not binary" in my console
Curtis Rueden
@ctrueden
Dec 08 2015 16:50
Firstly, you don't need to write implements Command, Cancelable—the ContextCommand layer already does.
Presumaby you wrote initializer="checkActiveImage" in the activeImage @Parameter annotation?
Or did you write it on the @Plugin? It should work either way, but I want to understand exactly what you did.
You should be able to solve this by debugging into the framework.
It would be great for you to do that, and learn more about it.
Or you can run directly from your IDE if you have a suitable main method.
Either way, I suggest setting a breakpoint here.
Richard Domander
@rimadoma
Dec 08 2015 16:58
@ctrueden Yes, I wrote the initializer="checkActiveImage" in the @Parameter annotation
I'll try debugging
Curtis Rueden
@ctrueden
Dec 08 2015 16:59
Great. So if you set that breakpoint, you should be able to see whether it's canceling, and how execution flow continues from there.
If you have any trouble setting the breakpoint in the SJC component, you could instead set it directly in your checkActiveImage method.
(Sometimes it's tricky to ensure you're operating within the right version of dependencies.)
Richard Domander
@rimadoma
Dec 08 2015 17:16
@ctrueden If I did things right, it seems that execution goes to CommandModule.isCanceled before it goes to ContextCommand.cancel. Thus cancelReason == null, and isCanceled returns false
Curtis Rueden
@ctrueden
Dec 08 2015 19:01
@rimadoma That seems odd...
Curtis Rueden
@ctrueden
Dec 08 2015 19:12
@rimadoma If you push your code to a branch and point me to it, I can take a look.