Confirmation, Warning, and Error Dialogs

Confirmation, warning, and error dialogs should conform to the following conventions:

  • All warning messages should be displayed in a message box with the title text set to "Warning". The only button should be the OK button (vbOKOnly).

  • All field validation errors should be displayed in a message box with the title text set to "Validation error". The only button should be the OK button (vbOKOnly).

  • Cross-field validation should usually be done using the onChange event for all fields involved. For example, if you want an end date to always be after a start date, then you should add an onChange event handler to both fields that checks that both fields are valid and that this condition exists; if not, you should display a message box as described above.

  • Any errors other than field validation should be displayed using the ShowErrorDlg routine. Server-side errors can be saved for display on the next page by calling SetError routine. For more information about these****routines, see ShowErrorDlg (client-side) and SetError (server-side).

  • Delete confirmation dialogs should be displayed in a message box with the title text set to "Delete?". The dialog should use Yes and No buttons (vbYesNo). Confirmation dialogs for Restore or other similar operations should be handled in the same way.

  • The file SharedStrings.asp defines a number of string constants meant for use in these types of dialogs.

  • To promote a consistent user interface for simple confirmation, warning, and error dialogs, use the ASP files dlg_confirm.asp, dlg_warn.asp, and dlg_error.asp, respectively, as the first argument to the showModalDialog routine.

    These files are located in the Include folder. See the file ActionPageUtil.asp for examples.

Properly built Edit Pages allow the Framework to handle the enable/disable state of the Save and SaveNew tasks as well as Save confirmation and warning dialogs. The following practices must be observed to obtain this behavior:

  • Use one master EditSheet HTC to contain all editing controls on the page.

  • Associate the following handlers with the master EditSheet HTC events:

    • The SetDirty method with the onChange event,

    • The SetRequired method with the onRequire event, and,

    • The SetValid method with the onValid event.

    If additional functionality is required, make sure you call one of these routines, as appropriate, in your event handler.

  • If nested EditSheet HTCs on the page use the template mechanism for freeform layout, make sure to register the IDs of any HTCs within the template in the register attribute of the template element.

  • HTML checkbox and radio button elements need special handling because they do not fire the onChange event. This means that they cannot be registered using the register attribute of the template element. For HTML checkbox and radio button elements, explicitly call the SetDirty method as the onClick handler for each element.

  • When the Edit Page is properly constructed, the Save and SaveNew buttons will not be enabled unless changes have been made to the page, all fields are valid, and no required fields are missing. Note that any special cross-field validation must be done separately.


All rights reserved.