TextField in Fiji

[AJBell]

Hi all

I've started using Fiji recently for plugin development and ran into a problem when updating a plugin that works fine in ImageJ.

The bit which seems to be the problem are a couple of TextFields in a plugin frame. They can be constructed, but the error appears why I try to add them to a panel or the frame directly, i.e.

TextField tf = new TextField();
add(tf);

or

TextField tf = new TextField();
panel.add(tf);

Both of which fail, but only in Fiji, not ImageJ. Has anyone come across this before and know of a solution?

Andrew

[dscho]

Hi Andrew,

On Wed, 9 Oct 2013, AJBell wrote:

> I've started using Fiji recently for plugin development and ran into a
> problem when updating a plugin that works fine in ImageJ.
>
> The bit which seems to be the problem are a couple of TextFields in a
> plugin frame. They can be constructed, but the error appears why I try
> to add them to a panel or the frame directly, i.e.
>
> TextField tf = new TextField();
> add(tf);
>
> or
>
> TextField tf = new TextField();
> panel.add(tf);
>
> Both of which fail, but only in Fiji, not ImageJ. Has anyone come across
> this before and know of a solution?

It would be helpful to know how they fail, i.e. what the error messages
are. Remember, things usually succeed in only one way, but they can fail
in million ways.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[AJBell]

Hi Johannes,

This code:

import ij.*;
import ij.process.*;
import ij.gui.*;
import java.awt.*;
import ij.plugin.frame.*;

public class Plugin_Frame extends PlugInFrame {

        public Plugin_Frame() {
                super("Plugin_Frame");
                TextField tf = new TextField();
                add(tf);
                pack();
                GUI.center(this);
                setVisible(true);
        }

}

produces the following error

   File....\Plugin_Frame.java:12: cannot find symbol
   symbol  : method add(TextField)
   location: class Plugin_Frame
                add(tf);

But only in Fiji - it works fine with ImageJ.

Andrew

Johannes Schindelin wrote

Hi Andrew,

On Wed, 9 Oct 2013, AJBell wrote:

> I've started using Fiji recently for plugin development and ran into a
> problem when updating a plugin that works fine in ImageJ.
>
> The bit which seems to be the problem are a couple of TextFields in a
> plugin frame. They can be constructed, but the error appears why I try
> to add them to a panel or the frame directly, i.e.
>
> TextField tf = new TextField();
> add(tf);
>
> or
>
> TextField tf = new TextField();
> panel.add(tf);
>
> Both of which fail, but only in Fiji, not ImageJ. Has anyone come across
> this before and know of a solution?

It would be helpful to know how they fail, i.e. what the error messages
are. Remember, things usually succeed in only one way, but they can fail
in million ways.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Andrew,

On Wed, 9 Oct 2013, AJBell wrote:

> This code:
>
> import ij.*;
> import ij.process.*;
> import ij.gui.*;
> import java.awt.*;
> import ij.plugin.frame.*;
>
> public class Plugin_Frame extends PlugInFrame {
>
> public Plugin_Frame() {
> super("Plugin_Frame");
> TextField tf = new TextField();
> add(tf);
> pack();
> GUI.center(this);
> setVisible(true);
> }
>
> }
>
> produces the following error
>
>    File....\Plugin_Frame.java:12: cannot find symbol
>    symbol  : method add(TextField)
>    location: class Plugin_Frame
> add(tf);
>
> But only in Fiji - it works fine with ImageJ.

You encountered the perils of unprecise importing. If you start
Plugin>Utilities>Find Jar For Class and type in "TextField" you will find
that it is in Volume_Viewer.jar. If you type in "java.awt.TextField", you
will find the correct .jar instead. Since you did not import that
TextField explicitly, Java will pick the TextField class that is in the
default package.

So if you insert

        import java.awt.TextField;

*before* all of these wildcard imports, it will actually work.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Andrew,

On Wed, 9 Oct 2013, Bell, Andrew wrote:

> Thank you for the explanation.

You are welcome!

> In general, therefore, should I always be explicitly importing? The
> plugin I have written for example, makes use of many of the java.awt
> components, and although it works, is it "more right" to implicitly
> import rather than use wildcards?

Yes, you should always import the classes you use explicitly. Otherwise
your code is prone to break whenever classes are introduced into packages
which have the same name of classes in other packages.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[ctrueden]

Hi Dscho,

> Yes, you should always import the classes you use explicitly.
> Otherwise your code is prone to break whenever classes are introduced
> into packages which have the same name of classes in other packages.

A reminder that many of these specific problems (e.g., "TextField") will be
avoided in the future once my "volume-viewer-package" branch is reviewed
and merged to master:

https://github.com/fiji/fiji/commit/2ee980be3ccc22ed38ff54594ad89dc3db2b8390

Regards,
Curtis


On Wed, Oct 9, 2013 at 7:41 AM, Johannes Schindelin <
[hidden email]> wrote:

> Hi Andrew,
>
> On Wed, 9 Oct 2013, Bell, Andrew wrote:
>
> > Thank you for the explanation.
>
> You are welcome!
>
> > In general, therefore, should I always be explicitly importing? The
> > plugin I have written for example, makes use of many of the java.awt
> > components, and although it works, is it "more right" to implicitly
> > import rather than use wildcards?
>
> Yes, you should always import the classes you use explicitly. Otherwise
> your code is prone to break whenever classes are introduced into packages
> which have the same name of classes in other packages.
>
> Ciao,
> Johannes
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Curtis,

On Wed, 9 Oct 2013, Curtis Rueden wrote:

> > Yes, you should always import the classes you use explicitly.
> > Otherwise your code is prone to break whenever classes are introduced
> > into packages which have the same name of classes in other packages.
>
> A reminder that many of these specific problems (e.g., "TextField") will
> be avoided in the future once my "volume-viewer-package" branch is
> reviewed and merged to master:
>
> https://github.com/fiji/fiji/commit/2ee980be3ccc22ed38ff54594ad89dc3db2b8390

Thanks for the reminder! I just integrated this change.

Thank you!
Dscho

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[Yuekan Jiao-2]

Hi Curtis,

One addition to the "TextField" error with Fiji, to draw a line I have to
explicitly import "Line", i.e. "import ij.gui.Line", hope the merging will
resolve it too.

Yuekan


On Wed, Oct 9, 2013 at 10:31 AM, Johannes Schindelin <
[hidden email]> wrote:

> Hi Curtis,
>
> On Wed, 9 Oct 2013, Curtis Rueden wrote:
>
> > > Yes, you should always import the classes you use explicitly.
> > > Otherwise your code is prone to break whenever classes are introduced
> > > into packages which have the same name of classes in other packages.
> >
> > A reminder that many of these specific problems (e.g., "TextField") will
> > be avoided in the future once my "volume-viewer-package" branch is
> > reviewed and merged to master:
> >
> >
> https://github.com/fiji/fiji/commit/2ee980be3ccc22ed38ff54594ad89dc3db2b8390
>
> Thanks for the reminder! I just integrated this change.
>
> Thank you!
> Dscho
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[dscho]

Hi Yuekan,

On Wed, 9 Oct 2013, Yuekan Jiao wrote:

> One addition to the "TextField" error with Fiji, to draw a line I have to
> explicitly import "Line", i.e. "import ij.gui.Line", hope the merging will
> resolve it too.

You can check easily yourself: Just call Plugins>Utilities>Find Jar For
Class and type in "Line". If the Log shows Volume_Viewer, then the merge
fixed it.

Ciao,
Johannes

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html