Soledad Pano's Blog

How to find Visual Studio command bars

spano — Tue, 07 Oct 2008 14:07:00 GMT

When developing a Visual Studio Addin it is a common task to add custom commands to existing menus and toolbars. It is a common problem too, not to find the proper command bar (we have to traverse all command bars to see its names, the names are not unique, etc). In these two posts: Using IVsProfferCommands to retrieve a Visual Studio CommandBar and Using EnableVSIPLogging to identify menus and commands with VS 2005 + SP1 it is very well explained how to solve this problem.

The answer relies on the fact that every toolbar and menu is uniquely identified in Visual Studio by a GUID,Id pair. In order to see which is the GUID, Id pair for a given command, you must:

Add or change the registry key HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\General\EnableVSIPLogging to 1.

Click on the toolbar or menu you want identify while keeping CTRL+SHIFT pressed. This will show a dialog with the command bar properties. Take note of the Guid and the CmdID:

From the Addin, use the following code to add your command in the desired command bar:

private void AddMyCustomCommand()

{

    …

    object[] contextGuids = new object[0];

    myCommand = ((Commands2)this._applicationObject.Commands).AddNamedCommand2(this._addInInstance,

             partialCommandName,displayName, tooltip, true, null, ref contextGuids,

            (int)vsCommandStatus.vsCommandStatusSupported + (int)vsCommandStatus.vsCommandStatusEnabled,

            (int)vsCommandStyle.vsCommandStyleText,vsCommandControlType.vsCommandControlTypeButton);

    CommandBar ownerBar = FindCommandBar(new Guid("{9AEB9524-82C6-40B9-9285-8D85D3DBD4C4}"), 1280);

    myControl = workflowCommand.AddControl(ownerBar, 1) as CommandBarButton;

}

private CommandBar FindCommandBar(Guid guidCmdGroup, uint menuID)

{

   // Retrieve IVsProfferComands via DTE's IOleServiceProvider interface

   IOleServiceProvider sp = (IOleServiceProvider)_applicationObject;

   Guid guidSvc = typeof(IVsProfferCommands).GUID;

   Object objService;

   sp.QueryService(ref guidSvc, ref guidSvc, out objService);

   IVsProfferCommands vsProfferCmds = (IVsProfferCommands)objService;

   return vsProfferCmds.FindCommandBar(IntPtr.Zero, ref guidCmdGroup, menuID) as CommandBar;

}

[ComImport,Guid("6D5140C1-7436-11CE-8034-00AA006009FA"),

InterfaceTypeAttribute(ComInterfaceType.InterfaceIsIUnknown)]

internal interface IOleServiceProvider

{

    [PreserveSig]

    int QueryService([In]ref Guid guidService, [In]ref Guid riid,

       [MarshalAs(UnmanagedType.Interface)] out System.Object obj);

}

CodeCamp Buenos Aires 2008

spano — Sun, 05 Oct 2008 14:13:18 GMT

I attended yesterday to the Microsoft Code Camp event at Buenos Aires. It was fun!

Here's a picture of the Lagash stand:

UI Automation Article Published on Level Extreme

spano — Wed, 12 Mar 2008 17:38:00 GMT

On this month's edition of the Level Extreme .Net Magazine, my article about Building an UI Automation Client Application was published. The article walks through building a client application for automating a win 32 target application (the Windows Address Book). The idea is to show through simple code snippets how to use the UI Automation API for manipulating a target application programmatically through its UI. It shows how to find the UI elements, and how to work with the UI Automation patterns and handle events. The sample client application code contains further examples and can be downloaded from the article's page. Hope you read it!

Read more on the magazine from Martin Salias.

CCF: Listening to External Application Events

spano — Tue, 15 Jan 2008 15:05:00 GMT

It is often necessary to listen to external application UI events when automating applications in CCF. For example, we may need to save a value in the Context if the user presses a button, or do something when an alert dialog appears. There are many ways we can handle events. In CCF 2008, the Hosted Application Toolkit (HAT) provides an easy way to listen to them. If not using HAT we can hook to events using the UIAutomation or MSAA (Microsoft Active Accessibility) APIs within our own application adapters.

Events in HAT

When we configure a hosted application for using an Automation Adapter, this adapter listens to the application events. We can hook and unhook to these events using the CCF's WF activities RegisterActionForEvent (see figure bellow) and UnregisterActionForEvent respectively.

It is the Data Driven Adapter (DDA) the one who throws the ControlChanged event (to which the activity subscribes). The arguments of the event consists of eventTypeName, controlName and controlValue.

For example, the WinDataDrivenAdapter that CCF provides supports the following event types:

SetControlValue: When the DDA set's a control's value.
ExecuteControlAction: When the DDA executes a control.
ContextChanged: When the context changes.
MenuShown: When a menu is shown
WindowShown: When a window is shown
WindowDisappeared: When a window is closed
LostFocus
SetFocus
CheckBoxSet
CheckBoxCleared
RadioButtonSet
RadioButtonCleared
ButtonPressed
ButtonReleased

There are some tricks about how to use this events, for example:

4-6: For menu and window events we must not register with the control's friendly name that we set in the databindings section of the AppInitString. We must specify the window or menu's caption instead.
7-14: For these events the related control must be previously found on the UI. You can use the FindControl activity to ensure that the control is successfully found. When the DDA finds the control it registers it in a KnownControls collection. Only for those registered controls the events are thrown.

