In DP4 dialogs users can navigate between fields using the cursor keys. However the navigation is not based on the physical layout of the map. Cursor movement is interpreted using the numbers assigned to the fields. Each map is considered to be divided into rows and columns, and the field numbers are assumed to imply the row and colunn number. For instance, if your map has 2 rows and 3 columns, then fields 1,2 and 3 are on the first row, and fields 4,5, and 6 on the second. If the cursor is in field 2, and the user presses cursor down, DP4 will attempt to move to field 5.
It is not actually that difficult to number a map in rows and columns properly. You simply divide the map (or a sketch of it - it is probably a good plan to do this before you actually set up the map) roughly into rows and columns so that no more than one field appears in each box (you may need to use a little poetic licence if your fields don't line up neatly). It is OK if a particularly big field occupies several boxes in your grid. Number the fields according to the box in which they appear. In detail:
When dividing the map into a grid you may ignore static controls that are headings for a following edit control. These two controls normally share a field number. You can also ignore all controls that will be given field number 0 (static controls that won't be associated with a field number, VCR controls, lines, and so on)
You do not have to divide radio buttons that are in a group. These will all have the same field number. In any case, inside radio buttons navigation does not work in the same way as for other fields.
If your map contains controls that need field numbers but are never used for input, for example hooks or output only edit controls, these should also be ignored when creating the grid. Assign them field numbers that are beyond the value rows*columns, so that the DP4 terminal manager knows they can be ignored when the user is navigating round a dialog. If you assign numbers in the range of the navigable controls your data entry routines will get called for these field numbers. This should be harmless (your code should drop through to the default case and omit the field), but it does impact performance slightly.
Number the boxes in the grid, starting from 1, according to their position in the grid, from left to right, top to bottom. If there is a field in a box its field number should be the number of the box, If a field is in more than one box assign the lowest (top left) number. It does not matter if there are gaps in the field number sequence. Here is an example:
|
1 |
2 |
3 |
|
4 |
5 |
6 |
|
7 |
8 |
9 |
|
10 |
||
This means the natural sequence or Tab Order of the fields is also left to right,top to bottom. If you want the Tab Order to go through columns then set the "Column major" property and number the fields top to bottom, right to left. The example above would now look like this:
|
1 |
5 |
9 |
|
2 |
6 |
10 |
|
3 |
7 |
11 |
|
4 |
||
It is even possible to number fields so that you do something like the top half of the first column, then the top half of the second, then the second half of the first column, and then finally the bottom half of the second. The trick there is to mentally cut your map in half and to move the lower half so that the two half maps form two diagonally opposite quarters of a larger grid. You then number the enlarged grid in the same way as previously described. Many maps on the system database are numbered like this.
If this all seems more trouble than its worth, you can simply number the fields sequentially, and say they are all in one column and set the number of rows to the last field number (or the other way round - it makes no difference). In this case the user will still be able to use the cursor keys to move round the map, but the left and up arrow keys will work the same, as will the down and right arrow keys.