K
Keith Johnson
Over the years, I've seen allusions to circumstances in which the VBE's
Project Explorer retains a reference to just-closed workbooks, but
still can't understand whether this can be avoided. Here's a simple
example:
Set Wkb = Workbooks.Open(Path)
Call Application.Run("'" & Wkb.Name & "'!Install")
Call Wkb.Close
Set Wkb = Nothing
Path is the full path of an existing, closed workbook containing
nothing but one public sub, Install, which just shows a MsgBox.
After this code has run, the VBE's Project Explorer still includes Wkb.
The "View Object" button for ThisWorkbook and it's sole Sheet1 are
greyed out. I can, however, still see the code. Moreover, I still can
execute this code (using F5). Attempting to Debug>Compile, on the
other hand, fails with an "Out of Memory" error. And attempting to
remove the "phantom" code module crashes Excel. In most -- maybe all
-- instances (it's hard to remember all the variations I've tried),
restarting Excel eliminates the phantom. But that doesn't really solve
anything if one wants to use code such as this and continue working,
especially because Excel is near-unstable.
Maybe I've gotten Excel corrupted somehow, and this behavior cannot be
reproduced on a clean system. If not, has anyone been able to identify
why this happens and whether there is a work-around?
Thanks,
Keith
Project Explorer retains a reference to just-closed workbooks, but
still can't understand whether this can be avoided. Here's a simple
example:
Set Wkb = Workbooks.Open(Path)
Call Application.Run("'" & Wkb.Name & "'!Install")
Call Wkb.Close
Set Wkb = Nothing
Path is the full path of an existing, closed workbook containing
nothing but one public sub, Install, which just shows a MsgBox.
After this code has run, the VBE's Project Explorer still includes Wkb.
The "View Object" button for ThisWorkbook and it's sole Sheet1 are
greyed out. I can, however, still see the code. Moreover, I still can
execute this code (using F5). Attempting to Debug>Compile, on the
other hand, fails with an "Out of Memory" error. And attempting to
remove the "phantom" code module crashes Excel. In most -- maybe all
-- instances (it's hard to remember all the variations I've tried),
restarting Excel eliminates the phantom. But that doesn't really solve
anything if one wants to use code such as this and continue working,
especially because Excel is near-unstable.
Maybe I've gotten Excel corrupted somehow, and this behavior cannot be
reproduced on a clean system. If not, has anyone been able to identify
why this happens and whether there is a work-around?
Thanks,
Keith