Custom DDAs or Legacy Adapters

If we need to handle events from a custom DDA or from a legacy adapter we can use win32 or accessibility APIs. If we use a custom DDA we can throw a ControlChanged event in order to use the WF/Automation activities mentioned before.

WinEvents

A low level approach is to use the SetWinEventHook and UnhookWinEvent functions from user32.dll. When we hook for events we specify the callback function that will handle the events. You can see the list of supported events and its constants in the MSAA SDK documentation on msdn.

In order to show some sample code, here are the user32 functions imports:

[Flags]

internal enum SetWinEventHookFlags

{

WINEVENT_INCONTEXT = 4,

WINEVENT_OUTOFCONTEXT = 0,

WINEVENT_SKIPOWNPROCESS = 2,

WINEVENT_SKIPOWNTHREAD = 1

}

internal delegate void WinEventProc(IntPtr hWinEventHook, int iEvent, IntPtr hWnd, int idObject, int idChild, int dwEventThread, int dwmsEventTime);
[DllImport("user32.dll", SetLastError = true)]
internal static extern IntPtr SetWinEventHook(int eventMin, int eventMax, IntPtr hmodWinEventProc, WinEventProc lpfnWinEventProc, int idProcess, int idThread, SetWinEventHookFlags dwflags);
[DllImport("user32.dll", SetLastError = true)]
internal static extern int UnhookWinEvent(IntPtr hWinEventHook);

Here's how we can subscribe to win events from our custom adapter:

WinEventProc wep = new WinEventProc(this.EventCallback);

SetWinEventHook(1, 0x7fffffff, IntPtr.Zero, wep, 0, threadId, SetWinEventHookFlags.WINEVENT_OUTOFCONTEXT);

And finally how to react to events in the event handler method:

private void EventCallback(IntPtr hWinEventHook, int iEvent, IntPtr hWnd, int idObject, int idChild, int dwEventThread, int dwmsEventTime)

