Tuesday, October 19, 2010

Tortured Execution Path For Union By Attribute Plug-In

I've been doing some work on the Union By Attribute Plug-In. One of the first thing I tried to identify when I began working with the program was the execution path. I started by taking a look at the plug-ins execute method. In this plug-in, the execute method only displayed the dialog to collect the parameters from the user needed to peform the union operation. After that, I lost the path of execution. I knew that the union method did the main work of the plug-in, but I couldn't figure out how it got called from the execute method.

The "open call hiearchy" tool in Eclipse may have provided the answer. Here is what I believe is the execution path of the UnionByAttributePlugIn class:

(1) The TaskMonitorManager. execute method is called. It receives an instance of a ThreadedPlugIn class as an argument, which is in this case the UnionByAttributePlugIn.

(2) The TaskMonitorManager.execute method creates a TaskWrapper object. The run method of the TaskWrapper object is then called.

(3) The TaskWrapper.run method calls the UnionByAttributePlugIn.run method.

(4) The UnionByAttributePlugIn.run method calls the UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method.

(5) The UnionByAttributePlugIn.unionFeaturesWithSameAttributeValue method calls the UnionByAttributePlugIn.union method, which does the main work of the plug-in.

I still haven't figured out the direct link between the execute method and the TaskMonitorManager. I'll be working on that. It would be nice if the path of execution was a little more clear in the execute method. This is something to remember when writing your own plug-ins for OpenJUMP. Try to keep a direct link between your plug-ins execute method and the methods that do the main work of your plug-in. One way this can be achieved is by putting your code to display and collect data from a GUI in its own method that is called from execute. Here is an example:

public boolean execute(PlugInContext context)
{
this.showGUI();
boolean workDoneSuccessfully = this.doWork();
return workDoneSuccessfully;
}

I hope to write more on this blog about the TaskMonitorManager class, TaskWrapper class, and threads in OJ as I learn more about them.

The Sunburned Surveyor
Posted on 9:40 AM | Categories:

Monday, August 16, 2010

A little info on the MultiInputDialog class.

The MultiInputDialog class can be used to quockly construct dialogs for OpenJUMP plug-ins. I was taking a peak at the class as part of my work on the Union By Attribute Plug-In, which uses the class. A couple of interesting things about the class caught my eye:

(1) The MultiInputDialog class contains a public method to add a Swing ComboBox with all the layers or all the editable layers in a task/project.

(2) The MultiInputDialog class uses a LayerNameRenderer, which is an implementation of the Swing ListCellRenderer.

I hope to learn more and talk more about this class on my blog in the future.

The Sunburned Surveyor
Posted on 10:15 AM | Categories:

Tuesday, February 09, 2010

Learning From Jump Source Code: IconLoader, FeatureInstaller, and More

During some of my recent programming work on BizzJUMP I ran across some interesting things about the JUMP/OpenJUMP source code that I wanted to make note of. Perhaps some other programmers and followers of my blog will be interested in these things also.
  • JUMP has an IconLoader class. I wonder what how it loads and provides icons? Do any of its methods throw I/O exceptions? I want to take a closer look at this class and find out.

  • JUMP has a FeatureInstaller class that can be used to install plug-ins. I want to take a closer look at this class so I can see how it works.

  • As far as I can tell there is no way for a plug-in to control the location of its menu item in the pop-up menu of the layer list. I wonder what I would have to change to make this control possible. Right now, if you want a plug-in to control the location of its menu item in the pop-up menu for the layer list, its got to be part of the core.

  • The LayerNamePanel (the class behind the layer list) is actually an interface. The default implementation of this interface is the AttributeTab class. Don't ask me where they got that name.

  • The JUMPConfiguration class controls the loading of plug-ins built into the core. It must be activated during the launch of the program. I want to document this launch process and describe the role of the JUMPConfiguration class in starting the program.


The Sunburned Surveyor

Posted on 11:09 AM | Categories:

Monday, January 11, 2010

Original JUMP Resources

We recently lost the jump-project.org web site, and all of the resources that were available from that site. I was worried the same thing might happen with the JUMP web site hosted by Vivid Solutions. So I grabbed the source code and executable distributions for JUMP from that web site and put them on my SurveyOS SourceForge project page. I also put a zip file with all the PDF documents from the original JUMP there. I also put a maker web page for these resources on my Redefined Horizons web site.

Original JUMP Resources Page at the Redefined Horizons Web Site

This may be useful for programmers interested in the original JUMP source code.

The Sunburned Surveyor
Posted on 2:11 PM | Categories:

Thursday, January 07, 2010