Contributions
Re: IE 11 crashes now after converting projects from JScript to JavaScript
Hi Marsha, thanks for your reply. Yes I use the Close() method at the end of a testscript. Each test opens and closes the IE (clear cache, delete history,...) in order to have the same starting point. In my test runs there are always only one instance of IE open.1.5KViews0likes1CommentIE 11 crashes now after converting projects from JScript to JavaScript
I am one of the lucky guys who ran intothe JScript performanceproblem after updating my windows 10 to version 1803. https://community.smartbear.com/t5/TestComplete-General-Discussions/TestComplete-and-Windows-10-April-2018-Update-version-1803/td-p/166281 Smartbear support suggested to convert my projectsuite to JavaScript. After a few modification: https://support.smartbear.com/testcomplete/docs/scripting/specifics/javascript-for-jscript-users.html The tests are running again but I encountered another problem. I got sporadically IE (11.228.17134.0) crashes when using the Close() - method on the browser object. Testlog messages are: The iexplore.exe process crashed. (Exception code: 0xC0000005.) The process "iexplore" was closed. After several IE crashes the IE freezes and the testexecution stucks. Anyone has an idea how I can fix that? Thanks in advance!Solved1.5KViews0likes3CommentsRe: ClickItem Intermittently Fails
Hi, I have the same problem the moment I got a new OS (Win10). With Win7the ClickItem() operation on Select controlsworked 100% of the time. After the OS update the ClickItem() operation on Select controlsfails frequently. With Win10 and IE11 the opening of the select-dropdown looks differently compared to older OS and IE11. If the desired item is not in the visble part of the dropdownTC or TE throws the error message There was an attempt to perform an action at a point, which is beyond the screen. System: Windows 10 Pro Version 1709 TestComplete Version12.42.3048.7 Internet Explorer 11.192.16299.0 Has someone a solution for this problem? Regards, Timo1.1KViews0likes1CommentRe: start test complete in the 32 bit version
To the information "That said, you don't have to fully upgrade your MS Office to make use of the 64-bit version. There's a redistributable download that you can install to have access for 64-bit processing. " I can't install the driver because of the 32bit Office installation. The driver installation says that the 64bit driver can only be installed if all 32bit Office products are deinstalled. So I'm not able to use the 64bit installation.3KViews0likes0CommentsRe: Test for Different Regional Settings
Hello I was searching for the same topic (I know this is an old post) and I found another solution which works better for newer OS. Windows7 and also Windows Server 2008 R2 has the command 'tzutil' which can easily change time zone from windows command line (reference http://www.windows-commandline.com/set-time-zone-from-command-line/). So the JScript version of the setTimeZone() would be: function setTimeZone(Timezone) { var WshShell = Sys.OleObject("WScript.Shell"); var CmdLine = "tzutil /s "; var Param = CmdLine + aqString.Quote(Timezone); Log.Message("Parameter: "+ Param); var WshShellExec = WshShell.Exec(Param); }5.5KViews1like0CommentsRe: Performance Issues with objects using "Extended Find" in TC 11.20
I got a solution from the smartbear support. With the new TC 11.20 version the namemapping find algorithm was reworked. In some cases this new algorithm is slower than the old algorithm from TC 10. TestComplete can be launchedwith the "/UseOldFindAlgorithm" command-line argument. With this argument TC11.20 uses the old TC10 find algorithm. You can do this in two ways: 1. Press the "Win" + "R" keyboard keys and execute the following command: "C:\Program Files (x86)\SmartBear\TestComplete 11\Bin\TestComplete.exe" /UseOldFindAlgorithm 2. Navigate to the Properties of the TestComplete shortcut and add the /UseOldFindAlgorithm command-line argument to the Target field: "C:\Program Files (x86)\SmartBear\TestComplete 11\Bin\TestComplete.exe" /UseOldFindAlgorithm This solution also works for TestExecute. I just added the "UseOldFindAlgorithm" parameterto the TestExecute command-line calls in my batch-files. Regards, Timo1.6KViews6likes0CommentsRe: Performance Issues with objects using "Extended Find" in TC 11.20
Nobody facing the same performance issues? I found another code block which consumes additional time with TC 11.20: if (Global_LoginPage.WaitNamedChild("P_LoginError",3000).Exists) { // do something } With TC 10.x this code block had a maximal delay of 3s. With TC 11.20 i face delays bigger than 10s. I really appreciate your help. Regards, Timo1.7KViews0likes0CommentsRe: Performance Issues with objects using "Extended Find" in TC 11.20
Hi djadhav, thank you for your reply. The AUT uses DevExpress controls where it is difficult (perhaps only for me)to detect the loading state of the control (e.g. switching to another page in a DevExpress grid control). My approach to detect the ready state of the control: do { // JobFolder still loading NameMapping.Sys.Refresh(); NameMapping.Sys.RefreshMappingInfo(); IterCount++; } while (LoadingTN.WaitProperty("VisibleOnScreen", true, 1000) == true && IterCount < MAXITER) LoadingTN is the control which indicates the loading state. I'm using this kind of code block over my whole projects. Please correct me if I'm doing it wrong or if there is a better approach. My understanding is that this code block waits maximal one second and jumps to the next iteration until the LoadingTN control is no longer visible. I execute my tests on a virtual machine which is not as fast as my local maschine. Since updating to TC 11.20 I have "Searching for a mapped object took too much time" warnings in the mentioned code blocks in my testlog which I did not have before. When I execute the tests on my local maschine I also observe longer wait times in the mentioned code block. Iassume it isbecause ofthe LoadingTN control is mapped via Extended Find. The TestComplete indicator displays the searching of the LoadingTN control (takes several seconds -> unexpected behaviour) and the WaitProperty() call (takes 1 second -> expected behaviour). Thank you in advance. Regards, Timo1.7KViews0likes0CommentsPerformance Issues with objects using "Extended Find" in TC 11.20
I upgraded my TC installationfrom Version 10.x to TC Version 11.20. With the new TC 11.20 installationI have to face performance problems with my tests whichareusing objects mapped via "Extended Find". Test runs consume approximately 30% to 40% more time than before. I tried to add additional mapping levels in my NameMapping tree but it was not sufficient to speed-up the test execution. A complete mapping of the affected objects is no option for me because the internal structure of the AUT is changing a lot. Therefore tests stability across different versions of AUT is of primary importance for me. My questions are: Am I the only one facing this performance problem? Is there a solution or workaround? Regards, TimoSolved1.7KViews0likes4Comments