Debugging Code in a Module - MS Access

To demonstrate how code is debugged, we will use a routine that splits a person’s name from a combined field in the frmContacts form into separate first name and surname.

Figure shows the Contact Name in the first record split into the FirstName and Surname fields.

Using VBA code, the contact’s full name, which is contained in the Contact Name field, is split into corresponding FirstName and Surname fields.

Using VBA code, the contact’s full name, which is contained in the Contact Name field,

Return now to the opening frmVBAStartsHere form, and then press the button labeled Break Apart The Contact Name Into First Name And Surname, as shown in Figure.

Click the Break Apart The Contact Name Into First Name And Surname button on the frmVBAStartsHere form to trace through and debug the application code for splitting apart the Contact Name field.

Click the Break Apart The Contact Name Into First Name And Surname button on the frmVBAStartsHere form to trace

The code will pause at a Stop statement, as depicted in Figure.

Hardcoded (permanent) breakpoints using the Stop keyword are a useful reminder when developing code that it is incomplete, but they should not be included in any final application.

Hardcoded (permanent) breakpoints using the Stop keyword are a useful reminder when developing code

Notice in above Figure that the code has stopped in the modUtilities module, and not in the form’s class module.

Figure presents the code behind the button. This code calls the procedure Process-Names in the module modUtilities.

The code behind the button is written in the Click() event. This code calls the ProcessNames routine, which is has been written in a module.

The code behind the button is written in the Click() event.

In Chapter, you will learn about naming conventions. The convention adopted in this book is to add a prefix to procedures in modules so that we can easily see in which module a procedure is defined. In the preceding example, if you had called the modUtilities _ ProcessNames procedure rather than ProcessNames, it would be easier to see how the code on the form linked to the code in the module (in this case, we have not followed the convention to illustrate the point).

There is another feature in the VBA Editor that can help display how the modules have been linked together. Selecting the Call Stack from the View menu displays the path from the forms class module to the procedure in the utilities module.

Figure illustrates that this procedure was called from a form (indicated by the “Form _” prefix) with the name frm- VBAStartsHere, from the control called cmdBreakApart on the Click event for the control.

The Call Stack is a visual aid that helps to establish where you are in the code. In this example, reading from top to bottom, you are in the code unit modUtilites_ProcessNames, which was called from the code unit cmdBreakApart_Click, which is in the form frmVBAStartsHere.

The Call Stack is a visual aid that helps to establish where you are in the code

Code in a form or report class module can call code in a module. The module can contain code that is used in several parts of the application.

Code in a form or report class module can call code in a module

Debug Commands

Debugging code involves several operations. These operations are:

  • Stopping or breakpointing the code so that it pauses at the correct point for investigation.
  • Examining and monitoring variables.
  • Modifying and repeating the code execution.

Debug.Print is a command that displays values of program variables or expressions in the Immediate window when developing code:

There is another debug command called Debug.Assert, which can be used to halt the execution of program code when a specific condition is False. For example, the following code halts execution when lngCount = 5 (note that the Debug.Assert stops when the condition is false):


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

MS Access Topics