always pendding, not ready

[bagwechien]

Rubberduck version information
Version 2.5.9.6316
OS: Microsoft Windows NT 10.0.19045.0, x64
Host Product: SolidWorks x64
Host Version: 25.5.0.0083
Host Executable: SLDWORKS.EXE

excel 2007 have same problem
Version 2.5.9.6316
OS: Microsoft Windows NT 6.2.9200.0, x64
Host Product: 2007 Microsoft Office system x86
Host Version: 12.0.6425.1000
Host Executable: EXCEL.EXE

Description
When you press pendding, it will turn gray for a moment and then return to pendding instead of ready.
This situation only happens on my laptop. I have another PC at home. In addition to the different operating system, it is Win7 and SolidWorks 2017. The PC at home can use rubberduck normally. Press pendding and it will jump to ready.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'solidworks macro editor'
2. Click on 'pendding'
3. nothing happen

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Logfile

solidworks log
RubberduckLog.txt

excel log
RubberduckLog.txt

Additional context

[Vogel612]

There seems to be some issue with how we retrieve the actual command in the command bar... Could you check whether running the reparse from one of the Rubberduck-Owned toolwindows has the same issue?

[bagwechien]

There seems to be some issue with how we retrieve the actual command in the command bar... Could you check whether running the reparse from one of the Rubberduck-Owned toolwindows has the same issue?

Except for all the functions of refactor being grayed out, some other functions can be used to a certain extent.
I also found that once the pendding is pressed, the test explorer will keep spinning and won't stop.

[retailcoder]

I'll be revisiting the website content soon-ish; I'd like to document under what circumstances the refactorings are enabled, because they are context-dependent. But most of Rubberduck is disabled until there's a clean parser run, by design: refactoring off of stale tokens would inevitably break the code and be useless, and the tokens are needed in the first place to evaluate whether the command can be enabled, so there's no way around a successful parse.

That said SolidWorks has always been a more or less problematic host to extend the VBE in; it doesn't take much with COM interop to throw the entire process out the window!