The C++ IAccessible interface offers a handful of methods that allow you to gather information or perform actions on an object. Each of these methods are well documented on MSDN, but it is up to the creator of an object to implement them correctly. In this article, I’ll be talking about a couple of the inconsistencies you may run into when using these methods due to improper implementations and a lack of restrictions on how they should be implemented.

IAccessible::get_accRole

In the documentation for this method, it is clearly stated that it accepts two parameters.  The first is the accessible objects child id.  This variant is either equal to CHILDID_SELF, which defines that you are seeking information about the current object, or the child ID, which will get the role of the defined child.  This parameter should be of variant type VT_I4.  The second parameter is a variant pointer that will return the accessibility role of the object.  In the documentation this is stated as being an object role constant such as ROLE_SYSTEM_WINDOW or ROLE_SYSTEM_CLIENT.  This parameter is where I have run into problems with how get_accRole has been implemented by the creator of the object.

In addition to stating the second parameter should return an object role constant, it also states that the variant type MUST be of type VT_I4.  This does not seem to be enforced though.  I have run into numerous situations (developing in Microsoft Office) where the variant type is VT_BSTR.  A string is considered invalid for this variant and can cause quite a headache when unexpected.  This occurs in a Microsoft product none the less, the creators of MSAA.  This is just one case that I have run into where the value is invalid, and it begs the question, what other variant types might this return?  That is totally up to the developer implemented get_accRole in his object.  The simple solution to this problem is to always check the variant type that is returned before doing any operations on it to avoid errors.

IAccessible::get_accState

After research into the get_accRole method, it came as no surprise the get_accState suffers from the same issues.  As with get_accRole, get_accState takes two parameters.  The first is the child id, and the second is the out variable to hold the state constant.  The documentation for get_accState states that the second argument will return a variant type of VT_I4 that corresponds to one of the object state constants.  Though in using the accState with Microsoft Office and Lotus Notes I have run into times where the state is of variant type VT_BSTR (string).  Again the solution is to always check the variant type that is returned before using it in any operations.

—–

As I continue to dive deeper into the world of MSAA, I’ll keep this blog up to date with the inconsistencies I find.  If you have any that you have come across in working with MSAA tell me about them.  I’ll be glad to look into them to see if there is a workaround or a clean way to handle them.  I’ll leave with you with a code snippet that shows how to get the accRole and compare it with an object role constant.

Compare accessibility role:

//Code below assumes that IAccessible object and ChildID are both passed in parameters.
bool CompareAccRole(IAccessible* pIAccessible, VARIANT childID, LONG objectRoleConstant)
{
	VARIANT accObjectRole;
	HRESULT hr = pIAccessible->get_accRole(childID, &accObjectRole);
	if(hr == S_OK && accObjectRole.vt == VT_I4)
	{
		if(accObjectRole.lVal & objectRoleConstant)
			return true;
	}
	return false;
}

Useful Links:

• IAccessible MSDN Documentation
• IAccessible::get_accRole MSDN Documentation
• Object Role Constants MSDN
• IAccessible::get_accState MSDN Documentation
• Object State Constants MSDN

When I started trying to write automations for Excel 2007 using C++, I ran into problems right up front. I was trying to use #import to get to the type library for Excel 2007, and was importing what I thought was the correct file. The following was written for a C++ application in Visual Studio 2008 (VS2008), automating Excel 2007.

1. The Excel Type Library is not contained in XL5EN32.OLB as you might expect, it is contained in excel.exe
2. Error #2: Even importing the correct file, errors were being raised.

   //The Following Import gives you the error Error	1	error C2504: '_IMsoDispObj' : base class undefined
   #import "C:\Program Files\Microsoft Office\Office12\EXCEL.EXE"
   

   To correctly import the Excel type library, two more references are needed: MSO.DLL and VBE6EXT.OLB

   #import "C:\Program Files\Common Files\Microsoft Shared\OFFICE12\mso.dll" no_implementation raw_interfaces_only
   #import "C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB" no_implementation raw_interfaces_only
   #import "C:\Program Files\Microsoft Office\OFFICE12\excel.exe" no_implementation raw_interfaces_only
   

3. While this solved the problem of the _IMsoDispObj, it raised a few more issues.

   warning C4003: not enough actual parameters for macro 'RGB'
   warning C4003: not enough actual parameters for macro 'DialogBoxW'
   

   Finally I had the solution, renaming the objects in question that seemed to be redefined elsewhere.

   #import "C:\Program Files\Common Files\Microsoft Shared\OFFICE12\MSO.DLL" no_implementation rename("RGB", "ExclRGB") rename("DocumentProperties", "ExclDocumentProperties") rename("SearchPath", "ExclSearchPath")
   #import "C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB" no_implementation
   #import "D:\Program Files\Microsoft Office\OFFICE12\EXCEL.EXE" rename("DialogBox", "ExclDialogBox") rename("RGB", "ExclRGB") rename("CopyFile", "ExclCopyFile") rename("ReplaceText", "ExclReplaceText")
   

So in conclusion, in order to import the Excel 2007 Type Library in C++ and use it in your automations, 3 files must be imported, MSO.DLL, VBE6EXT.OLB, and EXCEL.EXE. On top of those three files, various objects must be renamed due to already being defined. In my case it was the DialogBox and RGB, though it may differ on each project depending on what is defined. Here is the final code needed to import the type library.

