Ranorex Spy and MFC CListCtrl problem : Automation Tools

[deepsnow]

I'm attempting to automate tests for a C++ MFC dialog app, but I'm having difficulty getting Ranorex to extract data from cells within a list control. The list control is implemented with an MFC CListCtrl.

When I use Ranorex Spy to explore the app and its list control, I see that Spy identifies the list control as a "List", and each row is identified as a "ListItem". Unfortunately the ListItem appears to contain only the data from the left-most column in the list control, and not any data from other columns. Therefore, I conclude that the Ranorex API won't be able to interact with arbitrarily chosen cells in the list control either.

In order to explore the problem and attempt to find a solution, I've created my own C++ MFC dialog app which contains a CListCtrl. Strangely, when I run this little throw-away app of mine and explore it with Ranorex Spy, Spy identifies its list control as a "Table", and is able to navigate to every "Column", "Row", and "Cell" within the Table.

Why does Ranorex Spy fail to navigate the real app's list control when it can deal so well with a list control from my throw way code?

[Ciege]

The list items in the AUT that do not get seen by Ranorex... By chance are they off screen? In other words, is there a scroll bar that needs to be used to move the list items into view?
If so, try moving them into view then check and see if they can be recognized by RanorexSpy...

I have a similar issue in my AUT where the tree I use is "lazy loaded". In other words the actual data for the tree is not loaded until it is needed (i.e. until it is scrolled into view). This is an implementation of the AUT controls and not a limitation of Ranorex. To work this issue I had to make sure that I checked for scrollbars when reading the data and made sure I scrolled the tree into view when I am looking for specific data in the tree.

[deepsnow]

With regard to the cells within the list in the AUT, the ones that Ranorex can't see, some of them are in view and some are out of view. (The latter can be brought into view by scrolling.)

As Ranorex can only see the data in left-most column, and not any other column even amongst those that are in view by default, I don't think that's the explanation for what I'm seeing.

Why would Ranorex see one CListCtrl as a "List" (the AUT) and another as a "Tree" (in the throw-away app)?

[Support Team]

Could you post a Ranorex snapshot of the control?
Which Ranorex version do you use?
What is the value of the "Class" attribute of the list view control displayed by Ranorex Spy?

Usually, Ranorex recognizes Win32 and MFC list views (e.g. with classname "SysListView32") as List if the control is in "List mode" and as Table if the control is in "Detail mode". However, there could be problems when the list view or its items are owner-drawn. In that case the control might not react to the standard Win32 messages in the default way and Ranorex might not be able to retrieve data for the cells. (What most owner-drawn list views do is claiming that they are in "List mode" although they actually display rows and columns like in "Detail mode".)

Regards,
Alex
Ranorex Team

[deepsnow]

I've attempted to take a snapshot and upload it, but the snapshot turns out to be about 6 MB no matter what I try, and that's apparently too large to upload.

I'm using Ranorex 2.3.

The Class of the list in question is SysListView32.

In case this is relevant, both the AUT and my throw-away app have the following settings in the properties for their list controls:
Owner Data FALSE
Owner Draw Fixed FALSE
View REPORT

[Support Team]

I've attempted to take a snapshot and upload it, but the snapshot turns out to be about 6 MB no matter what I try, and that's apparently too large to upload.

Just try to compress the snapshot (e.g. using 7-zip) and upload the compressed zip file. The compressed file should only be a few hundred kilobytes in size.

Regards,
Alex
Ranorex Team

[deepsnow]

I'm sorry that I didn't think to zip it myself. I was not thinking very clearly yesterday, but I'm working to improve upon that today.

I've uploaded two files. One the compressed snapshot of the list in question from the AUT. The other is also snapshot from a sister list in the AUT, but this latter list has many fewer rows.

Both lists are seen by Ranorex as "List" rather than "Table", and I can hardly wait to learn why that is.

[Support Team]

Sorry, but the snapshots do not show anything that could bring some light into that issue.

What Ranorex internally does for list views of class "SysListView32" is sending them the LVM_GETVIEW message (see MSDN documentation) and examining the returned value. If the returned value is LV_VIEW_DETAILS, the list is displayed as a table, otherwise as a list.

Can we get access to the list view control that is identified as a list?
Were you able to compile a sample application that is recognized as a list similarly as in your original application?

Regards,
Alex
Ranorex Team

[deepsnow]

I am working to create a sample app that exhibits the same problem as the AUT, but I have not been able to do it so far. I've tried to make the sample app as much like the AUT as possible, but Ranorex still sees the sample app's list as a "Table". I'll keep working on that.

I'm going to experiment with the LVM_GETVIEW message. I've discussed this with one of the AUT's UI programmers, and he thinks we should try writing a handler for the LVM_GETVIEW message within the AUT that would return LV_VIEW_DETAILS. He says we can try to sub-class CListCtrl in order to conduct this experiment.

I'll post again as soon as I've made progress on either of those fronts.

[deepsnow]

I'm still whittling away at this problem. I've discovered that at least one of the CListCtrls in the AUT responds to LVM_GETVIEW with LV_VIEW_ICON. But the CListCtrl is defined to display in LVS_REPORT view, and I haven't yet found any code that changes that setting. So, why is the CListCtrl responding with LV_VIEW_ICON and not LV_VIEW_DETAILS?

As an experiment, I added a new function to the dialog's .cpp file:

LRESULT CALLBACK myWndProc(
HWND hwnd
, UINT uMsg
, WPARAM wparam
, LPARAM lparam)
{
if( uMsg == LVM_GETVIEW )
{
return LV_VIEW_DETAILS;
}
else
{
return ::CallWindowProc(d_oldProc, hwnd, uMsg, wparam, lparam);
}
}

and then I added a new line to the dialog's OnInitDialog() method:

SetWindowLongPtr(m_DefinedSetsList.GetSafeHwnd(), GWLP_WNDPROC, (LONG_PTR) myWndProc);

(where m_DefinedSetsList is the CListCtrl).

This causes the list within the AUT to present as a "Tree" and not as a "List", which allowed Ranorex Spy to properly traverse it for the very first time!!!

However, in order make the CListCtrl in question behave properly on a permanent basis, and other several CListCtrls within the AUT as well, I need to find and fix the underlying problem.

What advice can you give me in order to hunt down the real, underlying cause - the thing that's provoking the AUT's CListCtrls to present with LV_VIEW_ICON?

[praveena]

Hi to all I am working to create a sample app that exhibits the same problem as the AUT, but I have not been able to do it so far. I've tried to make the sample app as much like the AUT as possible, but Ranorex still sees the sample









-----------------------------------------------------------------

plc training in india | plc training in chennai | plc training in chennai | plc training in madurai | plc training chennai | SEO chennai