JMRI® is...
DecoderPro®
Advanced
Applications
By the community of JMRI.org:
Tools
JMRI tools for working with your layout:
Layout Automation
Use JMRI to automate parts of your layout and operations:
Supported hardware
JMRI supports a wide range of devices, DCC systems, command stations, networks, and protocols.
JMRI Setup and Installation
JMRI environments...

JMRI Help:

Contents Index
Glossary FAQ

Donate to JMRI.org

JMRI: DecoderPro User Guide

Create a Custom Programmer

How do I create my own custom programmer?

The answer starts with the creation of an xml file in the "programmers" subdirectory of the JMRI distribution. The contents of the file are described here.

After some initial parts (which you can just copy from an existing file), the rest of the file is a series of "pane" definition elements. Each one become a pane in the DecoderPro window.

The panes in the programmer file appear when you select that programmer in DecoderPro. Note that panes can also be defined in the decoder definition, in which case those panes appear after the ones in the programmer definitions.

Specifying items to display

The basic element of a programmer pane is a "display". This tells the programmer to present a single variable. The attributes are:

  • name - (Required) This is the "standard name" of the variable to be presented.
  • label - If present, this will be used to label the variable on the pane instead of the name or standard name of the variable.
  • layout - Where to locate the label with respect to the editable field, e.g. the text box. Possible values are "left", "above", "below", "right" with a default of "right".
  • viewOnly - Present the variable but do not allow the user to change its value in this place. Possible values are "yes" or "no", with a default of "no".
  • format -

    How the variable should be presented. Numeric variables can be presented as

    • an editable text field, which is the default if nothing is specified
    • hslider - a horizontal slider
    • vslider - a vertical slider

    Enum variables can be presented as

    • a selection box, which is the default if nothing is specified
    • radiobuttons - Each possible value is presented as an individual button
    • checkbox - An enum with only two states can also be presented as a checkbox
    • offradiobutton - A single button that sets the 0 choice for the variable when selected
    • onradiobutton - A single button that sets the 1 choice for the variable when selected

    These last two can be useful for indicating which parts of a configuration are active; see the "Speed Table" pane of Comprehensive.xml for an example.

  • tooltip - Allows you to specify a default tooltip to be presented when the cursor is left over the variable. This tooltip will be overridden by any tooltip defined in the decoder file. (Note: This behaviour differs from the behaviour of the label attribute.)

Which name to display is controlled by the pane's 'nameFmt' attribute, and the 'label' attribute on each display element (variable).

The choices are:

  • If a label is specified, it will be used. Use a label if you want absolute control over what a variable should be called, regardless of what the decoder file calls it, and you don't like the standard name.
  • The pane's nameFmt attribute is "item", in which case the item name will be used regardless of what the decoder file calls the variable. Use this is you want a uniform appearance for the pane for all decoders. But be aware that some standard names are really so generic as to be useless.
  • If the pane's nameFmt attribute is allowed to default, or contains "mfg", the decoder definition file's name will be used. This is the normal form, as it allows a manufacturer to specify in some detail what a variable defines.
Formatting

Each pane of the programmer consists of (nested) rows and/or columns. Columns lay out variables from top to bottom. Rows lay out variables from left to right. You can nest these to achieve various effects; for an example of this, see the "Speed Table" pane of the Comprehensive.xml file. It has two columns; the left of each uses a row to put some sliders from left to right.

Special Elements
There are a number of elements you can use to get the programmer formatted exactly the way you want:
  • grid - Create a grid for laying out elements in aligned rows and columns. See the Grid Layout section below.
  • label - Add text to a pane.
  • soundlabel - Add a soundlabel (from the decoder definition file) to a pane. It has a one attribute:
    • num - (Required) This is the number of the sound label to be presented.
  • separator - Add a separator line to a pane. If included in a column, this will be a horizontal separator line. If included in a row, it will be a vertical line.
  • cvtable - Insert a table of CV values onto the pane. To get the spacing right you should probably not combine this with other variables on the same pane.
  • fnmapping - Show a function mapping grid. This requires variables with specific names, which are described on a separate page.
  • dccaddress - Show a combined variable for the DCC address. This consists of a checkbox that selects use of short vs long address, and a single text field for entering the address. Depending on how the checkbox is set, the text field will configure the CV1 short address or the CV17/18 long address.