#import "C:\Program Files\Common Files\Microsoft Shared\OFFICE12\MSO.DLL" no_implementation rename("RGB", "ExclRGB") rename("DocumentProperties", "ExclDocumentProperties") rename("SearchPath", "ExclSearchPath")
#import "C:\Program Files\Common Files\Microsoft Shared\VBA\VBA6\VBE6EXT.OLB" no_implementation
#import "D:\Program Files\Microsoft Office\OFFICE12\EXCEL.EXE" rename("DialogBox", "ExclDialogBox") rename("RGB", "ExclRGB") rename("CopyFile", "ExclCopyFile") rename("ReplaceText", "ExclReplaceText")

Useful Links:

• Reading a cell from an Excel Worksheet
• Using Excel Type Library in VS 2005

A couple days ago I showed you how to access the Microsoft Word 2007 COM API through Microsoft Active Accessibility (MSAA). Today, I’m going to switch it up just a little bit, and use the same method to access the Microsoft Excel 2007 COM API. Again, we’ll be using AccesssibleObjectFromWindow to get at the main Excel::Window object. From that object, you can obtain the Excel Application, and Excel Workbook objects. Some documentation from Microsoft can be found here.

First we obtain the hwnd of the Microsoft Excel Process:

//The main window in Microsoft Excel has a class name of XLMAIN
HWND excelWindow = FindWindow(L"XLMAIN", NULL);

We can then traverse the child windows until we find the one with classname EXCEL7:

//Use the EnumChildWindows function to iterate through all child windows until we find EXCEL7
EnumChildWindows(excelWindow, (WNDENUMPROC) EnumChildProc, (LPARAM)1);

static BOOL EnumChildProc(HWND hwnd, LPARAM)
{
     WCHAR szClassName[64];
     if(GetClassNameW(hwnd, szClassName, 64))
     {
          if(_wcsicmp(szClassName, L"EXCEL7") == 0)
          {
               //Get AccessibleObject
               Excel::Window* pWindow = NULL;
               HRESULT hr = AccessibleObjectFromWindow(hwnd, OBJID_NATIVEOM, __uuidof(Excel::Window), (void**)&pWindow);
               if(hr == S_OK)
               {
                    //Excel object is now in pWindow pointer, from this you can obtain the document or application
                    Excel::_Application* pApp = NULL;
                    pWindow->get_Application(&pApp);
                    pWindow->Release();
               }
               return false;     // Stops enumerating through children
          }
     }
     return true;
}

Next we obtain our Excel::Window object through AccessibleObjectFromWindow:

//Get AccessibleObject
Excel::Window* pWindow = NULL;
HRESULT hr = AccessibleObjectFromWindow(hwnd, OBJID_NATIVEOM, __uuidof(Excel::Window), (void**)&pWindow);

That’s it! We now have our Excel::Window COM Object. From this object we can obtain the Excel::Application and Excel::Workbook objects, allowing us full interaction with the active document. So with just a few lines of code, we now have access to automate an Excel 2007 document.

Full source code:

#include <windows.h>
#include <oleacc.h>
#include "msexcel.h"

static BOOL EnumChildProc(HWND hwnd, LPARAM)
{
     WCHAR szClassName[64];
     if(GetClassNameW(hwnd, szClassName, 64))
     {
          if(_wcsicmp(szClassName, L"EXCEL7") == 0)
          {
               //Get AccessibleObject
               Excel::Window* pWindow = NULL;
               HRESULT hr = AccessibleObjectFromWindow(hwnd, OBJID_NATIVEOM, __uuidof(Excel::Window), (void**)&pWindow);
               if(hr == S_OK)
               {
                    //Excel object is now in pWindow pointer, from this you can obtain the document or application
                    Excel::_Application* pApp = NULL;
                    pWindow->get_Application(&pApp);
                    pWindow->Release();
               }
               return false;     // Stops enumerating through children
          }
     }
	 return true;
}
int main( int argc, CHAR* argv[])
{
     //The main window in Microsoft Excel has a class name of XLMAIN
     HWND excelWindow = FindWindow(L"XLMAIN", NULL);

     //Use the EnumChildWindows function to iterate through all child windows until we find _WwG
     EnumChildWindows(excelWindow, (WNDENUMPROC) EnumChildProc, (LPARAM)1);

     return 0;
}

Useful Links for this post:

• AccessibleObjectFromWindow Documentation
• Using Visual C++ to Automate Office
• EnumChildWindows Documentation

Key phrases: Accessing Excel 2007 COM object using AccessibleObjectFromWindow, Automating Excel 2007 with Microsoft Active Accessibility MSAA
Update: I’ve updated the full source to utilize get_Application. get_Document was in place previously, which was leftover from my Word source code.

Over the next few months, I will be interacting with Microsoft Access, Word, and Excel 2007 through Microsoft Active Accessibility (MSAA) in C++. As my journey progresses, I will be posting the neat little tricks and painful quirks that I run into along the way. To start, here are a few resources you can use to read up on Microsoft Active Accessibility.

• Microsoft’s documentation on IAccessible interface
• Sara Ford’s Weblog on Accessibility
• User Interface Element References for Control in Accessibility

Over the past 6 months, I used MSAA to develop against Microsoft Access 2003.  Although it was a painful process to get working, the end result gives quite a bit of flexibility in automating Access.  That being said, there are still a lot of hurdles to overcome, and Accessibility has definitely left many things to be desired.  In the next few weeks I will be posting about my first impressions of Accessibility and it’s inconsistencies.