Contributions
Re: Disable NameMapping Cache?
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. -Arlene2KViews0likes0CommentsRe: Disable NameMapping Cache?
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 knowto 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.2KViews0likes0CommentsRe: Disable NameMapping Cache?
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.2KViews0likes0CommentsDisable NameMapping Cache?
Hi, I know that the objects used by namemapping are "cached" for performance purposes. And because of this caching, everytime an object property is changed, RefreshMappingInfo must be called on the object for TC to recognize the most relevant instance. My question is, is there a way to disable the namemapping cache, and if there is, is there any strong argument, performance aside, as to why I shouldn't just disable it? object property changes are giving us a lot of trouble... thanks.3.2KViews0likes9CommentsRe: TestComplete not recognizing Visible windows
Thanks for the answerMarsha. I agree that closing those extra windows would be ideal, but our application is so big at this point thatit would be unreasonable and unrealistic to try to catch all the instances of this happening. I find that I can get around this by calling Sys.Refresh() and then some_dialog.RefreshMappingInfo() just beforesome_dialog gets used,but this solution is not at all ideal as this adds an extra manual step to the automated testing procedure (QA has requested we keep to keyword tests). I don't think the index would work for us as we are working with short, incremental tests and can't guarantee the order the tests will be executed. Windows might appear before their index. At this point I'm wondering/looking intoif there is some way we can write a script to call those two methodsbefore each step, or set of steps in a keyword test.845Views0likes0CommentsTestComplete not recognizing Visible windows
Hello I'm having some trouble with TC not finding the proper dialogs and thinking they are invisible (Swing App). In the application, I have set the ID properties of my swing dialog to "AWTComponentName" and "Visible", which is always set to "true". In my test, a window is opened and closed, but sometimes not disposed of and left floating. So, when playback opens the dialog again, the "floating" invisible one is still a process, leaving me with multiples of the same dialog. Now, although this happens, I assume TC should find the dialog with the Visible=true property rather than throwing an error that the dialog it's looking for is invisible. Is my logic wrong or am I missing something completely? Thanks.1.5KViews0likes2Comments