VbComponents.Remove doesn't always remove module

Question

I\'m trying to use Chip Pearson\'s code for overwriting an existing VBA code module with an import from another project. Original code here.

The particular section

Answer 1

I've spent endless time on removing/replacing Code Modules in order to find out what triggers works versus doesn't work.

Removing/replacing Code Modules in another Workbook

This is by far the least troubling approach and that's why I've implemented it with Code Module Management. Therein, for any yet not open Workbook, enabled to be selected in a file dialog, the Workbook is opend with:

Application.EnableEvents = False
....Open "workbook-fullname" ' selected in a file dialog
Application.EnableEvents = False

Code Module Management will not work when the target Workbook had been opened manually before (and thus is presented for selection as list of open Workbooks) by not having prevented any VBA-Code from being executed (see here for ways this can be achieved). Of course this is only an issue when Workbook_Open executes code.

My conclusion: Once Macros(Subprocedures, Functions, etc.) had been executed, a copy of the VBA-Code resides in memory. Thus, any Remove will not happen before the procedure which removed the Code Module has finished. Consequently an Import considers the Code Module still existing and imports a Code Module with the same name with a numeric suffix to make its name unique. And this of cource is always the case when ...

Removing/replacing Code Modules in 'ThisWorkbook' *)

Up to now I have not found any way to achieve this - except for a Class Module not declared in any of the other Code Modules, which I've realized accidentially! . Consequently I tried to temporarily comment out all declarations before Remove. Full success! Remove and Import worked fine. But when I finally tried to un-comment the previously out-commented declaration code lines, Excel allways crashed (in both cases, .DeleteLines and .InsertLines and .ReplaceLine). Since I have not found a solution for this I've given up trying - at least for the time being.

See the Code Module Management for making Cleanup, Remove, Transfer, Export, Import, and even Synchronize much less cumbersome, save and reliable. Even selecting the wrong 'target' Workbook for a transfer or a remove is no drama because of an Undo feature.

*) The difference between ActiveWorkbook and ThisWorkbook matters here. ThisWorkbook is the Workbook in which the VBA code is executed while the ActiveWorkbook may be another one. Because normally both are identicall, not paying attention on the difference doesn't matter.