issue with XTPReport control on 64-bit

Hi Aakash,



The behavior is quite strange.



We need to be sure that the issue persists in the latest version of the product. I recommend that you use TestComplete 8.70. It is available for download from our web site.



If the behavior is the same in TC 8.70, please send us screenshots demonstrating your tested application's node expanded in the Object Browser in both cases. We need to see the difference in the way TestComplete recognizes the target control in your AUT.

I tried TC8, same issue exisits. Attached please find screenshots, I captured same XTPPropertyGrid and XTPReport objects in 32-bit and 64-bit (TC7 and TC8).



It looks like MSAA doesn't work for all XTP controls on 64-bit application, for example, for XTPToolBar object on 32-bit, each menu item is recognized as ObjectType 'MenuItem', but on 64-bit no child item is recognized. I found a workaround for this via combination of Text Recognition and OCR, but it's slower and not as reliable.



XTPPropertyGrid and XTPReport are a bigger issue for me, as they are widely used in my application, and I haven't found any reliable workaround for this. If you can provide a workaround/hotfix for this, that'll help a lot.



Thanks.

 

  

Hi Aakash,





Thank you for the screenshots.





We have analyzed them in our test lab and found a couple of important differences that can explain the behavior variations you observe on different computers:

1. First of all, you are looking at two different applications - iCam and RTVue.

2. According to your screenshots, and, specifically, to the window classes, these apps were probably compiled in different versions of Visual Studio: iCam was built in Visual Studio 2008, and RTVue - in Visual Studio 2010. 





This explains the different tree structure in TestComplete, because MSAA technology that you are using to recognize your third party controls is implemented on the side of the application as an MSAA provider. For standard controls like ListView, the MSAA provider functionality is built into the application by the IDE when you are compiling the app, and the functioning of the MSAA provider can vary from one version of a compiler (or MFC library) to another.





I have created a standard MFC application with a ListView control in Visual Studio 2010, and I saw the same tree structure as that you observe. So, the cause of this is that the MSAA provider's behavior in Visual Studio 2010 is other than that of the MSAA provider built into the apps built in VS 2008. This difference has nothing to do with your application or the settings of your TestComplete project. 





In this situation, using the same test for different applications is difficult due to the differences of the MSAA structure. If the object structure differences are specific only to this control, while the structure is the same in all other screens of the applications, you can try using conditional logic to make one test set work for both applications. However, if the object structure differences are seen in many other places of the application's UI, it may be easier to create and maintain two different test sets for the two applications.





So, the right question is now as follows:

How can one test the XTPPropertyGrid control in an application built in VS 2010?

Or how should one build/configure such an application, so that the grid contents were represented as a set of MSAA elements?





We have checked the compiled samples on the CodeJock web site, and they do not demonstrate the issue - the grid rows are represented as the MSAA Row elements:

http://www.codejock.com/downloads/samples/propertygrid.asp





This is true for both the 32-bit and the 64-bit samples. Can you send us a sample application (preferably, with the source code) which demonstrates the problematic behavior? We could try to find a way to test this control when MSAA is not working.