How to Set the Tab Sequence

David MeegoThe following article describes the methods for setting up the tab sequence for fields in a window using Dexterity or Modifier.  It also provides methods for handling overlaid fields such as radio buttons.

Before we start setting the tab sequence we need to do a little preparation first:

  • For any field that is non editable, or should not be part of the tab sequence; change the field's Object Property TabStop to False.
    Note: Normally only actual data entry fields, Toolbar Buttons and additional navigation buttons are included in the tab sequence.  Lookup buttons, Browse buttons, Sort By drop down lists, Window and Record Note buttons, window print and window help buttons are not included in the tab sequence.

  • Decide on the required tab sequence.  The first field in the sequence should be the first data entry field in the window (which is normally the primary key or ID field).  Then all of the data entry fields should follow, moving down each column until there is a logical break and then right to the next column of fields, then back to the left side and so on.

  • For overlaid fields such as Radio Groups and Radio Buttons, move the Radio Buttons so that at least part (if not all) of the field is outside the boundary of the Radio Group.  After setting the tab sequence, the fields can be returned to their correct location.
    Note: For Radio Buttons to work correctly, the tab sequence must go first to the Radio Group and then to the Radio Buttons in the sequence you wish them to be valued, starting from 0.  It is very important not to change the tab sequence of individual Radio Buttons in a Radio Group once data has been stored as it will change the meaning of the stored data.

  • If there is an editable or adds allowed scrolling window, you can select its position in the tab sequence as though it is a field.  However, you must remember to open the scrolling window and set the tab sequence for the fields inside the scrolling window.

From the Dexterity or Modifier window layout screen, please follow the steps below to set the tab sequence for a window:

  1. From the menus, click Layout, click Set Tab Sequence.  The first field in the tab sequence will be highlighted.

  2. If this is not the correct field, double click on the correct field.

  3. Please Tab to move to the next field in the tab sequence.

  4. If this is not the correct field, double click on the correct field.

  5. Continue Steps 3 and 4 until the tab sequence returns to the first field.

  6. You can use Tab and Shift-Tab to move forwards and backwards through the tab sequence to check it.

  7. When completed, from the menus, click Layout, click Set Tab Sequence.

If you wish to test the tab sequence, from the menus click Layout and then click Preview or press Ctrl-5.  Close the preview window when you have finished. The preview window does not run any scripts, but is a good way to double check the tab sequence.

It is important to note that if you do not press tab as you set the tab sequence and just double click on the fields, you will end up creating a tab sequence which is the exact reverse of what is desired.

For more information consult the Dexterity or Modifier & VBA manuals and training materials.

This information is now available in the following Knowledge Base (KB) Article:

How to set the tab sequence in Dexterity or in Modifier in Microsoft Dynamics GP (KB 961565) Secure Link


10-Feb-2009: Added link to KB 961565.

Comments (7)

  1. Vaidy says:


    This is quite often an overlooked aspect by the developers. It’s imperative that we set the Tab Sequence for the forms we design. Thanks for this article, this would give everyone a thought of setting Tab Sequence.

    I have a pretty important doubt: When we set the tab sequences for Radio Group & Buttons, only the first time it takes the tab sequence. The next time, when I reset it, all the Radio Buttons get detached from the Radio Group. This is particularly annoying, as the only way out is to delete the controls and re-add it. I am not sure whether this is happening on v10.0, but this was the case till v9.0.

    Is there any reason for this behavior, a workaround of sorts?



  2. David Musgrave says:

    Hi Vaidy

    Setting the tab sequence Radio Groups and Radio Buttons works fine for all versions.

    You must move the Radio Buttons outside the Radio Group so you can select them independently of the group.

    Then just make sure that the Radio Group is just prior to the Radio Buttons in order in the tab sequence.

    Add any new Radio Buttons into the tab sequence just after the original Radio Buttons.  Never change the order of the original Radio Buttons as this will change the meaning of the integer Radio Group data stored in the table or referred to by code.

    You should never need to delete them and re-add them as this would lose properties and links and scripts and reset them at the end of the tab sequence.


  3. Wally Dodds says:

    I'm at a customer site where we are running GP2010.  We've modified the Employee Maintenance window and have vb code on the window.  We went ahead and set the tab sequence on the window on a development server and then exported that package file and imported it onto a test server and then eventually onto a production server.

    Each of these different environments is accessed via a windows 2008 terminal server.  The user who did the screen modifications and imported them onto the other environments has everything working great.  However everyone else has the old tab sequence (we can see the modified form and the vba code works on the window).  We only have 1 alternate security role which is assiged to everyone (i.e. we all have the same security rights to the modified form).  If the developer logs in he sees the changes, if the others login we see the form in it's modified state just the tab sequence is messed up.  We are not using roaming profiles on the terminal servers.

    Any ideas on why the tab sequence works for the 1 person and no one else?


  4. David Musgrave says:

    Hi Wally

    I can't think of any simple explanation. Have you tried copying the forms.dic dictionary from a working machine?

    I think you should log a support case to see if this issue can be resolved.



Skip to main content