Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Trying to Import Classes In Use Causes Incremental Naming #25

Open
M-Scott-Lassiter opened this issue Feb 20, 2021 · 1 comment
Open
Assignees
Labels
bug Something isn't working

Comments

@M-Scott-Lassiter
Copy link
Owner

Expected Behavior

When I try to import a class, I expect it to show up with the same name, and subsequent calls will reference the appropriate class, even if I am overwriting a class that was currently in use.

Current Behavior

When I tried to import "fredDeveloper_ModuleManager", it resulted in "fredDeveloper_ModuleManager1" and subsequent scripts thus didn't find the correct reference.

Steps to Reproduce

  1. Run this script
Sub FredSourceControl()
    Dim ModuleManager As New fredDeveloper_ModuleManager
    
    With ModuleManager
        .Directory = ThisWorkbook.Path & "\Source Code"
        .Import "fredDeveloper_ModuleManager"
    End With

End Sub
  1. Subsequent runs will not compile, because it overwrote fredDeveloper_ModuleManager as fredDeveloper_ModuleManager1

Possible Solution

Either prevent this behavior, or find a way to write as a second class, delete the first, and rename the second one.

Environment

Microsoft Office Version: 365
Program: Excel
Operating System: Windows 10
Other Relevant Information: None

@M-Scott-Lassiter M-Scott-Lassiter added the bug Something isn't working label Feb 20, 2021
@M-Scott-Lassiter M-Scott-Lassiter added this to the Reach Version 1.0 milestone Feb 20, 2021
@M-Scott-Lassiter M-Scott-Lassiter self-assigned this Feb 20, 2021
@adimarculescu
Copy link

The workaround is to first remove the class module in question, end code execution and then execute (from a secondary procedure) the module import. This is needed because VBA needs to update internally the remaining files in the project, after module elimination, and it does so only when the code execution stops. Thus any module update mechanism needs to be in 2 parts: first, removal of target modules and then adding updated modules.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants