-
Notifications
You must be signed in to change notification settings - Fork 22
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UIA Operation Abstraction lib: implement support for CallExtension / IsExtensionSupported #84
Conversation
…ropertyId by using UiaLookupId.
…omationRemoteObject so that the initializer list is implisitly cast to an array_view of AutomationRemoteObject values as expected.
I have been able to manually confirm that these changes work, at least for my use cases, by testing them against Microsoft Word's custom patterns implementation, from within the NVDA screen reader. However, I really am not sure how this can be tested specifically within this project as access to Microsoft Word, or something that implemented custom patterns, would be required on the build system. |
Sorry for us ignoring this PR for so long! I'll give it a look next week. @mavangur @zhayuli @pengyuanjin for FYI. Honestly, we haven't even had the time to get our tests running in CI yet. There's a general issue with launching apps and we haven't really gotten to look at why. I'll give some thought as to what we can do with regard to automated testing here. |
class UiaGuid : public UiaTypeBase<winrt::guid, winrt::Microsoft::UI::UIAutomation::AutomationRemoteGuid> | ||
{ | ||
public: | ||
//static constexpr VARTYPE c_comVariantType = VT_CLSID; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we need these comment lines?
I tried to add support for GUIds to UIAVariant, but did not succeed. I
am unsure as to what vt type should be used, or if it it is at all
possible to hold a GUID in a VARIANT structure at all these days?
I'm happy to either remove these commented lines, or if anyone has
further info on how to do this properly, please share and I'll try
adding that support again.
Message ID:
***@***.***>
|
|
||
UiaPropertyId UiaGuid::LookupPropertyId() | ||
{ | ||
if (ShouldUseRemoteApi()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: This should be indented in by 4 more spaces.
return; | ||
} | ||
|
||
// No local equivilant |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: Should be spelled "equivalent"
@michaelDCurran I'd say as long as we don't need GUIDs in UiaVariant for this PR, we can remove those comment lines. It might make sense to store GUIDs in VT_SAFEARRAY in the variant, though, when we want to implement that. Also, we could add support for extension tests by creating a provider that supports custom extensions, and loading it with the |
I'm really sorry for all the slow responses here! My remaining comment is can we add tests for Otherwise, this looks great!!! |
@michaelDCurran just in case you missed these notifications. |
Sorry for delay on this. Hopefully I should find time in next week or so
to write UiaGuid tests.
|
No need to apologize I just wanted to make sure you didn't think you were waiting on me :) |
@beweedon I'm afraid that I can't think of any ways I can write remote tests for UiaGuid.
In other words, to create any meaningful tests for UiaGuid, (just like for custom extensions) we'd need to write a custom provider or test with an MS Office product such as Microsoft Word. |
@michaelDCurran I was thinking mostly about testing the simple stuff just to make sure it works.
I'm glad you're not blocked, though :). If you don't want to add the tests, one of us can look into that at some point and get this merged in. |
…d annotation type IDs. This also required: * UIAGuid: add cast operator for winrt::guid to allow getting back to local after remote execution. * UiaOperationAbstraction library now also links against UiAutomationCore.lib as UiaLookupId is required.
@beweedon I've now added tests for UiaGuid, including equality checks, and looking up property IDs and annotation type IDs. |
@michaelDCurran This looks great to me! I'm going to see if other reviews filter in before merging. |
/azp run |
Azure Pipelines successfully started running 1 pipeline(s). |
The new commit being used (d8c87fa) is effectively the same as the commit used in NVDA currently (224b22f). microsoft main branch HEAD commit: d8c87fa Merge of microsoft/Microsoft-UI-UIAutomation#84 From repo:branch michaelDCurran:callExtension The callExtension branch includes the commit that NVDA was using (224b22f), but it was not the HEAD of the branch when the branch was merged upstream. There was one commit on that branch after this: See commit cdabf41ed5c277d7761222e947748ee860ec97d2 in the callExtension branch: https://github.com/michaelDCurran/Microsoft-UI-UIAutomation/commits/callExtension
UI Automation recently introduced the concept of custom patterns. This is the ability for a provider to expose custom methods, identified by a GUID, that a client an execute via UIA remote Operations. For example, MS Word might expose a custom pattern for moving by sentence - something that UIA by itself does not support.
This PR implements the ability for a client to execute these custom methods (extensions) by using the UIA Operation Abstraction library. Support for custom patterns has already been introduced to the Microsoft::UI::UIAutomation winrt library.
Specific changes:
No tests have been written yet. These will be hard to write unless they can be run against a specific app that exposes 1 or more custom patterns.
Manually I have tested UiaGuid::LookupAnnotationType / UiaGuid::LookupPropertyId. But I am so far unable to test UiaElement::IsExtensionSupported / UIAElement::CallExtension until I have an app that actually implements 1 or more custom patterns...