By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
426,060 Members | 1,878 Online
Bytes IT Community
Submit an Article
Got Smarts?
Share your bits of IT knowledge by writing an article on Bytes.

Debugging in VBA - 3) General Tips

NeoPa
Expert Mod 15k+
P: 31,419
Table of Contents - [Debugging in VBA]
Previous Chapter - [Debugging in VBA - 2G) The Watch Pane]
-----------------------------------------------------------------------------------------------
3) General Tips.

The first and most important tip is always to work with a compiled project.

Many of the problems you're likely to come across are identified during the compile process. Compile from the VBA IDE (Integrated Development Environment) by selecting Debug | Compile {Project name}. If you ever try to run a project that won't even compile then you can expect problems. These problems are far more easily identified by a compile than when trying to run.

The next important tip is that when you are developing anything, remember to USE the debugging facilities.

Most of the facilities are only available when the code is running (although paused). While it is possible to start individual (parameterless) procedures from within the VBA editor, the usual way to get control is to put a breakpoint in the code where you want to start tracing from (See Debugging in VBA - 2A) The Code Pane (F7)) and then simply start the project in the normal way (From the Access window).

Make sure that the VBA IDE debug setting allows your code to break when an error occurs.

From the VBE screen (Alt-F11 from the main application window) select Tools / Options / General and make sure Error Trapping is set to Break on All Errors or Break in Class Module. The latter should only be necessary if you are developing any class code, but if you ever do so, finding out why it never breaks when it should can be very difficult to work out unless this is already set. The setting of Break on Unhandled Errors seems to be the default, but this can mean that any error within one or more invoked procedures, which don't themselves have any error handling, can be handled by an original, calling, procedure thereby causing the information and context associated with the actual error to be dropped completely.

Other miscellaneous tips:
  • Find out precisely where the problem occurs.
  • Display information (current contents of variables or controls etc) at various stages of the process.
  • Often overlooked - check with the Help system to make sure your use of the inbuilt functions; methods; etc is correct.
  • Shift-F2 (Definition of object) & Ctrl-Shift-F2 (Return to last position) can be extremely helpful in working out what's what and where.
May 20 '07 #1
Share this Article
Share on Google+