In Visual Studio 2010, CodedUITest provides partial support to MFC applications. It uses MSAA (Microsoft Active Accessibility) which is a part of Windows Automation API 2.0 to drive the automation on MFC controls. The same plugin also supports Winforms and Win32 applications. Microsoft Active Accessibility helps users to get programmatic access to user interface elements from outside the application. The primary condition for UITest to work on any application is proper accessibility implementation from the application. This blogs discusses in detail what partial support means on MFC Applications.
Since UITest uses Winforms pluggin for MFC also (as both uses MSAA technology), please read the two deep dive blogs that was published on Winforms plugin to know about how this plugin works and how to troubleshoot failures.
UITest framework – Winforms Plugin - Part 1
UITest framework – Winforms Plugin - Part 2
MFC applications uses two sets of controls, basic controls and UI Rich Feature Pack controls.
· Basic controls – It includes the basic controls used for UI.
· VS 2008 Feature Pack– It is the advanced version and shipped with some complex controls e.g., ribbon, property sheet etc.
Basically in 2010 UITest framework supports most of the basic MFC controls and we might generally work. But if the application contains Feature Pack controls then we do not work and it will not be supported.
MFC Basic Controls
VS 2008 Feature Pack controls
Good (No Issues)
Fair (No Major issues)
Poor (Blocking issues)
For MFC basic controls UITest support is good at most of the scenarios except some controls where either the accessibility story is different (Spinbutton) as of Winforms or controls do not respond to windows messages that we use for recording/playback (e.g., month calendar, date picker etc.)
Controls with Poor Rating
· Recorded as raw actions but in Winforms UITest aggregates the date selection. If date changes playback may not work.
· The search is failing for the controls due to its class name being different as of Winforms.
· Get works but not Set
Recorded as raw actions but in Winforms we aggregate the Month selection. If date changes playback may not work.
The control hierarchy for SpinControl is different as of NumericUpDown control, so the control is not recognized as SpinControl. Recorder will record raw actions
Playback fails here as UITest does not recognize it as IPAddressCtrl as it is not present in MFC. Not a high priority control.
Recognizing it as WinControl. We will record raw actions. Not a high priority controls
Not accessible using AccExplorer coming as window –> text. Not a high priority control
Controls with Fair Rating
· In case of HoverSelect if recorder is ON selection of items does not happen on listbox until any item is selected using click but after this recorder is able to record on hovering and play them back.
· Able to work across different view of lists
· List boxes have advanced versions, where just name was not enough for AFN, for example one may want to add a validation on other columns of list which are mapped to description field
· Clicks on List items having checkbox with it are recorded as raw click on list item. if this is followed by a set value the previous action will be eaten up (different behavior from checkedlistbox)
· The list items can have additional support of editing the labels which is not supported by UITest
If the list items do not have any text, let say it is used only to pick a color from a list where UITest records SetValue(Empty). which will pick the first item allways
· Broken on XP and 2K3.
· Nameless buttons are not coming under toolbar they are directly under TLW
In some instances for nameless controls inside tool bar but in action log 'numbered <instance>' is not coming
Broken on 64bit Version
· The checkbox items are coming directly under TLW not under the list box as of Winforms, but using UICL they are under list box
Actions are recorded as click on list items
UITest support for MFC Feature pack controls as a whole is Poor due to the following reasons:
Control level details are not given for Feature Pack controls as majority of them are not supported. If an application is using a feature pack control then Fast Forward or CodedUITest are not supported on it.
The blog post was originally written for VS 2010. For folks who are using VS 2012 and wondering if Coded UI test continues to work with MFC in VS 2012, then the answer is yes. Coded UI test in VS 2012 works for MFC with the same set of limitations as outlined above.