Timeline for Sub that calls itself when its parent Workbook is closed
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 21, 2022 at 16:31 | comment | added | GWD |
You are of course right, more code is not a problem per se. I usually distribute .xlsm files and don't use add ins, which is why I like Cristians way of providing libraries (as standard modules)... And I have to point out that this method doesn't crash on breakpoints unless called as Release, which is usually a small minority of all the calls...
|
|
| Nov 21, 2022 at 15:41 | comment | added | Greedo | I should actually incorporate Cristian's code as a "StableTimerProvider" or something, for developing in Excel and then you switch to release mode and use the raw API... | |
| Nov 21, 2022 at 15:40 | history | edited | Greedo | CC BY-SA 4.0 |
deleted 1 character in body
|
| Nov 21, 2022 at 15:37 | comment | added | Greedo | What I'm trying to say is context is key. So I agree with your view if, copy+paste, single-use code, long timer delay are your assumptions. But if nice API, high performance low-overhead, addin distribution is your approach I'd just ship with a Timing.xlam dependency. And if you are editing and debugging, Cristian Buse's code is the safest, but likely a bit more overhead setting up that second workbook. | |
| Nov 21, 2022 at 15:28 | comment | added | Greedo |
"More code" isn't exactly the issue - it's more that if copy+paste is your distribution method, then portability is a concern. If you distribute a self extracting zip, or using a package manager (or RD sync) those issues go away. Plus you get the benefit of being able to update the code. If cross-platform compatibility is an issue, I'd just implement Application.OnTime as an ITimerProvider i.sstatic.net/jMLJB.png . Stability-wise there is a difference between "I can't set a breakpoint or it'll crash" vs "I can set breakpoints but cannot prematurely exit the Sub or it'll crash"
|
|
| Nov 21, 2022 at 14:16 | comment | added | GWD |
I have heard of your work on timers before but only skim-read it so far! This has the big advantage of being cross-application but the disadvantage of being Windows only. Without having looked into it in detail though, I think if working in Excel and not requiring sub-1-second resolution (or requiring stopping on End which would indicate other problems in the code anyways), Application.OnTime with the IUnknown trick makes more sense. It requires way less code and seems to be similar stability-wise. (Of course, I mean the version where SetIUnknown and Release are separate procedures..
|
|
| Nov 21, 2022 at 12:11 | history | answered | Greedo | CC BY-SA 4.0 |
