Ask a Question

The started WPF application by the script is treated as window32 appliaction.

jenli
Contributor

The started WPF application by the script is treated as window32 appliaction.

Sometimes, with the under of  a tested WPF application, TestComplete recognizes it as Window32 application even it recordered as WPF application. I found out this  while playing back the recorded scripts, TestComplete complainedthat  it can not find the  top window.

Then I went backto Object Broswer, The top window under the Process is recognized as Window("...") instead of WPFObject("...").  Any clues about this situation?   
9 REPLIES 9
jenli
Contributor

RE: The started WPF application by the script is treated as window32 appliaction.

When I recorded my WPF application, the top window is recognized as:

Aliases.Sys.ApplicationName.WPFObject("HwndScource::ShellView,"ApplicationName");

Sometimes, TestComplete recognized it as Window32 application as:

Aliases.Sys.ApplicationName.Window("HwndWrapper[ApplicationName.exe;;3757703a-dd5a-4f51-aa2c-adb49cc803fc]", "ApplicationName", 1).
jenli
Contributor

RE: The started WPF application by the script is treated as window32 appliaction.

This problem is very noisy since I can not cinsistently run my automated testing.


 


RE: The started WPF application by the script is treated as window32 appliaction.

Hi Jennifer,


It looks like the problem is that your application is not recognized as Open for some reason.


First of all, please make sure that the .NET Open Application Support plug-in is installed and enabled in TestComplete ("File | Install Extension..."). If this suggestion does not help you solve the problem, we need some additional information to investigate the issue. Please answer the following questions:


1. A possible cause of the problem is that some complex actions which take long to be completed are performed in the application's GUI threads when the application is started (the application's main window may become blank or unresponsive in such cases). If so, try increasing the "Method invoke timeout" option described in the "Project Properties - General Open Applications Options" help topic, check whether the problem persists and let us know your results.


2. What version of TestComplete are you using (Help | About...)? If it is earlier than TestComplete 7.52 (the latest version of TestComplete 7), please update the tool and check whether the problem persists in this version.


3. Is your tested application compiled for an x86 platform or for an x64 platform?


4. Exactly how is the application launched? Is it launched as an item of the Tested Applications collection? Is it launched under another account (in the RunAs mode)? Is it launched before or after TestComplete is launched? Please send us a detailed description of the steps you follow to launch the application.


5. Is the application launched from a network folder or from a folder having specific Runtime Security Policy settings? If it is, please make sure that the Runtime Security Policy settings for the folder from which the application is started are set as it is described in the "Working With Network and No-Touch-.NET-Deployment Applications" help topic.


6. Is the application treated as Open according to the Process Filter options? Please see the "Project Properties - Process Filter Options" help topic for details.


7. The problem can be caused by the fact that TestComplete is terminated incorrectly and the tested application is not restarted after that. Is this your case?


8. Does your application's process have child objects named "AppDomain(...)" when the application is not recognized as Open?



Best regards,
Alexey

Did my reply answer your question? Give Kudos or Accept it as a Solution to help others. ⬇️⬇️⬇️
jenli
Contributor

RE: The started WPF application by the script is treated as window32 appliaction.

Hi Allen,

 

   See my answers to your  questions:



1. A possible cause of the problem is that some complex actions which take long to be completed are performed in the application's GUI threads when the application is started (the application's main window may become blank or unresponsive in such cases). If so, try increasing the "Method invoke timeout" option described in the "Project Properties - General Open Applications Options" help topic, check whether the problem persists and let us know your results.

   Sure, our WPF application is very complex. When this occured, the application's main window does not become blank and is responsive to my manual GUI  actions but my testscript can no longer find the top WPF window.   After I increased the "Method invoke timeout"  to 30000. The frequency of this probelm has been  reduced.

  When this problem occured, I wnet to Object Broswer and saw my WFP application is still recognized as Open application but as Open Window application not Open WPF application.



2. What version of TestComplete are you using (Help | About...)? If it is earlier than TestComplete 7.52 (the latest version of TestComplete 7), please update the tool and check whether the problem persists in this version.



   We are using Testcomplete 7.52.



3. Is your tested application compiled for an x86 platform or for an x64 platform?

       Our tested application is compiled for an x86 platform.



