Contributions
Re: Searching for the mapped object "btnYes" took a long time
I eventually convinced myself that the problem was indeed that the problematic buttons were not _missing_ any mapping, but TC simply mapped them into the wrong place in the Mapped Object list. These maps were created over 10 years ago, obviously with a very old version of TC. I couldn't see any way to edit the mapping (just search criteria), so I deleted the 3 buttons from the main program parent in the Mapped Objects (including their aliases). Then I recorded a little keyword test using the 3 buttons to force TC to create new maps. The new maps went into the correct object, the same as the other buttons that do behave properly, and the problem is solved! Thanks to all, I sincerely appreciate the help.16Views0likes0CommentsRe: Searching for the mapped object "btnYes" took a long time
Thank you so much for your interest and patience! I guess it's a complement to TC that I've gotten by for 13 years without ever having to look at this part of the system. Instead of 1000 words, here are some screenshots. btnCancel (and others) appears in both Mapped Objects and Aliases under the dlgSTRIPLOGError object, and it executes quickly. However, btnYes, btnNo and btnOK are under the main process (which is actually StripLog, not MyApp) in Mapped Objects but under dlgSTRIPLOGError in the Aliases. The context menu item "Find Mapped Object" in the Aliases section finds btnYes easily in the Mapped Objects section under the main process. It seems the mapping info is known, but not easily found at runtime. It's not clear to me what needs to be changed, and where to do it.1View0likes1CommentRe: Searching for the mapped object "btnYes" took a long time
The buttons appear right at the top of the Object Tree in the Object Browser at the first level below the main program, exactly as in the Run Code Snippet call that runs in a fraction of a second. The only Button that shows there at any time is the one that is active on the screen at the time. v Process("MyApp") v Window("#32770", "MyApp", 1) v Window("Button", "&Yes", 1) The Object Spy shows the FullName as this hierarchy which is what works in Run Code Snippet, and shows the Name as Windows("Button", "Yes"", 1), but the MappedName is Aliases.MyApp.dlgMYAPPError.btnYes. The Object name dlgSTRIPLOGError doesn't appear in the Object Tree anywhere. It seems like the mapped name should somehow point to "#32770"? In the Workspace "NameMapping" tab, in its top section "Mapped Objects", it shows as "NameMapping.Sys.MyApp.btnYes", but below in the Aliases section it appears under "dlgMYAPPError". No mention of #32770 anywhere, but the context menu "Show in Object Browser" in both the top and bottom section of NameMapping find it at the top of the Object Browser.21Views0likes5CommentsSearching for the mapped object "btnYes" took a long time
I've been running TestComplete for 13 years now. I have over 1100 tests, all created with the recording function and letting TC take care of all name mapping. This is with an Open App. Nothing browser related, etc. One thing I've never had to get much involved with is Name Mapping. In recent years, certain message boxes have become very slow. Instead of a fraction of a second, it can take 20 to 30 seconds just to click a "Yes" button. When it takes more than about 10 seconds, I get the TC warning: "Searching for the mapped object "btnYes" took a long time. This happened because the sought-for object has the Extended Find attribute enabled, and the test engine searched for this object on all levels down the object hierarchy. To speed up the search and improve the test performance, add more parent objects of this object to the Mapped Objects tree of Name Mapping." I tried turning off the Extended Find but then some objects couldn't be found at all. I think I can see why the search is necessary, but don't know what to tweak in the Name Mapping to fix this. Dialogs that process button presses immediately have FullNames and MappedNames that have the same object hierarchies. Quoting one from the "Details" panes of a log file, it looks like this: Tested object: Aliases.MyApp.SaveChangesForm.CommitPanel.NoButton (Sys.Process("MyApp").VCLObject("SaveChangesForm").VCLObject("CommitPanel").VCLObject("NoButton")) One that takes a long time looks like this: Tested object: Aliases.MyApp.dlgMyAppError.btnYes (Sys.Process("MyApp").Window("#32770", "MyApp", 1).Window("Button", "&Yes", 1)) If I bypass the name mapping search and insert "Run Code Snippet" into my keyword test with the string Sys.Process("MyApp").Window("#32770", "MyApp", 1).Window("Button", "&Yes", 1), it runs in a fraction of a second. That doesn't make sense to me. If the run log Details (and the Object Spy) can list both the Alias and the FullName, why does it take so long to find the FullName (and the button) while running? We're hoping not to have to change our code PLUS the thousands of button click events in our keywordTests! The Yes button seems to have the main MyApp as it's parents. We think the problem has something to do with the dynamic nature of the message boxes used. The programmer described this: "The tested application displays many message boxes (900+) using Win32 MessageBoxA. The arguments to MessageBoxA are the handle of the active window, the message text, the title, and the style of the message box, e.g., MB_YESNOCANCEL | MB_ICONWARNING. We call MessageBoxA from thin wrapper functions such as userError(), userMessage(), debugMessage(), assertMessage(). We tested replacing MessageBoxA in several instances with the newer TaskDialog and it made no difference to the time taken for TC to find the object." I'm running TestComplete Version: 15.62.2.7 x64 on Windows 10. Our Windows development and build environment: Dell Latitude 3590 x64 16 GB RAM, Win 10 Pro v22H2 Build 19045.4170 Embarcadero C++ Builder 10.4 Update 2 DevExpress ExpressGridPack VCL Products 20.2.5 Easy Compression Library (ECL) 5.92 LeadTools Raster Toolkit Pro 15 (API version) no patch Parallax69 Eroiica API 5.0.28.0 & tif2rtl.dll (v??? 2012-11-16?) Indy 10.6.2 IdHTTP TinyXml 2.5.3 ZipForge 6.93 - Personal EditionSolved83Views1like8CommentsSyntax.CreateInvoke no longer creates "Run Script Routine" for Keyword Test
I have a number of Script Extensions that I wrote over 7 years ago. Sometime in the last year or so the record actions no longer work properly, in that the syntax that is created no longer uses "Run Script Routine" and instead tries to invoke my function directly. Here is a sample of my code: // Generate the set code function CreateSetSyntax(ldName, name, value) { // Generate the treeHelp set call by calling the layoutDesignerSetValue script var call; call = Syntax.CreateInvoke(); call.ClassValue = "LayoutDesignerFunctions"; call.InvokeName = "layoutDesignerSetValue"; call.IsProperty = false; call.AddParameter(ldName); call.AddParameter(name); call.AddParameter(value); return call; } ... // Generate code for the set method var syntax = CreateSetSyntax(ldName, name, value); ... // Insert the generated code into the recorded script Recorder.AddSyntaxToScript(syntax); // Or: Recorder.AddTextToScript(Syntax.GenerateSource(syntax)); Both Recorder.AddSyntaxToScript() and Recorder.AddTextToScript() seem to do the same thing so I've used the first form all these years. Until recently the above inserted the following into my Keyword Test at record time: Run Script Routine LayoutDesignerFunctions - layoutDesignerSetValue "Aliases.StripLog.LayoutForm", "Track=Curve Track 1|Layer=Eng. Data|Property=Constrain to Grid", "False" but now it creates: LayoutDesignerFunctions layoutDesignerSetValue "Aliases.StripLog.LayoutForm", "Track=Curve Track 1|Layer=Eng. Data|Property=Constrain to Grid", "False" I don't mind changing my code if necessary, but I can't find how to fix this. Or did it get broken when they resurrected record-time script extensions awhile ago?1.2KViews0likes2CommentsRe: Indicator causing test to stop since 12.4 update but won't hide
I don't know if Jenny installed the same patch that I have. Mine is for 12.40, hers is for 12.41. My patch has replacement files for \Bin\tcCore.dll and \x64\Bin\tcCore.dll. I'm running 64-bit. The patch that I installed fixed two problems: Indicator.Hide() now works (from Run Code Snippet), and the Indicator no longer gets included in playback Region Checkpoints. In 6 years I've never had to hide the Indicator. I only tried to hide it and discovered that I couldn't a few days ago when I was desperate for a work-around to the Region Checkpoint problem. Without hiding it, just now I did a test where I sized and positioned a window such that the Indicator would cover some menubar items during playback. I recorded a test where I clicked those menu items and during playback the Indicator seemed to be hidden automatically during the mouse clicks and then appeared again afterwards. tristaanogre- I'd be interested to know when and why one would ever have to hide the Indicator?2KViews1like1Comment