Hi Arlene,
Thank you for the additional description. Based on it, I don't think that the (real) problem is in namemapping cashing but in the way how this problematic dialog is identified in NameMapping.
> I am currently using AWTComponentName, which is set in the code and very static, and the Visible property to identify components.
I would recommend to investigate both old (invisible) and correct current (visible) objects in the Object Browser and figure-out properties that make it possible to clearly and reliably distinguish between them.
I had cases like yours and please note that it might appear that both old and current object instances may have Visible property set to True with one of the parents of the old object been hidden (thus, making old object not visible even despite the fact that the object itself has the Visible property set to True). In this case, depending on your application, you either might be able to find the property(ies) of the current object that distinguish it from the invisible one (e.g. Width and/or Height properties are gross than zero); or introduce some intermediate parent object which, when visible, guarantees visibility of the current dialog object; or use the coding approach (some function) that will return the current visible object.
Side note:
The real reason (AFAIR) of why RefreshMappingInfo helps in your case is because:
a) When a new instance of dialog is created, it gets the next value of the Index property and is located 'closer to the end' of the objects tree (you should see more than one dialog object in the Object Browser at this moment); and
b) NameMapping functionality searches for the objects starting from the 'end' of the objects tree.
This is the reason of why expected correct object is returned after the call to RefreshMappingInfo and why I think that you should double-check if the parameters used to NameMap the problematic dialog identify the correct visible one but do not at the same time correspond to the old invisible instance.