To debug an RE:Anywhere VBA DLL macro, log on to the RE:Anywhere Web server with administrative rights.
Then, open the code using the RE:Anywhere VBA DLL Tool, on the server that hosts RE:Anywhere. Open the
project properties screen by selecting Tools, [Project Name] Properties from the menu bar. On the Debugging tab
of that dialog, select Start browser with URL and enter the URL of the login page of RE:Anywhere (using the
host machine’s name to identify it in the URL). For example, if RE:Anywhere is hosted on a Web server named
CLIENTWEB1, the URL used on the Debugging tab should be “http://CLIENTWEB1/REWeb70/login.asp.” You
should access the Web application locally. You do not want the execution to pass through any proxy server or
firewall. Set breakpoints as necessary and select Run, Start Project from the menu bar to launch the debugger.
Debugging is interfered if you recompile a project to a new filename without changing the project name and class
name and if you do not unregister the old DLL. For example, you are working on a VBA DLL macro project named
“WebTest”, the name of your macro class is “CWebTest1,” and you compile it to C:\WebTest.dll. When you
launch the debugger, RE:Anywhere looks up the ProgID WebTest.CWebTest1 in the registry to find out that it is
stored in C:\WebTest.dll. If the project is rebuilt to C:\WebTestNew.dll without unregistering the old
C:\WebTest.dll, RE:Anywhere most likely still finds the old C:\WebTest.dll (which is still associated with the
WebTest.CWebTest1 ProgID in the registry). If your breakpoints are not being hit when debugging, this is
probably the cause.
If a bug in your VBA code results in a run-time error, a message box displays with a description of the error
identifying the VBA DLL that raised it. If the event that raised the error has a parameter allowing you to cancel the
event (for example, BeforeSave), it is not cancelled. However, code in downstream events is not executed. For
example, if a run-time error occurs in the IBBWebConstituent_BeforeSave code, any change made to the
constituent (either by the user or by the code up to the point of failure) saves to the database. However, if there is
also code in IBBWebConstituent_AfterSave, it does not execute. An exception to this is the code in
IBBWebActiveBatch_BeforePostRecord and IBBWebActiveBatch_HandleException. If there is a run-time error
in one of these two methods, their code executes up to the point where the error occurs (for as many times as there
are records or exceptions in the batch). The cancel flag in IBBWebActiveBatch_BeforePostRecord does not take
effect even if set to True before the run-time error occurs. If a run-time error occurs in either of these methods,
IBBWebActiveBatch_AfterPost does not execute.
RE:Anywhere needs to be able to read the interfaces of a VBA DLL from its file in order to access the DLL in
debug mode. This means that any time a new interface or public object is added to the project, the DLL must be
recompiled before that interface or object can be debugged.
Blackbaud strongly encourages you to write robust VBA code that handles errors correctly. Otherwise, memory
leaks could result from unreleased resources. All code examples should include proper error handling. Errors
can be reported back to the RE:Anywhere UI using the IBBVBAContext.AppendMessage method. If you have
questions, send an email to firstname.lastname@example.org or call 1-800-468-8996 for support assistance.