Sys calls taking very long

Hi Russell,





Your code works instantly on my Windows 7 Ultimate x86 with TestComplete 7.52. Please let me know exactly what version of TestComplete you have, exactly what process you are searching for, and how many instances of this process exist in the system.





Can you reproduce the problem with other processes?

Hi Russell,



What if you replace your code with something like this (untested mockup):

function calculateRunningInstances(processName)

{

  var i = 1;

  var instCount = 0;



  while (Sys.WaitProcess(processName, 0, i).Exists) // 0 may be replaced with small delay (like 200) for safety reasons

  {

    instCount = instCount +1;

    i = i + 1;

  }

  return instCount;

}



Does it work faster for you?

@David  We are using the same versions.  This used to work instantly as well, this particular function is more than two years old.  I can't imagine what has changed.



Our project suite is for a family of products where a common project houses API functions to interact with our apps.  The processName parameter is passed using a global variable (__executableName) within a script unit named IVariables, which is dedicated to global variables for the entire suite.  Our processName is by default "Spiricon.Version5"  unless updated by a test run for a specific variant of this product family.  I've copied this logic to a separate unit and tried it there and it performed the same way.



*As I typed this reply, I tried only passing in the string, but commenting out the Sys.Refresh and it was speedy once again.  In fact now anything I pass in works fine.  However, if I include the refresh call again its still slow.  I guess the big question now is, have you ever seen anything cause Sys.Refresh() to go into a tizzy?  I understand that sometimes it can be slow, but not the 2-3 minutes that I'm seeing now.



@Alexei  I suppose I can change this function to work like that, your mockup works fine btw. It would eliminate the need for the refresh, but the refresh is used in other functions as well and I'm seeing the same performance problem there too.

I'm working on a new workstation and I'm also having trouble getting into our app like normal.  The process only has one object "Window("HwndWrapper[Spiricon.Version5.exe;;30ca107e-461f-4df4-b475-cd291fc686d6]", "BeamGage® Standard 5.3 BeamMaker", 1)".  Its been a long time since I've seen this and I can't recall why this is happening.  Could someone jar my memory?

Hi Russell,



Assuming the tested application is a .Net one (let us know otherwise):

-- Is a proper .Net version installed on the problematic box?

-- Was this version of .Net installed prior to TestComplete?

-- Was TestComplete reinstalled/repaired if .Net was installed after TestComplete?

-- Are all relevant Extensions installed in TestComplete?

-- And finally :) - Does tested application contain debug information as per AQA's recommendations?

-- Is a proper .Net version installed on the problematic box?

Yes its a .NET 3.5 SP1/WPF application.  As I'm on Windows 7, .NET 3.5 SP1 is included with the OS.

-- Was this version of .Net installed prior to TestComplete?

Yes, included with the OS.

-- Was TestComplete reinstalled/repaired if .Net was installed after
TestComplete?

Not applicable but I will attempt a repair on TC anyway, perhaps another part of my development environment is messing with it.

-- Are all relevant Extensions installed in TestComplete?

It ssems to be so.  I'll attempt a repair however.

-- And finally :) - Does tested application contain debug information as
per AQA's recommendations?

In this particular case no.  Though I've been testing Release builds of this app for 2.5 years, only to now have this occuring again... I can switch to full debug builds that include both the debug assemblies and pdb's if I have to.

Hi Russell,





It seems that you have .NET Framework 4.0 installed on this machine or you had this version of the framework installed. This fact breaks the .NET Open Applications feature in TestComplete 7.52. We have a fix for this problem and you can get it if you send a request directly to us via the Contact Support form.

That would absoluetly make sense.  Since working with TC last I have
been working to get our TFS environment upgraded to 2010.  I'll submit my request and let you know the results.  Thanks.

I'm not sure what has changed but on Thursday Sys.Refresh() calls started taking a long time again.  During test execution that call will sit for up to 5 minutes before the test will move on again.  This does seem to be worse in this particular project in my project suite.  Can you think of anything within the project level that would affect this?  Perhaps there is a setting that is different that I've missed?

Hi Russell,





This behavior can be caused by the fact that the value of the 'Method Invoke Timeout' project option is too large. Please make sure that you have the default value of 3000 ms.





We have just released TestComplete 8. Could you please try requesting a trial version of TC8 and checking whether the problem can be reproduced with it?