You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, there is a known limitation that Ending code execution of a TimerProc (through the debugger + Stop button, or the End keyword) will crash Excel. This is because stopping the TimerProc from returning means WinAPI never gets a response from Excel, and there is no way of catching the Error with VBA code as End destroys everything.
Now RubberDuck uses a clever method of invoking methods in their test explorer which circumvents this issue
However this cannot be implemented directly in VBA since even if the method of invoking catches End statements, there needs to be some code to handle that caught error, and if it's VBA then it will be destroyed - https://chat.stackexchange.com/transcript/message/54875311#54875311
There are 3 solutions I can think of:
Use the RD method of invocation, but write some assembler to convert from WinAPI timer procs and whatever signature the invocation requires, and this way VBA is avoided entirely
Create an addin in C# or VB6 perhaps which does what RD does natively and is unaffected by the code termination
Write the error handling stuff in native assembler and forward the function call through that
The text was updated successfully, but these errors were encountered:
I came across this repo by mistake and I remembered I saw on your GitHub account that you have a massive repo with timers and subclassing. I am having the same issue as you in my repo but I have it with hooking the mouse. I just thought you might want to see it. The owner does assembler as you mentioned here, but in a really cool way with no need for addins or dlls. Unfortunately it's a VB6 repo.
Right now, there is a known limitation that Ending code execution of a TimerProc (through the debugger + Stop button, or the
End
keyword) will crash Excel. This is because stopping the TimerProc from returning means WinAPI never gets a response from Excel, and there is no way of catching the Error with VBA code as End destroys everything.Now RubberDuck uses a clever method of invoking methods in their test explorer which circumvents this issue
https://github.com/rubberduck-vba/Rubberduck/blob/e498d9501935428f1a4918b228429c273e56687f/Rubberduck.VBEEditor/ComManagement/TypeLibs/TypeInfoVBEExtensions.cs#L141
However this cannot be implemented directly in VBA since even if the method of invoking catches
End
statements, there needs to be some code to handle that caught error, and if it's VBA then it will be destroyed - https://chat.stackexchange.com/transcript/message/54875311#54875311There are 3 solutions I can think of:
Use the RD method of invocation, but write some assembler to convert from WinAPI timer procs and whatever signature the invocation requires, and this way VBA is avoided entirely
Create an addin in C# or VB6 perhaps which does what RD does natively and is unaffected by the code termination
Write the error handling stuff in native assembler and forward the function call through that
The text was updated successfully, but these errors were encountered: