Vogel612
commented
11 months ago IIUC what rubberduck does is literally call into the VBE to do that Debug > Compile before attempting to parse (assuming the setting is enabled). Why that would behave differently for RD instead of the VBE is beyond me.
From a quick look at the code, we seem to be using a wrapper around the VBE typelib that returns a bool compilation result when invoked with a string project name. You can actually invoke this wrapper yourself by referencing the unstable Rubberduck API exposed here:
This at least exposes the option of compiling via the same mechanism that Rubberduck uses, altough I'm not sure that helps you :/
Rubberduck version information Version 2.5.9.6296 OS: Microsoft Windows NT 10.0.22635.0, x64 Host Product: Microsoft Office x64 Host Version: 16.0.16827.20166 Host Executable: EXCEL.EXE
Description There are occasions when Debug.Compile crashes the host application (I'm looking at you Excel). The same code may or may not allow a Rubberduck parse but the host application never seems crash when the Rubberduck compile before parse option is used.
It would be a useful enhancement to have a Rubberduck compile option which could report back on the offending lines in the same manner as Debug.Compile but which avoid the Host Application crashes. to which Debug.Compile is subject.
The Debug.Compile crash happens to me a lot with my current project. Once this happens the workaround is, to switch to RubberDuck code analysis. In a few cases Rubberduck can't parse and it has been necessary to export to twinBasic to see what errors are reported there (this last step this far has worked 100%, but is not a very elegant solution as you are correcting errors in VBA and twinbasic at the same time)