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
Comments
Comment 1 by briang1 on 2014-04-29 07:48 Or would it fall back to Msaa. |
Comment 2 by mdcurran (in reply to comment 1) on 2014-04-29 08:21
Correct, MSAA will still be used. |
Comment 3 by jteh on 2014-05-15 01:52 |
@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? |
@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. |
@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? |
Hi, I believe this is now a part of NVDA via good UIA window list. Thanks.
From: bhavyashah <notifications@github.com>
Sent: Wednesday, August 15, 2018 11:38 AM
To: nvaccess/nvda <nvda@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Subject: Re: [nvaccess/nvda] Allow appModules to force a window to use UI automation (#4102)
@michaelDCurran <https://github.com/michaelDCurran> In #4102 (comment) <#4102 (comment)> , @feerrenrut <https://github.com/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?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub <#4102 (comment)> , or mute the thread <https://github.com/notifications/unsubscribe-auth/AHgLkHrDFa4cso-fLrp1xZloiF-qKWivks5uRGqfgaJpZM4PM7lt> .
|
@michaelDCurran if you agree with @josephsl, I guess this issue can now be closed. Right? |
Fixed in #7961 |
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. |
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.
The text was updated successfully, but these errors were encountered: