CODEWITHSUNDEEP
c++mfcsquish
jpou
jpou

Reputation: 1995

MFC Resource ID and Squish

I'm trying to automate some GUI testing with Squish and keep getting problems with MFC resource IDs in Squish.

I create a static label like this:

CStatic m_Status;
m_Status.Create("", WS_CHILD | WS_VISIBLE | SS_CENTERIMAGE | SS_LEFT, 
                mCfg->rectStatus(), this, 42);
m_Status.SetWindowText("42 is the answer");

When I spy this label with Squish, all I get is:

{"container": o_Pane, "text": "42 is the answer", "type": "Label"}

however, there's no ID. As the text is changing, matching element based on the text alone is not optimal.

In the same program other labels are created via the resource manager wizard. For those labels Squish is able to get both the resource ID and set the correct "nativeObject" property.

Is there some way to make CStatic objects created in the source code also properly visible to the Squish, with the nativeObject property if possible?

Upvotes: 2

Views: 294

Answers (2)

Stephen C. Steel
Stephen C. Steel

Reputation: 4430

Squish will match Windows control IDs to the "id" property in real names if you include them. So replacing the real name in your example with

{"container": o_Pane, "id": 42, "type": "Label"}

should work.

By default, Squish doesn't automatically include Windows control IDs when generating real names in the Squish GUI. However, it is possible to edit the XML descriptor files (stored in the etc subdirectory where Squish for Windows is installed) to tell Squish to include the control ID when generating real names for specific Windows control types. For instance changing this entry in the windowswrapper_descriptors.xml file from

<descriptor>
    <type name="Label"/>
    <realidentifiers>
        <property>text</property>
    </realidentifiers>
</descriptor>

to

<descriptor>
    <type name="Label"/>
    <realidentifiers>
        <property>text</property>
        <property>id</property>
    </realidentifiers>
</descriptor>

will add the Windows control ID to the real name generated for label controls.

This is particularly useful for MFC applications, since the control IDs are generally quite stable, but it might be less useful for other types of windows apps (which may be why control IDs are not used by default). The documentation file https://doc.qt.io/squish/object-name-generation.html explains the XML descriptor file syntax and gives more details about how to do this.

Note: I've used this technique with Squish v7.2.1, but I don't know far back this support exists, since I've only used this version of Squish.

Upvotes: 0

frog.ca
frog.ca

Reputation: 732

Spying can be used for inspecting the object properties. Once you know which properties Squish sees, you can use the properties and their values in Squish object real names for identifying the desired object.

However, since the MFC support of Squish is not compiled in, it typically has no way to access such IDs, since it gets all its information about MFC controls via Window Messaging.

It might be that these IDs are exposed via UI Automation. Check with Inspect if that is the case. And if so, try identifying the object via Squish' UI Automation support. For this change the priority in SQUISH_DIR\lib\extensions\win\uiautomation.ext to be higher than the priority in SQUISH_DIR\lib\extensions\win\mfc.ext, use a new test suite (for good measure and testing), launch the AUT from Squish, pick the object and see if you see different object properties, and if the nativeObject properties is non-null (being empty/null implies that the MFC supports is providing access to the object).

Upvotes: 1

Related Questions