Stop button doesn't work when API referenced from Addin

[Greedquest]

It seems Excel loads addins as quite separate files, and interestingly the Stop button does not affect VBA loaded in the addin. This could certainly have some positives, in ensuring certain objects persist beyond timer destruction, allowing for safe cleanup.

Couple of solutions

• Move out of addin and into self extractor for sharing code, this way everything is as normal
• Get user code to supply the Userform ref that hosts the timer
• Create a VBA function that persists after stop button press and does something clever. This could also stop the End statement crashes perhaps

[Greedquest]

A cool opportunity here is to remove the ties to a Userform; the original reason for using a Userform was not to provide a hwnd for the timer messages - the thread message queue (hwndless) would suffice - but to invalidate the timers upon state loss. This is because when hitting the stop button you kill VBA callback functions but not the WinAPI calling them, so WinAPI would crash the host when it tried to call a TIMERPROC that no longer existed. Userforms are killed by VBA, removing the hwnd and invalidating WM_TIMER messages so the now destroyed TIMERPROCs are never called (I guess there is no race condition here because VBA cleanup is in the same thread as the message queue so the hwnd is always invalidated in the same (atomic?) step as the TIMERPROCs).

Anyway if VBA code in an addin survives termination of the main project, then the TIMERPROCS could persist after state loss and do something a bit more flexible than just disappearing. Plus there would be no need to tie the timer messages to a userform which has always felt weird. This still leaves the issue of detecting state loss in the main project (we don't want the addin timers going off indefinitely) but worth thinking about...

[Greedquest]

Another avenue; create timers and invoke from tB out of proc or inproc dll