{

//get accObj from handler

//get accObj's name, role, etc...

...

switch (iEvent)

{

case 0x10: //EVENT_SYSTEM_DIALOGSTART

if (role.Equals(localize.ACC_ROLE_TEXT_WINDOW))

{

if (name.Length > 0)

{

//throw ControlChangedEvent

this.ControlChanged(accObj, new ControlChangedEventArgs("DialogStart", controlName, string.Empty));

}

break;

...

}

UIAutomation

Another option is to use the UIAutomation accessibility API, included on .Net framework 3.0 to hook to events from custom adapters. The Automation element provides the following static methods to hook to different event on different controls:

//Registers a method that handles UI Automation events.

public static void AddAutomationEventHandler(AutomationEvent eventId, AutomationElement element, TreeScope scope, AutomationEventHandler eventHandler);

//Registers a method that will handle focus-changed events.

public static void AddAutomationFocusChangedEventHandler(AutomationFocusChangedEventHandler eventHandler);

//Registers a method that will handle property-changed events.

public static void AddAutomationPropertyChangedEventHandler(AutomationElement element, TreeScope scope, AutomationPropertyChangedEventHandler eventHandler, params AutomationProperty[] properties);

//Registers the method that will handle structure-changed events.

public static void AddStructureChangedEventHandler(AutomationElement element, TreeScope scope, StructureChangedEventHandler eventHandler);

The UIAutomation API is much more friendly to use, but some times it takes too long for the event to reach the handler. You should be very precise when setting the element and scope to subscribe the event to. You can find more information about this API and sample code on my previous post about WPF Accessibility.

Hosting a Window Form Control in a SharePoint WebPart

spano — Fri, 07 Dec 2007 01:48:00 GMT

Some months ago I posted about Hosting a Windows Form Control in a web page. I explained there how we can run a WinForm control from Internet Explorer by hosting it in a web page using the <object> tag. Now suppose you want to use the same solution in a custom web part that is included in a Sharepoint site. I will describe here where the control library should be placed and how it can be referenced from the web part.

When we develop a custom web part, we place its resources under the _wpresources web site, into a folder named <WebPartAssemblyName>/<WebPartAssemblyVersion>__<PublicKeyToken>. You can create there a subfolder (named "bin" por example) to place the win control assembly. This folder must have execute permissions set to Script Only (not Script and Executables as is the default under a SharePoint site). The picture bellow shows the resulting structure when placing the win form control assembly in a web part called MyCustomWebPart that is part of the MyCustomWebParts assembly:

Once the control assembly is placed in the correct place, the web part can render the <object> tag within the RenderWebPart method:

namespace MyCustomWebParts
{
  [XmlRoot(Namespace = "MyCustomWebParts")]
  public class MyCustomWebPart : WebPart
  {

protected override void RenderWebPart(HtmlTextWriter output)

{

EnsureChildControls();

string resourcePath = SPWebPartManager.GetClassResourcePath(SPContext.Current.Web, GetType());

output.Write( ReplaceTokens("<h1>Windows Form Control:</h1>" +

"<object id='MyWinControl' classid='" + resourcePath +

"/bin/WindowsControlLibrary1.dll#WindowsControlLibrary1.UserControl1'" +

"height='300' width='800' VIEWASTEXT>" +

" <PARAM name='Prop1Str' value='blabla' valuetype='data'>" +

" <PARAM name='Prop2Int' value='2' valuetype='data'>" +

" </object>"));

base.RenderWebPart(output);

}

CCF HAT - Making use of DDAs from Legacy Adapters

spano — Wed, 31 Oct 2007 01:34:00 GMT

Although Data Driven Adapters (DDAs) are mainly designed for Automation Adapters in HAT, we can make use of them from legacy adapters, too. Here's an example of an external VB application, which is configured to use a legacy application adapter and a WinDataDrivenAdapter with the corresponding bindings:

<?xml version="1.0" encoding="utf-16"?>

<URL>C:\MyApp.exe</URL>

</interopAssembly>

<UseTopLevelWindow class="ThunderRT6Form" />

<URL>C:\MyApplicationAdapters.dll</URL>

<type>Microsoft.Ccf.QuickStarts.MyExtVBAppAdapter</type>

</adapter>

<Type>Microsoft.Ccf.HostedApplicationToolkit.DataDrivenAdapter.WinDataDrivenAdapter,

Microsoft.Ccf.HostedApplicationToolkit.DataDrivenAdapter</Type>

<Path>

</Path>

</AccControl>

</Controls>

</DataDrivenAdapterBindings>

</initstring>

One thing to take into account is that, if the application uses an alternative top level window, the DDA must be instantiated with that top level window instead of the process MainWindowHandle. The picture shows how the alternate top level window configuration is seen in the Admin Console:

And here is the code of the legacy adapter making use of the data driven adapter to automate the hosted application's UI:

using System;
using Microsoft.Ccf.Csr;
using Microsoft.Ccf.HostedApplicationToolkit.DataDrivenAdapter;
namespace Microsoft.Ccf.BancoGalicia.ApplicationAdapters
{
    public class MyExtVBAppAdapter : ApplicationAdapter
    {
        protected DataDrivenAdapterBase _dda;
        public override bool Initialize()
        {
            //IntPtr topLevelWnd = Process.MainWindowHandle;//this won't work for a VB app 
            IntPtr topLevelWnd = GetTopLevelWndHandle();
            //Initialize Data Driven Adapter with proper top level window handle
            _dda = DataDrivenAdapterBase.CreateInstance(ApplicationInitString, topLevelWnd);
            return _dda != null;
        }
        public override bool DoAction(Action action, RequestActionEventArgs args)
        {
            switch (args.Action)
            {
                case "DefaultAction":
                    break;
                case "PressButton":
                    PressButton();
                    break;
            }
            return base.DoAction(action, args);
        }
        private void PressButton()
        {
            if (_dda.FindControl("button1"))
            {
                _dda.ExecuteControlAction("button1");
            }
        }
        //Find the top level window of the VB application (for example of class "ThunderRT6Form")
        private IntPtr GetTopLevelWndHandle()
        {
            IntPtr agentDesktopPtr = Win32API.FindWindow(null, "Agent Desktio");
            if (agentDesktopPtr != IntPtr.Zero)
            {
                IntPtr tabWindowHandle = Win32API.FindWindowByText(agentDesktopPtr, "MyApp");
                if (tabWindowHandle != IntPtr.Zero)
                {
                    return Win32API.FindWindowByText(tabWindowHandle, "MyAppTopLevelWndCaption");
                }
            }
            return IntPtr.Zero;
        }
    }
}  

CCF 2008 Hosted Application Toolkit

spano — Fri, 26 Oct 2007 03:40:00 GMT

The Hosted Application Toolkit (HAT) is a new component of CCF 2.6 (2008) that facilitates the task of automating the UI of the hosted applications. It consists of two main parts: the Data Driven Adapters (DDA) and the Automations (WF workflows) that automates the hosted application using the DDAs.

Data Driven Adapters

DDAs must inherit from DataDrivenAdapterBase in Microsoft.Ccf.HostedApplicationToolkit. CCF supports two implementations out of the box: WinDataDrivenAdapter and WebDataDrivenAdapter. We can inherit from any of the three to extend the DDA as necessary. The methods the DDAs expose to manipulate the hosted application UI are ExecuteControlAction, FindControl, GetControlValue and SetControlValue. These methods take a friendly name as parameter and lets the application adapters interact with the hosted application UI abstracting from the details of how to obtain the control from that friendly name. The mapping between the controls' friendly names and the directions for the DDA to finding them is called Data Driven Adapter Binding and is part of the hosted app initialization string:

<DataDrivenAdapterBindings>
    <Type>Microsoft.Ccf.HostedApplicationToolkit.DataDrivenAdapter.WinDataDrivenAdapter</Type>
    <Controls>
        <AccControl name="okButton">
            <Path>
                <FindWindow>
                    <ControlID>15</ControlID>
                </FindWindow>
            </Path>
        </AccControl>
        <AccControl name="cancelButton">
            <Path>
                <FindWindow>
                    <ControlID>15</ControlID>
                </FindWindow>
            </Path>
        </AccControl>
    </Controls>
</DataDrivenAdapterBindings>

Note: It is a known issue that the initialization string of a hosted application is limited to 3902 characters. This may result a problem if several controls must be listed.

Although DDAs can be used from any custom adapter (and even outside CCF), they were mainly thought to support Automations in HAT.

Automations

In previous versions of CCF we could choose to use an Application Adapter to implement the actions' logic. In version 2.6 we can choose between Automation Adapter, Legacy Adapter, or no adapter at all. The Legacy Adapter is the Application Adapter from the previous versions. We can implement our own Legacy Adapter inheriting from the [Web]ApplicationAdapter class. The Automation Adapter is the adapter that makes use of the new Workflow Foundation (WF) feature. The AutomationAdapter implements the IAutomationAdapter interface. However, if we choose AutomationAdapter in the hosted app configuration in the AdminConsole, we can't choose our own implementation of IAutomationAdapter.

If a hosted application is configured to use the AutomationAdapter, we can specify a WF workflow to implement an action's logic. Workflows in HAT are called Automations.

In order to orchestrate an action automation, a set of WF Activities are provided by CCF that interact with the DDAs to access the UI controls. There are activities for calling an action in a hosted application, setting or getting a control's value, accessing the context, register for an application event, etc.

All together

The connection between the Automations and the DDAs is achieved by the AutomationBridgeService, which is in turn connected to the AutomationAdapter. As the bridge service is added to the WF runtime, it is accessible from the CCF WF activities. We can extend the set of activities and make use of this server, too.

The following diagram depicts the relationship between the components mentioned above:

More detailed documentation can be found in chapter 9 of the CCF 2008 Development Guide.

Silverlight article published this month

spano — Mon, 08 Oct 2007 02:23:00 GMT

My colleagues Ariel Neisen, Federico García, Rodolfo Finochietti and I wrote the cover article of the #42 edition of the .Code Magazine (in Spanish) about Silverlight. The article talks about this new technology's fundamentals, architecture, programming tools, advanced features, code samples and a lot more.

Choosing the right WCF binding

spano — Tue, 02 Oct 2007 02:43:00 GMT

A WCF binding is the endpoint component that defines how the client needs to communicate with the service. It groups settings such as underlying transport protocol, security requirements, and message encoding.

WCF provides nine built-in bindings:

BasicHttpBinding: Basic web service communication. Exposes WCF services as legacy ASMX web services. Used for interoperability. No security by default.
WSHttpBinding: Web services with WS-* support. Supports transactions and reliable messaging.
WSDualHttpBinding: Web services with duplex contract and transaction support.
WSFederationHttpBinding: Web services with federated security. Supports transactions.
MsmqIntegrationBinding: Communication directly with MSMQ applications. Supports transactions.
NetMsmqBinding: Communication between WCF applications by using queuing. Supports transactions.
NetNamedPipeBinding: Communication between WCF applications on same computer. Supports duplex contracts and transactions.
NetPeerTcpBinding: Communication between computers across peer-to-peer services. Supports duplex contracts.
NetTcpBinding: Communication between WCF applications across computers. Supports duplex contracts and transactions.

Although most bindings will work on scenarios they are not designed for, it's a good practice to choose the right binding for a given endpoint. In chapter one of the "Programming WCF Services" book, Juval Lowy provides a very useful decision-activity diagram for choosing the right binding:

"The first question you should ask yourself is whether your service needs to interact with non-WCF clients. If the answer is yes, and if the client is a legacy MSMQ client, choose the MsmqIntegrationBinding that enables your service to interoperate over MSMQ with such a client. If you need to interoperate with a non-WCF client and that client expects basic web service protocol (ASMX web services), choose the BasicHttpBinding, which exposes your WCF service to the outside world as if it were an ASMX web service (that is, a WSI-basic profile). The downside is that you cannot take advantage of most of the modern WS-* protocols. However, if the non-WCF client can understand these standards, choose one of the WS bindings, such as WSHttpBinding, WSFederationHttpBinding, or WSDualHttpBinding. If you can assume that the client is a WCF client, yet it requires offline or disconnected interaction, choose the NetMsmqBinding that uses MSMQ for transporting the messages. If the client requires connected communication, but could be calling across machine boundaries, choose the NetTcpBinding that communicates over TCP. If the client is on the same machine as the service, choose the NetNamedPipeBinding that uses named pipes to maximize performance. You may fine-tune binding selections based on additional criteria such as the need for callbacks (WSDualHttpBinding) or federated security (WSFederationHttpBinding)."

You can download the book's sample chapter to read more on this subject. You would also find the diagram in Juval's article WCF Essentials - A Developer's Primer on the CoDe Magazine.

CCF 2008 New Features

spano — Fri, 28 Sep 2007 17:00:00 GMT

The 3.0 version of the Customer Care Framework (CCF) is out! Among its new features we'll find:

CCF web services migrated to Windows Communication Foundation (WCF).
Agent Desktop use of Composite Application Block (CAB).
Hosted Application Toolkit (HAT): new sub-system for providing UI automation, that makes use of Workflow Foundation (WF) and Active Accessibility.
ClickOnce support.
Dynamic Applications: 3rd category of hosted applications that allow an agent to dynamically launch or close a hosted application on-demand, via the UI or programmatically in code.

I found the HAT to be the most interesting feature, allowing to decouple accessibility implementation details from automation logic and making use of WF to represent this automation logic in a friendly, declarative way. I guess I will be posting more on this subject later.

Hosting a Windows Form Control in a web page

spano — Wed, 19 Sep 2007 17:56:00 GMT

Although it is not the most common use of it, it is possible to host a Windows Form Control in a Web Page and run it from within Internet Explorer. This allows to build powerful client side functionality with all the advantages of using the .Net framework and executing the control in the client side. Of course there are some restrictions that cannot be left aside. At least the .Net framework must be installed on the client for the control to run. In addition, it is possible that some permission must be granted to the control, too, depending on the actions the control will take on the client machine.

Let’s build an example to see how this works:

1. Create the Windows Form Control

Create a “Windows Control Library” project in Visual Studio. For this simple example we will add a label to the control and a public “SendMessage” method to change the label’s text. In order to be able to call the method from IE, we will set the control’s COMVisible attribute to true.

using System;

using System.Windows.Forms;

using System.Runtime.InteropServices;

namespace WindowsControlLibrary1

{

[ComVisible(true)]

public partial class UserControl1 : UserControl

{

public UserControl1()

{

InitializeComponent();

}

public void SendMessage(string msg){

_lblMessage.Text = msg;

}

2. Create the hosting HTML document

The control will be hosted using the HTML <object> element. In its classid attribute we will place the control's reference in the following manner: classid="http:[relativePath/]<winControlAssemblyName>.dll#<ControlNamespace>.<ControlClassName>". For this example we will have an HTML page (index.html) with the following code:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" >    

 <head>        

  <title>Windows Form Control Test Page</title>        

  <script type="text/javascript">            

    function SendMessageToWinControl() 

{

     var winCtrl = document.getElementById("MyWinControl");                    

     winCtrl.SendMessage("Message sent from the HTML page!!");                

}

  </script>    

 </head>    

 <body>        

  <h1>Windows Form Control:</h1>        

  <object id="MyWinControl" classid="http:WindowsControlLibrary1.dll#WindowsControlLibrary1.UserControl1"            

          height="100" width="300" VIEWASTEXT/>        

  <br/><br/>        

  <input type="button" onclick="SendMessageToWinControl()" value="Send Message" />    

 </body>

</html>  

3. Deploy the sample

Copy both the index.html page and the control library WindowControlLibrary1.dll to a directory (we will name it WinControlTest). In the “Web Sharing” dir properties select Share this folder, leave the default alias and application permissions to Scripts and make sure not to select the Execute permission).

4. Try it in Internet Explorer

Open the page http://localhost/WinControlTest/index.html in Internet Explorer. We can see the control hosted in the html page:

By clicking the Send Message button, we will call the Control's SendMessage method from javscript. Resulting in the label's text changed:

If you modify the control after its first use, you will need to close IE, replace the control's dll in the virtual directory and clean the contents of the download cache. You do this cleaning using the following command: "gacutil /cdl".To list the contents of the download cache use "gacutil /ldl".

This solution is not intended to replace a WebControl or any common web artifact. But is good to know it can be use in an uncommon scenario if needed.

Sole

WPF Accessibility

spano — Fri, 07 Sep 2007 15:55:00 GMT

Windows Presentation Foundation (WPF) provides a very interesting API for Accessibility called Microsoft UI Automation. It allows programmatic access to most user interface elements on the desktop, addressing the needs of assistive technology products and also for User Interface (UI) tests automation.

The framework provides solutions for both accessibility providers and clients, and it is conformed of four main components (see UI Automation Overview):

The Provider API (UIAutomationProvider.dll and UIAutomationTypes.dll) defines a set of interfaces that are implemented by UI Automation providers, objects that provide information about UI elements and respond to programmatic input.
The Client API (UIAutomationClient.dll and UIAutomationTypes.dll) is a set of types for managed code that enables UI Automation client applications to obtain information about the UI and to send input to controls.
The UI Automation Core (UiAutomationCore.dll) has the underlying code that handles communication between providers and clients.
The UIAutomationClientsideProviders.dll that has a set of UI Automation providers for standard legacy controls. (WPF controls have native support for UI Automation.) This support is automatically available to client applications.

We will typically use the Provider API to create support for our WPF custom controls, since they don't provide accessibility support by default. We will use the Client API for creating applications that need to communicate with UI elements and eventually automate the use of other program's UI.

You can find good documentation in the WPF Accessibility section on MSDN, and several code samples in the SDK Sample Applications.

Just to mention, Microsoft’s earlier solution for Accessibility was Active Accessibility. The main advantage of UI Automation over Active Accessibility is the technology in which it is based on (managed code vs COM) and, as a consequence, the programming languages that can be used. You can read more of the differences in UI Automation and Microsoft Active Accessibility.

A few words about the API's Object Model: Every piece of UI, such as a window, a button, etc, is represented by the AutomationElement class in the System.Windows.Automation namespace of the UIAutomationClient assembly. An AutomationElement corresponds to a piece of UI regardless of the underlying implementation (WPF or Win32). All automation elements are part of a tree, in which the root element is the Desktop. Through the AutomationElement.RootElement static property you can obtain a reference to the Desktop and find any child piece of UI from there to access.

AutomationElements expose Control Patterns that provide properties specific to their Control Types (window, button, checkbox, etc). Control Patterns also expose methods that enable clients to get further information about the element and to provide input. We are going to see how this works in the examples below.

A very useful tool for finding the element's properties in the tree is UISpy, which comes with the Windows SDK. It lets you see all the UI tree and each element's properties. In the Focus Tracking mode, you can select the real UI element in the Desktop and UISpy will automatically show its properties in the tree view.

Code sample

This is an example of a client application for automating a win32 application (in this case the Windows Address Book). For this example, we only need a Windows Console Application and references to the UIAutomationClient and UIAutomationTypes assemblies. From the code it can be seen how to match a control to a given pattern depending on what we want to do with the control.

The controls' names and/or ids where obtained using UISpy.

These are the UI artifacts that we want to automate:

And here is the code to:

- Get a reference to the Address Book application main window:

using System.Windows.Automation;

...

AutomationElement mainWindow = FindWindowByName(AutomationElement.RootElement, "Address Book - Main Identity");

...

private static AutomationElement FindWindowByName(AutomationElement rootElement, string name)

{

PropertyCondition nameCondition = new PropertyCondition(AutomationElement.NameProperty, name);

PropertyCondition typeCondition = new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Window);

AndCondition andCondition = new AndCondition(nameCondition,typeCondition);

return rootElement.FindFirst(TreeScope.Element | TreeScope.Descendants, andCondition);

}

- Press the Find People button:

AutomationElement findPeopleButton = FindElementById(mainWindow, "Item 8084");

if (findPeopleButton != null)

{

InvokePattern invPattern = findPeopleButton.GetCurrentPattern(InvokePattern.Pattern) as InvokePattern;

if (invPattern != null)

{

invPattern.Invoke();

}

...

private static AutomationElement FindElementById(AutomationElement parentElement, string automationID)

{

PropertyCondition propertyCondition = new PropertyCondition( AutomationElement.AutomationIdProperty, automationID);

return parentElement.FindFirst(TreeScope.Element | TreeScope.Descendants, propertyCondition);

}

- Attach to the Find People dialog Closed event:

AutomationElement dialog = FindWindowByName(AutomationElement.RootElement, "Find People");

if (dialog != null)

{

Automation.AddAutomationEventHandler(WindowPattern.WindowClosedEvent, dialog, TreeScope.Element,

dialogEventHandler = new AutomationEventHandler(OnWindowClosedEvent));

}

...

private static void OnWindowClosedEvent(object src, AutomationEventArgs e)

{

Console.WriteLine("On window closed event");

}

- Attach to the Dialog's Close Button Clicked event:

AutomationElement closeButton = FindElementById(dialog, "68");

if (closeButton != null)

{

Automation.AddAutomationEventHandler(InvokePattern.InvokedEvent,closeButton, TreeScope.Element,

clickedEventHandler = new AutomationEventHandler(OnCloseButtonClickedEvent));

}

...

private static void OnCloseButtonClickedEvent(object src, AutomationEventArgs e)

{

Console.WriteLine("On button clicked event");

}

- Get and set the value of the Name text box of the Find People dialog:

AutomationElement text = FindElementById(mainWindow, "1152"); //Automation Id = 1152 of Name text box find with UISpy

if (text != null)

{

//get content

TextPattern txtPattern = text.GetCurrentPattern(TextPattern.Pattern) as TextPattern;

if (txtPattern != null)

{

string content = txtPattern.DocumentRange.GetText(-1);

Console.Out.WriteLine(content);

}

//write content

ValuePattern valuePattern = text.GetCurrentPattern(ValuePattern.Pattern) as ValuePattern;

valuePattern.SetValue("new value");

}

- Set a combo box value:

AutomationElement combo = FindElementById(dialog, "99");

if (combo != null)

{

AutomationElement item = FindListItemByName(combo,"Active Directory");

SelectionItemPattern itemPattern = item.GetCurrentPattern(SelectionItemPattern.Pattern) as SelectionItemPattern;

itemPattern.Select();

}

Well...that's it. I hope this helps for a start. Enjoy!

Sole

New @ weblogs

spano — Fri, 07 Sep 2007 15:33:00 GMT

HI! this is my first post @ weblogs.asp.net. I'm moving from http://solepano.blogspot.com, where I've been blogging since last year. I would like to introduce myself with a few words: My name is Soledad Pano, I live in Buenos Aires - Argentina, have a degree in Electronic Engineer from the University of Buenos Aires, and work as a software consultant at Lagash Systems. I’ve been working with the .Net technology for the last four years, and the purpose of this blog is to share thoughts, news, code samples, etc, about several .Net technologies and products. I'm also interested in more general topics, such as software quality, metrics, testing, agile, technical tools, etc. You are totally welcome to contribute with any comments, questions, answers, suggestions, whatever. I will really appreciate your participation. Have fun!

Sole

Working around VSTO SE's lack of document-customization for Excel 2007

spano — Sun, 10 Jun 2007 22:42:00 GMT

This post was originally published at http://solepano.blogspot.com

I've been doing some research on Visual Studio Tools for Office (VSTO) and Excel 2007 recently and found out that some very interesting features available in previous versions of VSTO for Excel 2003 are not available for Excel 2007. Here's a summary of the current situation and the workarounds I figured out.

State of the Art

VSTO has basically two kinds of Excel add-ins: document-level customization an application-level add-ins.

The document-level customization lets you customize an Excel workbook and also reference the Application to add buttons to the command bar and so forth. The resulting add-in will be only available to the customized workbook. The great benefit of document-level customization is that you can add controls to the spreadsheets within Visual Studio, being these controls part of the VSTO object model. The VSTO objects are wrappers around the Interop ones and they add very interesting functionality, like events and databinding. The VSTO controls are in the Microsoft.Office.Tools.Excel namespace whereas the Interop ones are in Microsoft.Office.Interop.Excel.

Document-level customization project template

Document-level customization project

On the other and, an application-level add-in is, as its name implies, always visible for the host Application regardless of the opened workbook. The only class added by Visual Studio is the TheAddin one, no workbook or worksheet editors are provided. The VSTO controls are not available neither. All Excel objects that we can get access through TheAddin class are from the Microsoft.Office.Interop.Excel API.

Application-level add-in project template

Application-level add-in project

The problem is that, whereas document-level customization is available for Excel2003, is not yet available for Excel 2007. So, the spreadsheet editor is not available within Visual Studio and the VSTO extended controls cannot be used. The table below shows which kinds of add-in are available for each product combination (see Features available by product combination for the complete table listing all Office applications).

VSTO 2005 or Visual Studio Team System

VSTO 2005 SE installed with VSTO 2005 or Visual Studio Team System

VSTO 2005 SE installed with Visual Studio 2005 Professional Edition

Document-level customizations

Excel 2003

Not available

Application-level add-ins

Not available

Excel 2003

Excel 2007

Excel 2003

Excel 2007

Workarounds

In order to make a document-level customization (or at least something similar) to target Excel 2007 I found out that some of the following things can be done:

1- Develop for Excel 2003 and deploy in Excel 2007

It is possible to develop a document-level customization in Visual Studio for Excel 2003 using VSTO 2005. The resulting customized document can then be opened in Excel 2007 in compatibility mode with the same functionality. The drawbacks of this approach is that Excel 2003 needs to be installed in the developer's machine and that you won't have Office 2007 features like custom panes and ribbon extensibility available.

2- Develop for Excel 2007 with VSTO SE and try to emulate the document-level customization.

In order to target Excel 2007, VSTO SE is needed and the only option by the moment is to create an application level add-in. For emulating the document customization you can create an Excel's template file within Excel application, add the desired named ranges, tables, graphics, etc...and then access these controls trough the add-in's code to make custom automation. The drawback of this approach is that the extended functionality of VSTO's controls is not available. For example, you won't be able to use the ListObject databinding support. In order to access the workbook controls, the Interop API must be used. Another drawback, is that the Interop API is not as well documented as the VSTO's.

3- Develop an application-level add-in for Excel 2007 and create the VSTO's objects from code.

Actually I'm not sure wheter this is really a choice, since I couldn't make it work. What I tried here was to create a new instance of a VSTO worksheet to wrap an Interop worksheet. In ThisAddin class I have the following code:

 
using Excel = Microsoft.Office.Interop.Excel;
using Vsto = Microsoft.Office.Tools.Excel;
 
namespace ExcelAddIn1
{
    public partial class ThisAddIn
    {
        private void ThisAddIn_Startup(object sender, System.EventArgs e)
        {
            #region VSTO generated code
 
            this.Application = (Excel.Application)Microsoft.Office.Tools.Excel.ExcelLocale1033Proxy.Wrap(typeof(Excel.Application), this.Application);
 
            #endregion
 
            try
            {
                Excel.Worksheet newSheet = (Excel.Worksheet)this.Application.ActiveWorkbook.Worksheets.Add(Type.Missing, Type.Missing, Type.Missing, Type.Missing);
                Microsoft.Office.Tools.Excel.Worksheet extendedSheet = GetExtendedWorksheet(newSheet);
                extendedSheet.Controls.AddNamedRange(extendedSheet.Range["A1","C2"], "NamedRange");
            }
            catch (Exception ex) {
                MessageBox.Show(ex.ToString());
            }
        }
 
        private Vsto.Worksheet GetExtendedWorksheet(Excel.Worksheet nativeWorksheet)
        {
            //Get the IHostItemProvider instance.
            Microsoft.VisualStudio.Tools.Applications.Runtime.IHostItemProvider hostItemProvider = (Microsoft.VisualStudio.Tools.Applications.Runtime.IHostItemProvider)
                RuntimeCallback.GetService(typeof(Microsoft.VisualStudio.Tools.Applications.Runtime.IHostItemProvider));
            //Create the new worksheet and return it to calling function.
            return new Vsto.Worksheet(hostItemProvider, RuntimeCallback, nativeWorksheet.CodeName,
               null, nativeWorksheet.Name);
        }

But, when trying to add the NamedRange to the extended worksheet this Exception is thrown:

This document might not function as expected because the following control is missing: Sheet4. Data that relies on this control will not be automatically displayed or updated, and other custom functionality will not be available. Contact your administrator or the author of this document for further assistance.
at Microsoft.Office.Tools.Excel.Worksheet.GetObjects()
at Microsoft.Office.Tools.Excel.Worksheet.GetPrimaryControl()
at Microsoft.Office.Tools.Excel.Worksheet.get_Range()
at ExcelAddIn1.ThisAddIn.ThisAddIn_Startup(Object sender, EventArgs e) in C:\...\Projects\ExcelAddIn1\ExcelAddIn1\ThisAddIn.cs:line 26

Conclusion

Although VSTO's document-level customization is not available for Excel 2007 yet, there still are some choices for developing add-ins targeting this application version. Besides, the good news is that this lack will be supplied soon. VSTO "Orcas" will provide document-level customization for Excel 2007 within its new features. So, anyway, it's just a matter of time...

Developing a Custom Property Comparison Validator using Entlib's VAP

spano — Wed, 16 May 2007 16:03:00 GMT

This post was originally published at http://solepano.blogspot.com

Here's a sample scenario where, in an application using Entlib's Validation Application Block (VAP), the validation of an entity's member depends on the value of another property. In this case the entity I want to validate has two properties. Using the attributes approach to support validation, the entity's code looks like this:

public class MyEntity
{
    private string myVar1;
 
    [NotNullValidator()]
    [StringLengthValidator(0, 20, MessageTemplate = "MyProperty1 must be less than 20 characters length")]
    public string MyProperty1
    {
        get { return myVar1; }
        set { myVar1 = value; }
    }
 
    private string myVar2;
 
    [MyProp2Validator()]
    public string MyProperty2
    {
        get { return myVar2; }
        set { myVar2 = value; }
    }
}

The validators for Property1 are built in validators, no big deal with that. The thing here is that I want the second property to be validated against the value of the first one. Let’s say, for example, that Property2 is valid if it begins with the value of Property1.

Although the VAP ships with a PropertyComparisonValidator, it is limited to comparisons of type =, !=, >, >=, <>. So it seems that a custom validator has to be made. But how to obtain the actual value of Property1 from the Property2's custom validator?

One approach is to use reflection. Using reflection the DoValidate method of MyProperty2Validator would look something like this:

protected override void DoValidate(string objectToValidate, object currentTarget, string key, ValidationResults validationResults){
    //obtain the other property value through reflection
    PropertyInfo prop = currentTarget.GetType().GetProperty("MyProperty1");
    string myProp1Value = prop.GetValue(currentTarget, null) as string;
    //some custom logic here
    if (! objectToValidate.StartsWith( myProp1Value ){
        LogValidationResult(validationResults,"msg",currentTarget,key);
    }
}

But the dropdown of using reflection is that it wouldn't work with UI integration.

What do work with integration is what the built-in PropertyComparisonValidator does, and that is using the ValueAccess class. The ValueAccess class allow us to find other members in an integration friendly way throuhg its GetValue method. See how this is done in our Property2 valdiator:

[ConfigurationElementType(typeof(MyProp2ValidatorData))]
class MyProp2Validator : Validator<string> {
    private ValueAccess valueAccess;
    internal const string OtherPropName = "MyProperty1";
 
    public MyProp2Validator(ValueAccess valueAccess):base (Resources.MyProp2ValidatorMessageTemplate,null){
        this.valueAccess = valueAccess;
    }
 
    protected override void DoValidate(string objectToValidate, object currentTarget, string key, ValidationResults validationResults){
        object myProp1;
        string valueAccessFailureMessage;
        //try to obtain the value of property 1.
        if (!this.valueAccess.GetValue(currentTarget, out myProp1, out valueAccessFailureMessage)) {
            base.LogValidationResult(validationResults, string.Format(CultureInfo.CurrentUICulture, Resources.MyProp2ValidatorFailureToRetrieveProp1, new object[] { this.valueAccess.Key, valueAccessFailureMessage }), currentTarget, key);
        }
        else {
            //custom validation logic between prop1 and prop2
            if (!objectToValidate.StartsWith((string)myProp1)) { 
                base.LogValidationResult(validationResults, string.Format(CultureInfo.CurrentUICulture, this.MessageTemplate, new object[] { objectToValidate, myProp1 }), currentTarget, key);
            }
        }
    }
 
    protected override string DefaultMessageTemplate {
        get { return Resources.MyProp2ValidatorDefaultMessageTemplate; }
    }
}

What’s left is to provide the ValueAccess to the validator’s constructor. This is done in the MyProp2ValidatorAttribute class, if using attributes to place validators, or in the MyProp2ValidatorData if using configuration files. MyProp2ValidatorAttribute would look like this:

public class MyProp2ValidatorAttribute : ValueValidatorAttribute
{
    protected override Validator DoCreateValidator(Type targetType)
    {
        throw new InvalidOperationException("A member value access builder is needed.");
    }
 
    protected override Validator DoCreateValidator(Type targetType, Type ownerType, MemberValueAccessBuilder memberValueAccessBuilder)
    {
        PropertyInfo propertyInfo = ownerType.GetProperty(MyProp2Validator.OtherPropName);
        if (propertyInfo == null)
        {
            throw new InvalidOperationException(String.Format(Resources.MyProp2ValidatorAttributeCouldNotFindProperty, new string[] { ownerType.Name, MyProp2Validator.OtherPropName }));
        }
        return new MyProp2Validator(memberValueAccessBuilder.GetPropertyValueAccess(propertyInfo));
    }
}

Finally, you can test the validation logic using the following code:

private void buttonValidate_Click(object sender, EventArgs e)
{
    MyEntity ent = new MyEntity();
    ent.MyProperty1 = textBoxProp1.Text;
    ent.MyProperty2 = textBoxProp2.Text;
    ValidationResults r = Validation.Validate<MyEntity>(ent);        
    if (!r.IsValid)
    {
        DisplayValidationResults(r);
    }
    else {
        MessageBox.Show("ok");
    }
}

It's only left to provide the UI integration for the custom validator to assure averything's working right. I hope to be posting this in a second part soon.