locked
Client-side provider RRS feed

  • Question

  • Hi all:

    I'm trying to figure out and practice provider related topics.

    I've implement a custom button derived form System.Windows.Forms.Control which will deal with custom appearance.

    Firstly, i implement a simple server-side provider with pasic info and InvokePattern, it worked correctly.
    Then, i removed the server-side provider and try to implement a client-side provider, the following is the condition that confused me:

    Actually, If we make a custom control derived from System.Windows.Forms.Control without any automation provider, that contorl could be capture by UISPY and its classname is "WindowsForms10.Window.8.app.0.378734a".
    While i implement client-side provider for my custom control, I implement the class UIAutomationClientSideProviders to provide ClientSideProviderDescription with my class name "MyCustomButton". but it seems not work, it does not even call my provider create function. It looks like the UIA framework did not recognize "MyCustomButton" and therefore could not access it. If I change the class name to "WindowsForms10.Window.8.app.0.378734a" and it seems the provider was correctly invoked (surely its not logically "correct" because the class name of the window that control hosts is also "WindowsForms10.Window.8.app.0.378734a". I just change it to test.).

    What is the definition of the parameter "Class Name" to create ClientSideProviderDescription? isn't it the implmentation class of my custom control? How do i make a client-side provider correctly?

    Please provide some guidance, Any words would be helpful~
    Thx sincerely.
    Monday, July 27, 2009 4:24 PM

Answers

  • Hi, Danans,

    Client-side providers are cool, but not magic.  We use them extensively in our own code -- every time you check the UIA properties of a common Win32 control, like a button or a scrollbar, you are using a client-side provider.  They *do* solve a lot of problems. 

    However, you have to have a pre-existing mechanism for getting information in and out of the controls from the client application.  For Win32 controls like buttons and scrollbars, there are a set of Win32 messages (like WM_GETTEXT and BN_CLICK) that can be used to query and change these controls.  A client-side provider is thus a kind of translator that translates UIA requests into the Win32 controls' own language.  This is a bit similar to language translation: if I can speak to you in Russian, then if I don't understand Russian, I can still get a Russian-to-English translator and continue our conversation.

    However, if there is no mechanism for getting information in and out of the controls from the client application, then you are stuck.  (If you are on the other side of a brick wall, my Russian-to-English translator can't solve my problem.)  UIA's client-side support cannot do the impossible -- it cannot pull information out of a control that does not provide any way to expose it.

    WPF generally does server-side providers for accessibility.  A custom WPF control that does not implement a server-side provider, and does not implement any other way to control it, cannot be controlled with a UIA client-side provider.  It's pretty much on the other side of the brick wall.  No amount of cleverness (either from UIA or another other library) is going to pull information from a control that doesn't want to expose it -- that's what operating system security is all about.

    Hope that helps,
    Michael
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, August 7, 2009 3:24 PM

All replies

  • Hi, Danans,

    The "Class Name" parameter is the window class name of the control for which you are creating a provider.  There is an MSDN discussion of window classes here: http://msdn.microsoft.com/en-us/library/ms633574(VS.85).aspx

    I think you were hoping that "Class Name" would be the name of your C# or VB class that implements the window.  Unfortunately, the name of the C#/VB class is mostly obliterated by the compiler when it turns your code into a .NET binary.  (In .NET, the class name is still around in a few places, but in C++, it's really gone.)  That's why UI Automation uses the Window Class.

    Also, it sounds like you have access to the code for the provider (the custom button itself).  It is generally *much* easier to create a server-side provider than a client-side one, so if you have the choice, I would definitely stick to server-side.  That's what we do in the UIA team when we have the option. 

    Thanks,
    Michael
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, August 5, 2009 3:53 PM
  • Hi Michael:

    Really really thx for reply.

    I certainly know its easier to implement server-side provider. but thats under the circumstance that the Application is just developing. My scenario is auto testing for fully developed existing appications which have no chances to update the implementation to nativily support for UIA. Those applications i have to test now are implement form varies UI framework, some of them are our custom UI framework, some of them use MS framework like WPF but also have some WPF custom control. All of them were developed before we awared the existance of the UIA framework.

    MS claims that UIA could use client-side provider to fulfill this kind requirement but provide less technique infomation of this part. This really frustrated me because i really gave a lot of hope while i read about "client-side provider", and i truely believe that there are many others will have the same requirement in this time, for not every applications have implement accessibility. It seems now that the "client-side provider" is not much useful in real condition.

    Anyway, really thx for reply again.
    BR~
    Thursday, August 6, 2009 11:56 AM
  • Hi, Danans,

    Client-side providers are cool, but not magic.  We use them extensively in our own code -- every time you check the UIA properties of a common Win32 control, like a button or a scrollbar, you are using a client-side provider.  They *do* solve a lot of problems. 

    However, you have to have a pre-existing mechanism for getting information in and out of the controls from the client application.  For Win32 controls like buttons and scrollbars, there are a set of Win32 messages (like WM_GETTEXT and BN_CLICK) that can be used to query and change these controls.  A client-side provider is thus a kind of translator that translates UIA requests into the Win32 controls' own language.  This is a bit similar to language translation: if I can speak to you in Russian, then if I don't understand Russian, I can still get a Russian-to-English translator and continue our conversation.

    However, if there is no mechanism for getting information in and out of the controls from the client application, then you are stuck.  (If you are on the other side of a brick wall, my Russian-to-English translator can't solve my problem.)  UIA's client-side support cannot do the impossible -- it cannot pull information out of a control that does not provide any way to expose it.

    WPF generally does server-side providers for accessibility.  A custom WPF control that does not implement a server-side provider, and does not implement any other way to control it, cannot be controlled with a UIA client-side provider.  It's pretty much on the other side of the brick wall.  No amount of cleverness (either from UIA or another other library) is going to pull information from a control that doesn't want to expose it -- that's what operating system security is all about.

    Hope that helps,
    Michael
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Friday, August 7, 2009 3:24 PM
  • Hi Michael:

    Really really thx for reply again.

    I know MS implement UIA support for Win32 and WindowForm by client-side provider exactly. forgive my unsuitable adjective words "not much useful in real condition". I just want to clarify the bottom line requirement to use client-side provider.

    May i say that: if the custom UI framewrok or controls of some application are designed by window-handle message base and have explicit register its implement window classes respectly, then it might have a lot chance to use client-side provider to implement UIA accessibility out-side the that application?

    Anyway, your response do really help me to clarify some technique details already. thanks for help.
    BR~
    Monday, August 10, 2009 6:05 AM