Discussion:  When creating GUI edit screens, there are a number of issues to decide.  The primary mission is to input data for each of the Tic objects in a record.  There are times, however, when non-Tic related items will appear on the edit screen, so there must be some way to handle these.

I envision each input line to appear as three parts as follows:

 A label for the input.    The input (BEditable) component.    The Alternate input button.

A button was originally planned to call up extended help for each input item, however, that seemed to clutter the screen, so I decided to use a right mouse click on the input item to bring up the help dialog.  This requires adding a mouse listener to every input item, as long as it is editable.  Some items are not editable, and therefore don't need a help option.
The panel on which these input lines will appear may contain one or more "columns" of input lines.  In some cases a subpanel will be incorporated, such as the handicap panel using a Handicap object as its source of data.  These should be completely self contained.  In anticipation of future touch screens, there must be provided a mechanism to allow a HELP button, without having to rewrite all of the GUI screen code, if possible.  This is because tooltips are not available, and neither are right clicks, so HELP must come from a button.

First I'll identify the items related to each edit screen.  For an input field, these are the relevent components:

The input component will implement the BEditable interface to assure that the requisite methods for setting and getting the desired object are present.  I've created my own input components based on standard Java objects, to implement the BEditable interface.

The current list of BEditable components is:

The column and row identify where on the panel the input line will appear.

The icon filename provides the name of an icon image to appear on the alternate input button.  Not every input will have an alternate input selection.

The alternate input dialog object is the object that will be instantiated for the user to provide input using an alternate form.  This may be another component, such as a spinner, or it can be a self-contained object such as a calendar dialog.  In either case the primary input component must be updated by this component when it is exited (dialog) or an item selected (spinner).  When this component or object is given the focus it must be updated to reflect the value currently in the primary input component.

There are a number of item Strings, some of which are stored in a ResourceBundle, and retrieved when the panel is constructed.  Some of these Strings are constructed from either the Tic name, or some other name provided in some other way. None of these are used when the input component is a sub-panel.  Here are these Strings:

Requirements:  I've identified certain criteria for the edit screens to be able to perform.

Data will come from a Ticable object, but not all screen elements will pertain to a Tic.

Data must be able to be written to a Tic, if applicable.  One exception is when the input component is disabled.

The tab (focus) order must be preserved, either by the order in which input lines are entered, by indexing, column or row position, or by some other mechanism.

Blank, non-visible, components must be possible.

Each column must adjust to the minimum size needed to display the text and data.  This is because the label, and possibly other components, will have different sizes based on the locale text.

Alternate input methods must return the correct type of object, as should the primary input component.

Use a right, or center, click on the primary input component as the way to call up a help dialog for the item.  Use the tooltip text of the label for a shortened version of the help or to explain abbreviations or acronyms.

In anticipation of touch screens, have the capability to have the help called up by a button press.

The alternate input dialog object can either be a component itself, such as a spinner, or can be a button with an icon, which opens another dialog when pressed.

Each component must be able to be enabled/disabled based on the status/value in another component.  For example, "Use Handicap".

Ideally, be able to align the label and input components left or right, independently, and with only minor changes to code.  However, I prefer to still allow for I18N order of reading, left to right or right to left based on the locale.