Formatting with the Grid Layout
The "row" and "column" elements allow you to align elements in rows or columns, but if you have multiple columns within a row element (or vice versa) it is not possible to ensure that rows in adjacent columns (or vice versa) stay aligned.
The Grid Layout allows you to align elements in rows and columns, maintaining alignment even if a particular element is absent. There are two elements:
  • grid - Create a grid layout (within a "row" or "column" element):
    • It may have one or more optional attributes.
    • The only allowed sub-element is "griditem" and there must be at least one of these.
  • griditem - Create a grid item (within a "grid" element):
    • It should have "gridx" and "gridy" attributes.
    • It may also have one or more optional attributes.
    • It must contain one or more elements, which can be any combination of any of the other elements listed above, including "row", "column", or even another "grid".

The "gridx" and "gridy" attributes of a grid item specify the location of that item within the grid. A value of gridx="0" puts the item in the leftmost column. A value of gridy="0" puts the item in the topmost row. Other attributes to control the format of the grid items are available and are documented in the Java® GridBagLayout Tutorial.

  • Attributes of "grid" apply to all items in the table.
  • Attributes of "griditem" apply to only that item and override any equivalent attribute of "grid".
  • Both numeric and named constant values (as specified by the documentation) can be used.
  • Two extra named constant values are available for "gridx" and "gridy":
    • "CURRENT" is the value from the last added "griditem" (i.e. the same row or column).
    • "NEXT" is one more than the value from the last added "griditem" (i.e. the next row or column).
      ("NEXT" is actually a synonym for "RELATIVE".)
  • The "insets" attribute is specified as insets="top,left,bottom,right" where "top" etc. are integers.
  • A "griditem" can span more than one grid cell. Attributes "gridwidth" and "gridheight" control this.
  • By default grid items clump together in the centre of a container. Attribute "weightx" can override this and left/right justify.
  • It is possible in some circumstances to omit either or both of "gridx" and "gridy" from a "griditem" and specify a default value in "grid". See xml/decoders/esu/v4fnOutPane.xml for an example of this usage to generate a simple single-column right-aligned grid. (However if you are not careful with use of this technique and/or the "RELATIVE" constant, results can be bizarre.)
  • Unfortunately "ipadx", "ipady" and "insets" allocate space even if the enclosed display variable(s) fail qualification. A workaround is to qualify the whole "griditem" enclosing the variable (if that is appropriate to the situation).

For an example of Grid Layout use (with some explanations of attributes used), see xml/decoders/esu/v4soundPane.xml. The LokSound Select (and V4) definitions use this file.

Installing your new programmer

All of the .xml files in the "programmers" subdirectory will appear in the selection box when you create a new programmer in DecoderPro. To use your new file, just put it in the "programmers" subdirectory of the "prefs" directory and select it. You don't have to restart the program, as the list is remade each time you open a new programmer window.

How variables in a decoder file match up with the programmer file

Each decoder file defines variables that describe specific controls within the decoder. The programmer file then describes how to place those on panes so that the user can find and manipulate them.

Each "display" element in the programmer file defines one thing to show. But which one? That's controlled by the "name" attribute of the "display" element. DecoderPro takes that "name" and looks through the decoder definition for a "variable" element that has either the same "item" or "label" attribute.

This has some nice effects:

  1. The "name" in the "display" element is effectively a "standard name", that can be used in decoder definition files from different manufacturers. Since this is separate from the "label" on the decoder variable, it's possible to have a generic programmer file that works for many types of different decoders, while still displaying specific variable names. For more on this, please see above.
  2. It lets you use very generic names to control where somewhat different things go. For example, different sound decoders provide different controls. One might have "Airpump", while another doesn't have that at all, and instead has "Brake Squeal". We don't want to have the programmer files contain zillions of "display" elements to handle every possible option. Instead, we use elements with more generic names, like "Sound Option 1", for the display name.

    The decoder definition then has a "label" of "Airpump" or whatever, and an "item" of "Sound Option 1". Everything matches up properly, and "Airpump" appears on the computer's screen.