Skip to content
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

Move Terminal UIA provider into Types & hook it up to the WPF control #4548

Merged
1 commit merged into from
Feb 24, 2020

Conversation

ZoeyR
Copy link
Contributor

@ZoeyR ZoeyR commented Feb 12, 2020

This PR hooks up the existing UIA implementation to the WPF control. Some existing code that was specific to the UWP terminal control could be shared so that has been refactored to a common location as well.

Validation Steps Performed

WPF control was brought up in UISpy and the UIA tree was verified. NVDA was then used to check that screen readers were operating properly.

Copy link
Contributor

@DHowett-MSFT DHowett-MSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems reasonable, but I have some minor questions and I need @carlos-zamora and @miniksa to take a good long look at it. I'll red-x for now, but I love where it's going.

src/cascadia/TerminalControl/TermControlAutomationPeer.cpp Outdated Show resolved Hide resolved
src/cascadia/TerminalControl/TermControlAutomationPeer.cpp Outdated Show resolved Hide resolved
src/types/IControlInfo.h Outdated Show resolved Hide resolved
src/types/IControlInfo.h Outdated Show resolved Hide resolved
src/types/TermControlUiaProvider.cpp Outdated Show resolved Hide resolved
src/types/TermControlUiaTextRange.cpp Show resolved Hide resolved
@ghost ghost added Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something and removed Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something labels Feb 12, 2020
@ZoeyR
Copy link
Contributor Author

ZoeyR commented Feb 12, 2020

Can someone help me with this precomp.h issue with the header files? Shouldn't the header files not need it?

Edit: Nevermind, figured out the issue, I had something <ClCompile> and not <ClInclude>

@ZoeyR
Copy link
Contributor Author

ZoeyR commented Feb 12, 2020

I think I hit some new static analysis issues with code that wasn't covered before.

Copy link
Member

@miniksa miniksa left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some comments. Looks pretty alright to me.

src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
src/cascadia/PublicTerminalCore/HwndTerminal.cpp Outdated Show resolved Hide resolved
@ZoeyR
Copy link
Contributor Author

ZoeyR commented Feb 14, 2020

@miniksa or @DHowett Why would I be getting static analysis issues with UiaTextRangeBase.hpp? I didn't edit that at all.


double HwndTerminal::GetScaleFactor() const
{
return static_cast<double>(_currentDpi) / static_cast<double>(USER_DEFAULT_SCREEN_DPI);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: you could probably use base::ClampDiv() here.

Copy link
Member

@carlos-zamora carlos-zamora left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I get why we moved UiaTextRange to Types. But can we keep the same name? At least to reduce merge conflicts? We can probably take on the renaming once we merge IControlAccessibilityInfo with UiaTextRangeBase.

  • Would you be able to just have IControlAccessibilityInfo needed at the ScreenInfoUiaProviderBase layer instead of the TermControlUiaProvider?

@ghost ghost added the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Feb 14, 2020
@ZoeyR
Copy link
Contributor Author

ZoeyR commented Feb 14, 2020

If we keep the same name wouldn't it conflict with the names in src\interactivity\win32?

As for the IControlAccessibilityInfo comment, We'd again run into issues migrating over the stuff in win32

@ghost ghost removed the Needs-Author-Feedback The original author of the issue/PR needs to come back and respond to something label Feb 14, 2020
@carlos-zamora
Copy link
Member

If we keep the same name wouldn't it conflict with the names in src\interactivity\win32?

As for the IControlAccessibilityInfo comment, We'd again run into issues migrating over the stuff in win32

Ugh. Yeah. Win32 is the problem here. That'll all have to be fixed as a part of resolving the "merge IControlAccesibilityInfo with UiaTextRangeBase" issue. That's annoying but, other than that, I don't think I have any blocking comments.

@DHowett-MSFT
Copy link
Contributor

It looks like, by rights, these issues should have tripped up SA before your PR. Hmm.

Copy link
Contributor

@DHowett-MSFT DHowett-MSFT left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, this looks good to me. Thanks so much for abstracting the things that made it TerminalControl-specific. This'll be a good platform on which we can re-merge the disparate UiaTextRangeBase derivations into a single class.

We should eventually crush together all the interfaces, where possible, but I won't ask you to do that.

Comment on lines +66 to +71
virtual COORD GetFontSize() const override;
virtual RECT GetBounds() const override;
virtual RECT GetPadding() const override;
virtual double GetScaleFactor() const override;
virtual void ChangeViewport(SMALL_RECT NewWindow) override;
virtual HRESULT GetHostUiaProvider(IRawElementProviderSimple** provider) override;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: SA would complain about the virtual here because override implies it

@DHowett-MSFT DHowett-MSFT changed the title hook up UIA tree to WPF control Move Control UIA provider into Types and hook it up to the WPF control Feb 24, 2020
@DHowett-MSFT DHowett-MSFT changed the title Move Control UIA provider into Types and hook it up to the WPF control Move Terminal UIA provider into Types & hook it up to the WPF control Feb 24, 2020
@DHowett-MSFT DHowett-MSFT added the AutoMerge Marked for automatic merge by the bot when requirements are met label Feb 24, 2020
@ghost
Copy link

ghost commented Feb 24, 2020

Hello @DHowett-MSFT!

Because this pull request has the AutoMerge label, I will be glad to assist with helping to merge this pull request once all check-in policies pass.

p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (@msftbot) and give me an instruction to get started! Learn more here.

@ghost ghost merged commit 4def49c into master Feb 24, 2020
@ghost ghost deleted the dev/zorio/wpf-uia-tree branch February 24, 2020 23:18
@ZoeyR ZoeyR mentioned this pull request Feb 25, 2020
5 tasks
ZoeyR added a commit that referenced this pull request Feb 28, 2020
PR #4548 inadvertantly broke mouse button input in the WPF control. This happened due to the extra layer of HWND indirection. The fix is to move the mouse button handling down into the native control where the window messages are now being sent.
DHowett-MSFT pushed a commit that referenced this pull request Feb 28, 2020
PR #4548 inadvertantly broke mouse button input in the WPF control. This happened due to the extra layer of HWND indirection. The fix is to move the mouse button handling down into the native control where the window messages are now being sent.

(cherry picked from commit 4393fef)
This pull request was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
AutoMerge Marked for automatic merge by the bot when requirements are met
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants