Late Binding Global Variables?

后端 未结 2 1984
独厮守ぢ
独厮守ぢ 2021-01-21 01:27

I\'m using VBA for Excel. From my understanding, global variables need to be declared outside of any subs. That\'s the only way they can be accessed by all subs.

At th

相关标签:
2条回答
  • 2021-01-21 01:59

    Global variables are really not needed and should be avoided. However, if you have decided to use them for a your own reasons, you can put them in the Workbook_Open event:

    Option Explicit
    
    Dim Dic1 As Object
    Dim Dic2 As Object
    
    Private Sub Workbook_Open()
    
        Set Dic1 = CreateObject("Scripting.Dictionary")
        Set Dic2 = CreateObject("Scripting.Dictionary")
    
    End Sub
    

    Thus, it would create the object every time the workbook is opened.

    0 讨论(0)
  • 2021-01-21 02:02

    Like the VBA code itself, project references don't magically disappear when your user opens your host workbook. They're saved along with the code in the host document.

    So, the premise of your question is wrong: users never need to tweak project references.

    Also the Scripting Runtime type library is standard issue and has been shipped the exact same version on every single Windows machine built this century (even before that), which means unless your code needs to run on a Mac, there's no need to ever late-bind the Scripting Runtime library.

    And if your code needs to run on a Mac, the library won't late-bind anyway because it won't be found on the host machine, so late-binding the Scripting Runtime only serves to make silly typos and introduce other easily avoidable bugs that IntelliSense helps preventing.


    ThisWorkbook.VBProject.References.AddFromGuid GUID:=strGUID, Major:=1, Minor:=0
    

    This defeats the entire purpose of late-binding: it's using the VBIDE extensibility library (which requires lowered macro security settings) to programmatically add a reference that you can easily add at design-time through the VBE's Tools menu.

    Late-bound code doesn't need the reference at all. Not at compile-time, not at run-time.

    Add the reference, save, then declare your objects As Scripting.Dictionary and enjoy the benefits of early-bound code.

    Set Dic1 = New Scripting.Dictionary
    

    That's all you need.


    What if I want to declare global dictionary object with late binding? It looks like VBA won't allow me to put any code outside of the subs (other than the declarations).

    Late binding isn't any different than early binding in that aspect. The only difference between late and early bound code is the As clause of the declaration:

    Private foo As Object ' no compile-time type knowledge: late-bound
    Private bar As Dictionary ' compile-time type knowledge: early-bound
    

    How you're initializing that object reference makes no difference to the late/early binding nature of the declaration.

    This looks up a ProgID in the registry to find the library and the type:

    Set foo = CreateObject("Scripting.Dictionary")
    

    This uses the project references:

    Set foo = New Scripting.Dictionary
    

    Both are correct, and both will work against either early or late-bound declarations. Except, if you already have a reference to the type library, there's not really a need to go hit the registry to locate that library - just New it up!

    0 讨论(0)
提交回复
热议问题