IDispatch Late-Binding Cache Invalidation in Visual Basic 6

Answer

The Visual Basic 6 runtime does not expose any method, API call, or setting that can invalidate the IDispatch DispID cache for a live object reference while keeping that reference alive. Likewise, there is no documented configuration (registry key, INI file, or environment variable) that disables the caching so that every late‑bound call performs a fresh name resolution.

Confirmed Facts

1. The first late‑bound call to a member triggers IDispatch::GetIDsOfNames; the returned DispID is stored in an internal cache associated with that object variable.
2. Subsequent calls reuse the cached DispID until the object variable is set to Nothing (or goes out of scope), which destroys the reference and clears the cache.
3. No VB6 language feature, COM API, or runtime flag can flush or refresh that cache without releasing the reference.

Likely Explanation

The cache is an internal optimization of the VB6 dispatch helper. Because the helper holds the DispID in a per‑variable slot, the only way to obtain a new slot (and thus a fresh lookup) is to drop the old variable and create a new reference via CreateObject, GetObject, or similar.

Steps to Obtain a Fresh DispID

1. Set the current object variable to Nothing (e.g., Set obj = Nothing).
2. Create a new reference to the same COM component (e.g., Set obj = CreateObject("ProgID.Class")).
3. Use the new variable for late‑bound calls; the runtime will perform a fresh GetIDsOfNames call and cache the new DispID.

Verification (Optional)

' VB6 test sketch
Dim obj As Object
Set obj = CreateObject("Some.Com.Class")
' First call caches DispID for "MethodA"
obj.MethodA
' Modify the component (add/reorder a method) while obj remains alive
' Second call will likely fail with "Member not found" if the DispID shifted
' Release and recreate
Set obj = Nothing
Set obj = CreateObject("Some.Com.Class")
obj.MethodA ' succeeds after fresh lookup

Missing Diagnostic Detail

If releasing the object could affect other parts of your application (e.g., the COM server is shared or uses a singleton lifetime), you should confirm whether the component is designed to tolerate multiple instances or if it relies on a single live reference. Knowing this will determine whether the release‑and‑recreate approach is safe in your specific scenario.