SQLiteC-for-VBA VS Excel-Pomodoro-Timer

Complete project source code with dependencies is available from the GitHub repo and the project documentation - from the GitHub pages site. I perform unit testing under x32/VBA6 (Excel XP/2002 SP3) and x64/VBA7 (Excel 2016) environments. With the entire repository cloned on Windows 10 and the two dependencies (the SQLiteODBC driver and the RubberDuck VBA add-in) installed, the following two quick checks can be executed right away from the immediate pane. This command ?LiteMan(":mem:").ExecADO.GetScalar("SELECT sqlite_version()") returns SQLite library version used by the SQLiteODBC driver (usually embedded), e.g., 3.23.3, and this command ?SQLiteC("").CreateConnection(":mem:").ExecADO.GetScalar("SELECT sqlite_version()") returns SQLite library version loaded by the project, e.g., 3.37.0. The project also includes a set of examples, which should also run out-of-the-box (see documentation).

I suspect that your reason for asking this is that you've found that getting VBA to run every X minutes (using Application.OnTime?) will throw an error if VBA is already running, or if you're in the middle of editing a cell, etc. One way around this is, as u/e032 and u/Either-Belt-1413 point out, to create a further instance of Excel (InstanceTwo), with the VBA code running in a workbook loaded into that instance. There are a number of projects which demonstrate this - it's a very useful method - but the one that comes immediately to mind (and is most relevant to what you're doing) is the Excel Pomodoro Timer. When it is loaded, it creates a new instance of Excel in the background, and loads a userform with a pomodoro timer on it, which is then displayed at all times on top of any Excel workbook you're using without throwing any of the above errors. There are some much more complex and sophisticated methods using Win32 APIs - like this one - but that may be using a jackhammer to crack a wallnut.