When you write code using the RE7VBA tool that compiles the VBA code into a DLL to be deployed, the environment is very similar to the built in VBA environment. There is the same development environment and access to the same code. So you would think that switching between the two would not be a problem.
When you open up the environment by creating a new project there is already some code there for you. The MacroClass1 object (I usually change its name depending on what I am doing in this project but will keep it as is here) contains references to many of the top level objects. However you can also use the code wizard that will create events for you based on the top level object you select. When working within MacroClass1 you have access to the REApplication object. This is essentially the same as the REApplication object found in the build in VBA environment. There is a SessionContext property built in that you would use to initialize objects. So far so good.
If you decide to write all your code in this one module everything should work as expected. However when I create a lot of code, or code based on different concepts, I like to group the code in modules of their own and call those modules from MacroClass1.
You would think that assigning the session context to a global variable when RE starts up and first initializes the VBA code (i.e. in the CustomConnect method) that would be sufficient for all the modules in the VBA dll. Unfortunately this is not the case. Between calls the value of the session context is “lost”. Well not so much lost as more that the global variable is really not so global as we thought. It is only global for the session call.
What this means is that each time you capture an event you have to pass through session code. This is not so difficult but it is really counter intuitive when it is not required for VBA within the Raiser’s Edge environment.