This is the first post in a series of six articles discussing making additional Window Fields required and why the standard technique using Modifier does not always work.

For a field to behave as required, there are a number of different factors that must all fall into place. This article will explain the theory and what can go wrong. Links to examples with sample code will be published over the next week.

We will start by explaining how Required fields work at the Dexterity development level. In a perfect world marking a field as required should automatically make it show as required on the window AND prevent saving of the table record if the field has not been entered. As you will see, this is not always the case.

The Theory – Layout

Required Fields are fields with the Field Object Property, Required = True set in the Dexterity (or Modifier) Window Layout mode. The Required Fields are usually the key (or index) fields for a table, but might also include other fields that need to have a value because they are used by the underlying business logic.

In the screenshot below from the Vendor Maintenance (PM_Vendor_Maintenance) window, the Vendor ID and Vendor Name fields are showing as required (indicated by the bold prompt text).

For a field to show as required, Help menu >> Show Required Fields must be selected AND the User Display Preference (Microsoft Dynamics GP >> User Preferences >> Display) for the current user must have the Required Fields set to something other than Black and Regular.

Note: GP Power Tools automatically changes Required Fields from Black and Regular to Black and Bold, so that Required Fields will be visible if Show Required Fields is enabled.

The final piece if the puzzle is that the Field that has been marked as Required must be Linked to its prompt in the Dexterity (or Modifier) layout. If it is not already linked, you can use Tools menu >> Link Prompt and then use the mouse to click and drag from the field to the prompt. Having the prompt linked is vital for the ability to show the Required Field by changing the appearance of its prompt.

Note: It is also possible to programmatically make a field required using the Dexterity command Field_SetBooleanProperty(<Field>, FIELD_PROP_REQUIRED, true). You can use this command with GP Power Tools in a Window Pre trigger to make fields required without needing to use Modifier (and change Security settings). You can also use the “no code/low code” Form Control module to make a field required without using any code. Using code to make a field required means it will work on any version of the window (original, modified, alternate or modified alternate).

Without the linked prompt, the field will still be required but you will not be able to easily see that it is required. This can make for a bad user experience as the standard warning dialog does not explain which fields are required when you try to save.

Note: When a field is user defined or has a prompt that can be changed by code, the prompt for that field will be a non editable string field rather than a static text prompt. In this situation the string field cannot be linked as a Linked Prompt and so it is not possible to make the field “show” as required.

The Theory – Code

Having a field marked as required and linked to a prompt is only the first part of how Required Fields work. The next part is the code that will validate that all required fields have a value (are not empty).

It is important to understand the difference between a form and a window in the Dexterity development environment.

The windows that a user sees in Dexterity are defined on a Form. Think of the Form as a container for one or multiple Windows along with any code that is specific to those windows. Usually when there is too much data in a table record to display on a single window, additional windows will be added to the same form.

For example: The PM_Vendor_Maintenance form contains the PM_Vendor_Maintenance (Vendor Maintenance) window as well as windows for Accounts, Options, Email, Email Address and Tax Withholding (for Australia, used to be called PPS).

Knowing the difference between a form (with all its windows) and a single window will help you understand the difference in the saving code that checks if the required fields have data: Is it using the required() Dexterity function, and which windows it is checking?

if not required(window PM_Vendor_Maintenance) then
	call Warning_Dialog,2351,"","","";
	abort script;
end if;

The code snippet above will ONLY check for Required Fields on the main Vendor Maintenance window. So making a field required on the Options window (for example) will not be detected.

if not required(form PM_Vendor_Maintenance) then
	call Warning_Dialog,2351,"","","";
	abort script;
end if;

The second code snippet is better as it will check ALL windows on the entire PM_Vendor_Maintenance form for Required Fields.

if empty('Vendor ID') or empty ('Vendor Name') then
	call Warning_Dialog,2351,"","","";
	abort script;
end if;

This final code snippet is a bad implementation as it only looks at the two fields the developer set as required (Vendor ID and Vendor Name) and does not use the required() function at all. If the code is written this way, making other fields required will be ignored.

There are examples of all three methods in the Microsoft Dynamics GP code. For example:

• Customer Maintenance uses if not required(form RM_Customer_Maintenance) then
• Vendor Maintenance uses if not required(window PM_Vendor_Maintenance) then
• Vendor Address Maintenance uses if ‘Vendor ID’ <> “” and ‘Address Code’ <> “” then

This means that changing a field to required using the Modifier or GP Power Tools might not work if the underlying code in the window does not follow best practice of using the required() function against the form (meaning against all windows on the form).

The Separate Form Problem

Another situation that can occur is when the Required Field is on a related window that is actually an entirely different form. For example:

• The Sales Transaction Entry (SOP_Entry) window is on the SOP_Entry form, however, the Sales Customer Detail Entry (SOP_Customer_Detail_Entry) window is on a completely separate SOP_Customer_Detail_Entry form. So, when saving the transaction and the code checks “if not required(window SOP_Entry) then” it will not look for required fields on the Sales Customer Detail Entry window at all.

• The Purchase Order Entry (POP_PO_Entry) window is on the POP_PO_Entry form, and the Purchasing Vendor Detail Entry (POP_PO_Vendor_Detail_Entry) window is on a separate POP_PO_Vendor_Detail_Entry form. So again, when saving the transaction and the code checks “if not required(window POP_PO_Entry) then” it will not look for required fields on the Purchasing Vendor Detail Entry window.

In these situations, where the required field is on a sub window that is actually a separate form and that window may not even be opened before trying to save, marking a field as Required will never work automatically.

The Solutions

Depending on the windows you wish to add Required Fields to, the solution used could be different and it may or may not work automatically.

• If the field is on the main window of the form, it will probably work straight away as windows that don’t at the required() function on the main window are rare.

• Making a field required on a sub window (same form) will sometimes work when the required() function has been used on the entire form. It will also not give you a hint that the sub form needs to be opened to see the required field.

• Making a field required on a sub window (separate form) will never work as the sub window will not be checked.

To make required fields work where it fails to work automatically, we can use GP Power Tools – Developer Tools module to create some triggers to perform the extra checks needed, display a dialog, and even open the sub window and place the focus on the field that needs to be entered.

Next week, I will post the following free samples that can be used as they are, or used as a basis to help you develop your own code. The articles will be available after the dates shown:

• 18-Aug-2025:  #GPPT Making Tax Registration Number on Customer Maintenance Options Required
  Sub window on same form, save using ‘Save Record’ field change script

• 19-Aug-2025: #GPPT Making Tax Registration Number on Vendor Maintenance Options Required
  Sub window on same form, save using Save() form level function

• 20-Aug-2025: #GPPT Making Substitute Item 1 on Item Maintenance Options Required
  Sub window on same form, save using ‘Save Record’ field change script

• 21-Aug-2025: #GPPT Making Salesperson ID on Sales Customer Detail Entry Required
  Sub window on separate form, save using ‘Save Record’ field change script

• 22-Aug-2025: #GPPT Making Tax Registration Number on Purchasing Vendor Detail Entry Required
  Sub window on separate form, save using Save() form level function

• 05-May-2026: #GPPT Making Reason Code on Inventory Transactions Required
  Scrolling window field, showing alternative methods.

Hope you find this information and the samples helpful.

David

05-May-2026: Added new article to series.

This article was originally posted on https://www.winthropdc.com/blog.