Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ruberduck: compile only option #6167

Open
FullValueRider opened this issue Oct 17, 2023 · 1 comment
Open

Ruberduck: compile only option #6167

FullValueRider opened this issue Oct 17, 2023 · 1 comment
Labels
enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope.

Comments

@FullValueRider
Copy link

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)

@FullValueRider FullValueRider added the bug Identifies work items for known bugs label Oct 17, 2023
@Vogel612
Copy link
Member

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:

/// <summary>
/// FOR DEBUGGING/DEVELOPMENT PURPOSES, ALLOW ACCESS TO SOME VBETypeLibsAPI FEATURES FROM VBA
/// </summary>
/// <remarks>
/// VBA Usage example:
/// With Application.VBE.Addins("Rubberduck.Extension").Object
/// .ExecuteCode("ProjectName", "ModuleName", "ProcedureName")
/// End With
/// </remarks>
[
ComVisible(true),
Guid(RubberduckGuid.DebugAddinObjectInterfaceGuid),
InterfaceType(ComInterfaceType.InterfaceIsDual),
EditorBrowsable(EditorBrowsableState.Always)
]
public interface IVBETypeLibsAPI_Object
{
[DispId(1)]
bool CompileProject(string projectName);

This at least exposes the option of compiling via the same mechanism that Rubberduck uses, altough I'm not sure that helps you :/

@Vogel612 Vogel612 added enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope. and removed bug Identifies work items for known bugs labels Dec 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Feature requests, or enhancements to existing features. Ideas. Anything within the project's scope.
Projects
None yet
Development

No branches or pull requests

2 participants