Hi Barry,
I agree with Jon in using the export and re-import as an effective measure to cure some of the normally hidden Microsoft VBA project inconsistencies that can and will develop over time when a code project changes related to specific component ID (version , location, and registration specific attributes), operating systems, bitness, project location changes and registration issues, etc. that do occur and affect projects over time.
The sanity checks I perform are as follows:
- Option Explicit
- Enable "Require Variable Declaration" (Editor Tab) in every unique Microsoft VBA application environment you use for development
- Manually add Option Explicit to Every source code: Module, Class, and Form for any project that does not have it
- Examine Tools > References list for any references having MISSING in the list.
- Export and re-import all VBA project source code files. This helps ensure any point-in-time version specific component IDs will be updated to your development current standards (to be deployed to client runtime environments)
- Compile your VBA Project. Debug > Compile <ProjectName>. Helps to catch hard to detect sometimes subtle coding errors issues that arise
- Ensure appropriate VBA "Error Trapping" (General Tab) options used.
- Object debugging, enable: "Break in Class Module", can be effective at times.
- Add Class Initialize and Terminate handlers to confirm proper object creation and terminate events are being triggered
- Add break points and/or trace level logging to understand the system (event and object construct/deconstruct order sequences, function call flows, etc.)
- If you have a need to consistently break for a condition that you need to resume debugging between sessions, or is a critical situation you need to debug in a user's environment, use the "Stop" keyword to immediately break into the debugger for your specific interest.
Using and applying the steps defined above are an effective strategy to ensuring a clean source code project th
HTH,
Bob
