Thanks Richard.
Yeah, I changed that line to Worksheets("The List").Activate just for the sake of this example so it would run. In the actual project all worksheet references use CodeNames.
I have also been toying around with it, and have come to the same conclusion; it must be split into two separate macros. So I did something like this:
Private Sub WorkBook_Open()
If (the list worksheet does not exist in the UserBook) then
(Copy the list worksheet from the MasterBook to the UserBook)
Else If (the list worksheet does exist in the UserBook but it needs to be updated) then
(Delete the list worksheet from the UserBook)
(Instruct the user to close, then re-open their file)
'UserBook.Close True '<--- Does not work.
EndIf
End Sub
This way does work, but it leaves a step in the hands of the user. If they decide not to obey the message (or don't read it, as many don't), and if try using any of the features or running any of the macros which use this worksheet while it's deleted, everything will crash. I don't want any crashes in a polished product, so I'm going to have to bang my head against the wall a little longer before accepting this.
I tried throwing in a UserBook.Close True at the end, so at least they couldn't use the file if the worksheet is missing, and when they open it again it will complete the update... but apparently that still behaves as though the macro was never stopped.
In fact, that does something even weirder... the wsTheList1 worksheet appears again (bad), but this time there is also a ghost workbook with the CodeName wsTheList. It's right under ThisWorkbook in the Project Explorer and it has a workbook icon instead of a worksheet icon. It won't let me view it or do anything with it, not even remove it. Continuing to update the file in this way creates additional worksheets CodeNamed wsTheList2, wsTheList3, etc.
I've attached the new working files. Try it "as is" to see it work (with manual restarting)... then remove the ' in front of UserBook.Close and try it again to see what I mean.
Bookmarks