4. Exactly how is the application launched? Is it launched as an item of the Tested Applications collection? Is it launched under another account (in the RunAs mode)? Is it launched before or after TestComplete is launched? Please send us a detailed description of the steps you follow to launch the application.



  I have tried the different approaches to launch the my WPF application. Normally, it is launched as an item of the Tested Applications.collection  as:



TestedApps.myWPFApplicationName.Run(1, true);



  I also tried to lauch the application before and after TestComplete is launched. This still occurs.  To resolve this, I tried to launch the application several times or just reboot my testing computers.



5. Is the application launched from a network folder or from a folder having specific Runtime Security Policy settings? If it is, please make sure that the Runtime Security Policy settings for the folder from which the application is started are set as it is described in the "Working With Network and No-Touch-.NET-Deployment Applications" help topic.



  The application is launched from my local disk folder.



6. Is the application treated as Open according to the Process Filter options? Please see the "Project Properties - Process Filter Options" help topic for details.

   Yes.



7. The problem can be caused by the fact that TestComplete is terminated incorrectly and the tested application is not restarted after that. Is this your case?



   No.



8. Does your application's process have child objects named "AppDomain(...)" when the application is not recognized as Open?

   My WPF application is always recognized as Open but not as WPF application but as Window application or occasionally under the process, it was recognized UIAObject.
YMinaev
Staff

RE: The started WPF application by the script is treated as window32 appliaction.

Hi,



Try increasing the "Method invoke timeout" option's value (Tools | Default Project Properties | Project | Open Applications). Does it help to reduce the problem's frequency? Does the problem occur if you keep increasing this value?



BTW, note that this option's value does not apply to projects which are already created (you need to modify their properties).
------
Yuri
TestComplete Customer Care Engineer

Did my reply answer your question? Give Kudos or Accept it as a Solution to help others. ⬇️⬇️⬇️
jenli
Contributor

RE: The started WPF application by the script is treated as window32 appliaction.

There are lots of discussions in the thread "Testing WPF Program Causes Crassh".

  Yes, I  already increased  the "Method invoke timeout" option's value way up to 30000. 

It helps to reduce the problem's frequency but not completely gone. Yeasterday even WPF Orders application coming with TestComplete was recognized as Window Application. I saved tcObject file. Please see the thread "Testing WPF Program Causes Crassh". Hope this mya help you to invetigate this issue.

RE: The started WPF application by the script is treated as window32 appliaction.


Hi Jennifer,





Could you please clarify whether you increased the value of the "Method invoke timeout" option located in the Tools | Default Project Properties | Project | Open Applications group? Note that this option and the "Method invoke timeout" option located in the Open Applications | General group of the project editor's Properties page are different options. Does the problem occur if you keep increasing the value of the former option?
--
Dmitry Nikolaev

Did my reply answer your question? Give Kudos or Accept it as a Solution to help others. ⬇️⬇️⬇️
jenli
Contributor

RE: The started WPF application by the script is treated as window32 appliaction.

Hi David,

  I used both approaches to set method Invoke timeout to 30000.


RE: The started WPF application by the script is treated as window32 appliaction.


Hi Jennifer,





To continue the investigation, we will need the following information:





1. Try setting the values of both "Method invoke timeout" options so that they will equal double the application start time. Does the problem occur after that?





2. Let me know exactly how often the problem occurs.





3. Open Event Viewer (Start | Control Panel | Administrative Tools | Event Viewer). Right-click the 'Windows Logs | Application' node and select "Save Events As...".

Save the log to a file and send it to us.





4. Download the Process Explorer tool. It doesn't require installation - just run the procexp.exe executable. After the problem occurs, follow the steps below:





* Launch the Process Explorer;

* In the Process Explorer:

    - select the TestComplete.exe process in the tree;

    - press Ctrl+D or the "View DLLs" toolbar button to switch to the DLL mode;

    - save the contents of the lower sub-window (File | Save As...);

    - send us the resulting file.





5. After the problem occurs, check the value of the IsOpen property of your application process (you can find this value in the Object Browser).





I recommend that you send your answers along with files in a request submitted via our Contact Support form.





Thanks in advance.
--
Dmitry Nikolaev

Did my reply answer your question? Give Kudos or Accept it as a Solution to help others. ⬇️⬇️⬇️
cancel
Showing results for 
Search instead for 
Did you mean: