Disable NameMapping Cache?

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.

Hi Arlene,

Hi Tanya,



What I mean is what is discussed in RefreshMappingInfo. I mean about caching mapped objects to speed up test runs. Is there a way to disable TC from "remembering" found objects?

Hi Arlene - 



The link Tanya posted is what you want.  It will explain how to turn off the Code Completion info.  That's the cache you are talking about.





Hi Tanya -



There's a typo in that article.  ;)

Hi Marsha,



I don't believe that's what I mean. I mean specifically about this line in the RefreshMappingInfo article:



"TestComplete caches mapped objects to speed up test runs. The first time a test uses an alias, TestComplete remembers the found object and uses the cached object for all subsequent uses of the alias."



The article Tanya pointed out to me talks about objects and properties in the code editor. I'm talking about cached objects during playback. After a test uses an alias once in a test, it caches the object (and its property values) found in the object browser and tries to use the cached object with subsequent calls to that alias.



I am wondering if there is a way to disable this feature so that TC will always look for the matched object in the object browser, instead of using the cached one, as it is possible the object properties will have changed.



If I am completely misunderstanding something please feel free to correct me. And if RefreshMappingInfo is the only way to get around this, then please let me know also.



Thanks.

Hi Arlene,



I am using Namemapping without any problem for a complex dynamic web application when the contents of the mapped object (i.e. the object itself and its children) can be changed very significantly or even be recreated.

May it be that the problem is not with 'caching' but with the way how tested objects are namemapped and/or how they are used by the test code.

If you provide us with more specific details instead of generic "object property changes are giving us a lot of trouble..." there is a chance that somebody will have some good idea that might help.

Hi Alex,



Apologies for not clarifying. I'd written another post about the problem, but it didn't seem like anyone knew the answer / maybe it didn't get noticed - so I tried to think of other ways to solve it. Any help would be appreciated.



Basically, in our Swing app, some of our JDialog code is written a bit poorly, as in, some of the JDialogs are not disposed of properly. For example, when you open a dialog in the app, then close it, a new dialog instance will be created when you open the dialog again, and the old instance will remain invisible in the background.



This is causing trouble with namemapping because that old, invisible, instance is cached, and the only way I know to get the new, visible, instance is by calling RefreshMappingInfo on the mapped object. I am currently using AWTComponentName, which is set in the code and very static, and the Visible property to identify components.



This is doable, but a bit tedious, as we are trying to keep things as simple as possible for QA (keeping to keyword tests, straightforward test recording, as little 'hacking' as possible, etc.). Clearly, another option is to clean up those dialogs, but I was wondering if there were other possible solutions, if only to have a wider selection of options.



Thanks for any help.

Hi Alex,



Thanks for the reply. The problem is that the invisible component is one of the larger parents itself - an entire dialog - rather than individual components in a dialog, so it's a bit trickier to discern old, identical, invisible versions from the newer, visible ones.



It doesn't seem like there is really a way to turn it off, and it seems the only solution is a manual one (RefreshMappingInfo), so I think we're just going to clean up those dialogs and hope that'll be enough.



Thanks again for all your help. Very much appreciated.



-Arlene

Hi Arlene,



If you have a chance to get the original problem (not properly disposed of dialogs) solved, then this is definitely the best way to go.

Otherwise, if RefreshMappingInfo works for you, I think that this is OK to use it (at the cost of some performance penalty.

In my case it was 'by design' how developers hide this or that element from been displayed on the screen. So I ended up with search for all required controls (e.g. all buttons that are children of the given form) and then check the values of .Parent.Visible (as well as .Parent.Heigth and .Parent.Width) for several levels up (3 levels usually was enough).