Navigation Menu

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

Allow appModules to force a window to use UI automation #4102

Closed
nvaccessAuto opened this issue Apr 29, 2014 · 10 comments
Closed

Allow appModules to force a window to use UI automation #4102

nvaccessAuto opened this issue Apr 29, 2014 · 10 comments

Comments

@nvaccessAuto
Copy link

Reported by mdcurran on 2014-04-29 03:07
Currently it's possible for an appModule to force a control to not use UIA, via its isBadUIAWindow method. However, there is no way for the opposite situation. We should replace isBadUIAWindow with an isUIAWindow which can return True for yes, False for no, and None for not sure (ask the window).
A practical usecase is the spell check field and signature field in Outlook 2013. These have suitable UIA implementations but unusable IAccessible ones.

@nvaccessAuto
Copy link
Author

Comment 1 by briang1 on 2014-04-29 07:48
How would you let a user know that is running the software in XP, that the program may not work due to there being no UIA implimented in XP though.

Or would it fall back to Msaa.

@nvaccessAuto
Copy link
Author

Comment 2 by mdcurran (in reply to comment 1) on 2014-04-29 08:21
Replying to briang1:

How would you let a user know that is running the software in XP, that the program may not work due to there being no UIA implimented in XP though.

Or would it fall back to Msaa.

Correct, MSAA will still be used.

@nvaccessAuto
Copy link
Author

Comment 3 by jteh on 2014-05-15 01:52
Not needed at the moment after all.
Changes:
Milestone changed from next to None

@bhavyashah
Copy link

@feerrenrut Since labelling well-defined feature requests or proposals as feature would help in eliminating them from the triage process and allow developers to systematically access a list of them later, I think this particular ticket looks suitable to be labelled as a feature. Thoughts?

@feerrenrut
Copy link
Contributor

@bhavyashah this issue does not contain a description of a user facing feature. It does however detail a "behind the scenes" change that could allow improvements in app modules. As such, I think an enhancement label would be best for this. One thing we should try to get an understanding of, is what kind of demand there is for this change. This will help to influence when something like this will get worked on.

@bhavyashah
Copy link

@michaelDCurran In #4102 (comment), @feerrenrut states "One thing we should try to get an understanding of, is what kind of demand there is for this change. This will help to influence when something like this will get worked on." Do you have any inputs on or responses to this?

@josephsl
Copy link
Collaborator

josephsl commented Aug 15, 2018 via email

@Adriani90
Copy link
Collaborator

@michaelDCurran if you agree with @josephsl, I guess this issue can now be closed. Right?

@LeonarddeR
Copy link
Collaborator

Fixed in #7961

@josephsl
Copy link
Collaborator

josephsl commented Jan 2, 2019

Hi,

Yes, this is an older issue that was the reason for defining appModule.isGoodUIAWindow and friends in recent releases. See #7961 for details on justifications and implementation discussion.

Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants