Date   
Recommended way of excluding certain elements from navigation

Toni Barth
 

Hello,
 
because noone replied to my last post from a few days ago and I accidentally used the wrong tag for my question, i'm sending my previous message again down below.
 
i'm developing an add-on right now to enhance the usability of an application. This application contains at least one table with several cells, but some of those cells, even though they are navigatable by NVDA, contain unimportant information, like the value 'None' or just an icon. I thus wanted to "hide" those cells for the user, meaning that they shouldn't be able to navigate to them using the tab key or arrow keys and tried several ways to do so.
 
I overlayed the table row and override _get_children(), removing the certain children from the list, but I noticed that _get_children() never seems to get executed.
 
I also tried adding states to the specific cells like controlTypes.STATE_INVISIBLE or controlTypes.STATE_UNAVAILABLE, but nothing helped.
 
I also tried moving the focus manually whenever the cell is focused by using event_gainFocus(), but even this seems to mess up things even further. Same goes for using redirectFocus and/or _get_redirectFocus(). It properly redirects my focus to the next cell, but the cursor still seems to be located in the cell whatsoever, means whenever I press the right arrow key, i'll get the same, second cell announced a second time.
 
Do you have an idea how to remove those cells from keyboard navigation (not navigator, but at least from tab/arrow keys navigation)?
 
There must be an easy way to exclude certain elements from keyboard navigation.
 
Thanks for your help :).
 
Best Regards.
 
Toni Barth

Re: Recommended way of excluding certain elements from navigation

James Scholes
 

It would help to know more about the application. You've given tons of detail about what you've tried on the NVDA side, but none about what else you're working with.

• Is this an application you're developing or helping to develop?
• Is it a traditional desktop application, or a web app inside a desktop container?
• If the former, what sort of UI framework and programming environment is in use (e.g. Qt, .Net Framework with WPF, etc.)?

Regards,

James Scholes

On 03/09/2019 at 7:15 pm, Toni Barth via Groups.Io wrote:
Hello,
because noone replied to my last post from a few days ago and I accidentally used the wrong tag for my question, i'm sending my previous message again down below.
i'm developing an add-on right now to enhance the usability of an application. This application contains at least one table with several cells, but some of those cells, even though they are navigatable by NVDA, contain unimportant information, like the value 'None' or just an icon. I thus wanted to "hide" those cells for the user, meaning that they shouldn't be able to navigate to them using the tab key or arrow keys and tried several ways to do so.
I overlayed the table row and override _get_children(), removing the certain children from the list, but I noticed that _get_children() never seems to get executed.
I also tried adding states to the specific cells like controlTypes.STATE_INVISIBLE or controlTypes.STATE_UNAVAILABLE, but nothing helped.
I also tried moving the focus manually whenever the cell is focused by using event_gainFocus(), but even this seems to mess up things even further. Same goes for using redirectFocus and/or _get_redirectFocus(). It properly redirects my focus to the next cell, but the cursor still seems to be located in the cell whatsoever, means whenever I press the right arrow key, i'll get the same, second cell announced a second time.
Do you have an idea how to remove those cells from keyboard navigation (not navigator, but at least from tab/arrow keys navigation)?
There must be an easy way to exclude certain elements from keyboard navigation.
Thanks for your help :).
Best Regards.
Toni Barth

Re: Recommended way of excluding certain elements from navigation

Toni Barth
 

Hi,

thanks, those questions help alot.

Am 03.09.2019 um 20:37 schrieb James Scholes:
It would help to know more about the application.  You've given tons
of detail about what you've tried on the NVDA side, but none about
what else you're working with.

• Is this an application you're developing or helping to develop?

Nope, i'm just trying to enhance its accessibility by developing an
add-on for NVDA.

The application itself is called Banking 4
(https://subsembly.com/banking4.html).


• Is it a traditional desktop application, or a web app inside a
desktop container?

Its a traditional desktop application (at least it looks like it).


• If the former, what sort of UI framework and programming environment
is in use (e.g. Qt, .Net Framework with WPF, etc.)?
I actually don't know. It doesn't look like Qt or Java though. NVDA
itself recognizes the UI elements as IAccessible elements.


Thanks for your help.


Best Regards.


Toni Barth


Regards,

James Scholes

On 03/09/2019 at 7:15 pm, Toni Barth via Groups.Io wrote:
Hello,
because noone replied to my last post from a few days ago and I
accidentally used the wrong tag for my question, i'm sending my
previous message again down below.
i'm developing an add-on right now to enhance the usability of an
application. This application contains at least one table with
several cells, but some of those cells, even though they are
navigatable by NVDA, contain unimportant information, like the value
'None' or just an icon. I thus wanted to "hide" those cells for the
user, meaning that they shouldn't be able to navigate to them using
the tab key or arrow keys and tried several ways to do so.
I overlayed the table row and override _get_children(), removing the
certain children from the list, but I noticed that _get_children()
never seems to get executed.
I also tried adding states to the specific cells like
controlTypes.STATE_INVISIBLE or controlTypes.STATE_UNAVAILABLE, but
nothing helped.
I also tried moving the focus manually whenever the cell is focused
by using event_gainFocus(), but even this seems to mess up things
even further. Same goes for using redirectFocus and/or
_get_redirectFocus(). It properly redirects my focus to the next
cell, but the cursor still seems to be located in the cell
whatsoever, means whenever I press the right arrow key, i'll get the
same, second cell announced a second time.
Do you have an idea how to remove those cells from keyboard
navigation (not navigator, but at least from tab/arrow keys navigation)?
There must be an easy way to exclude certain elements from keyboard
navigation.
Thanks for your help :).
Best Regards.
Toni Barth

Screen Curtain: September 6th build, preparing for future NVDA releases #addonrelease

 

Hi all,

 

In about an hour from now Screen Curtain September 6th build will be released. This build is important because it includes a good news and a bad news (depending on how you view it):

 

  • Good news: Screen Curtain add-on is ready for NVDA 2019.3 (alpha form).
  • Bad news: this will be one of the last builds of this add-on.

 

As for this being a bad news for Screen Curtain add-on, not entirely a bad news: Screen Curtain add-on has found a new home, and that is latest NVDA alpha snapshot. As part of this transplantation, Leonard de Ruijter (the author behind routines in this add-on and allowing me to package his work as an add-on for field testing) rewrote major portions of screen curtain facility. Thus, if you are using latest NVDA 2019.3 alpha snapshot, today’s Screen Curtain add-on release will recognize this and not load itself.

 

As for today’s release being one of the last releases of Screen Curtain add-on: yes, although it won’t be until NVDA 2019.3 stable version is released that this add-on will be declared end of life. This is because there might be changes that will require me to adjust end of life strategy for this add-on. The repo will not be removed from my GitHub so people can study it once the add-on ceases active development.

 

Thanks.

Cheers,

Joseph

Question about screen curtain, review comments

Noelia Ruiz
 

@leonardder and @feerrenrut :

def script_toggleScreenCurtain(self, gesture):
message = None
try:
screenCurtainName = "screenCurtain"
if not vision.getProviderClass(screenCurtainName).canStart():
# Translators: Reported when the screen curtain is not available.
message = _("Screen curtain not available")
return

If return, I think that the message won't be reported if screen curtain is not available.

Also:

# Translators: Reported when the screen curtain could not be enabled.
message = _("Could not enable screen curtain")
return

Sorry if I'm missing something.
My tests are successful toggling screen curtain, so I can't check what happens when this can't be done.
Kind regards

Re: Screen Curtain: September 6th build, preparing for future NVDA releases #addonrelease

Brian's Mail list account
 

So it will still work where it worked before, so no issues to anybody then?
Not that I use it myself as my puters do not have a screen in the first place!
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Joseph Lee" <@joslee>
To: <nvda-devel@groups.io>
Sent: Friday, September 06, 2019 8:35 PM
Subject: [nvda-devel] Screen Curtain: September 6th build, preparing for future NVDA releases #AddonRelease


Hi all,



In about an hour from now Screen Curtain September 6th build will be
released. This build is important because it includes a good news and a bad
news (depending on how you view it):



* Good news: Screen Curtain add-on is ready for NVDA 2019.3 (alpha
form).
* Bad news: this will be one of the last builds of this add-on.



As for this being a bad news for Screen Curtain add-on, not entirely a bad
news: Screen Curtain add-on has found a new home, and that is latest NVDA
alpha snapshot. As part of this transplantation, Leonard de Ruijter (the
author behind routines in this add-on and allowing me to package his work as
an add-on for field testing) rewrote major portions of screen curtain
facility. Thus, if you are using latest NVDA 2019.3 alpha snapshot, today's
Screen Curtain add-on release will recognize this and not load itself.



As for today's release being one of the last releases of Screen Curtain
add-on: yes, although it won't be until NVDA 2019.3 stable version is
released that this add-on will be declared end of life. This is because
there might be changes that will require me to adjust end of life strategy
for this add-on. The repo will not be removed from my GitHub so people can
study it once the add-on ceases active development.



Thanks.

Cheers,

Joseph



Re: Question about screen curtain, review comments

 

Hey Noelia,


Thanks for pointing this out. It actually works as expected, but I will explain why.


The script uses a try/finally block. I think the following code is pretty explanatory when executed:


def test():
    try:
        return(42)
    finally:
        print("hello!")

You will notice that when executing test(), both 42 and Hello are printed. In short, return brings you straight to the finally block, and I think the function will first execute the finally block and then returns.


Regards,

Leonard


On 7-9-2019 11:17, Noelia Ruiz wrote:
@leonardder and @feerrenrut :

def script_toggleScreenCurtain(self, gesture):
        message = None
        try:
            screenCurtainName = "screenCurtain"
            if not vision.getProviderClass(screenCurtainName).canStart():
                # Translators: Reported when the screen curtain is not available.
                message = _("Screen curtain not available")
                return

If return, I think that the message won't be reported if screen curtain is not available.

Also:

# Translators: Reported when the screen curtain could not be enabled.
                    message = _("Could not enable screen curtain")
                    return

Sorry if I'm missing something.
My tests are successful toggling screen curtain, so I can't check what happens when this can't be done.
Kind regards




Re: Question about screen curtain, review comments

Noelia Ruiz
 

Great work and excellent explanation!
Previously, I tried to test something similar in the Python console and for any reason this failed, but it works perfectly in a global plugin using ui.message().
In the console I got this: SyntaxError: 'return' outside function
But this works and expected. Thanks for all your work and my best wishes.

Regards

El 07/09/2019 a las 12:40, Leonard de Ruijter escribió:
Hey Noelia,
Thanks for pointing this out. It actually works as expected, but I will explain why.
The script uses a try/finally block. I think the following code is pretty explanatory when executed:
def test():
    try:
        return(42)
    finally:
        print("hello!")
You will notice that when executing test(), both 42 and Hello are printed. In short, return brings you straight to the finally block, and I think the function will first execute the finally block and then returns.
Regards,
Leonard
On 7-9-2019 11:17, Noelia Ruiz wrote:
@leonardder and @feerrenrut :

def script_toggleScreenCurtain(self, gesture):
        message = None
        try:
            screenCurtainName = "screenCurtain"
            if not vision.getProviderClass(screenCurtainName).canStart():
                # Translators: Reported when the screen curtain is not available.
                message = _("Screen curtain not available")
                return

If return, I think that the message won't be reported if screen curtain is not available.

Also:

# Translators: Reported when the screen curtain could not be enabled.
                    message = _("Could not enable screen curtain")
                    return

Sorry if I'm missing something.
My tests are successful toggling screen curtain, so I can't check what happens when this can't be done.
Kind regards



Re: Question about screen curtain, review comments

Noelia Ruiz
 

Obviously, the function works well in the console too. It was my mistake since I didn't use a function to encapsulate code.
Thanks.

El 07/09/2019 a las 13:14, Noelia Ruiz via Groups.Io escribió:
Great work and excellent explanation!
Previously, I tried to test something similar in the Python console and for any reason this failed, but it works perfectly in a global plugin using ui.message().
In the console I got this: SyntaxError: 'return' outside function
But this works and expected. Thanks for all your work and my best wishes.
Regards
El 07/09/2019 a las 12:40, Leonard de Ruijter escribió:
Hey Noelia,


Thanks for pointing this out. It actually works as expected, but I will explain why.


The script uses a try/finally block. I think the following code is pretty explanatory when executed:


def test():
     try:
         return(42)
     finally:
         print("hello!")

You will notice that when executing test(), both 42 and Hello are printed. In short, return brings you straight to the finally block, and I think the function will first execute the finally block and then returns.


Regards,

Leonard


On 7-9-2019 11:17, Noelia Ruiz wrote:
@leonardder and @feerrenrut :

def script_toggleScreenCurtain(self, gesture):
        message = None
        try:
            screenCurtainName = "screenCurtain"
            if not vision.getProviderClass(screenCurtainName).canStart():
                # Translators: Reported when the screen curtain is not available.
                message = _("Screen curtain not available")
                return

If return, I think that the message won't be reported if screen curtain is not available.

Also:

# Translators: Reported when the screen curtain could not be enabled.
                    message = _("Could not enable screen curtain")
                    return

Sorry if I'm missing something.
My tests are successful toggling screen curtain, so I can't check what happens when this can't be done.
Kind regards



Re: Question about screen curtain, review comments

 

Thanks!


On 7-9-2019 13:14, Noelia Ruiz wrote:
Great work and excellent explanation!
Previously, I tried to test something similar in the Python console and for any reason this failed, but it works perfectly in a global plugin using ui.message().
In the console I got this: SyntaxError: 'return' outside function
But this works and expected. Thanks for all your work and my best wishes.

Regards

El 07/09/2019 a las 12:40, Leonard de Ruijter escribió:
Hey Noelia,


Thanks for pointing this out. It actually works as expected, but I will explain why.


The script uses a try/finally block. I think the following code is pretty explanatory when executed:


def test():
     try:
         return(42)
     finally:
         print("hello!")

You will notice that when executing test(), both 42 and Hello are printed. In short, return brings you straight to the finally block, and I think the function will first execute the finally block and then returns.


Regards,

Leonard


On 7-9-2019 11:17, Noelia Ruiz wrote:
@leonardder and @feerrenrut :

def script_toggleScreenCurtain(self, gesture):
        message = None
        try:
            screenCurtainName = "screenCurtain"
            if not vision.getProviderClass(screenCurtainName).canStart():
                # Translators: Reported when the screen curtain is not available.
                message = _("Screen curtain not available")
                return

If return, I think that the message won't be reported if screen curtain is not available.

Also:

# Translators: Reported when the screen curtain could not be enabled.
                    message = _("Could not enable screen curtain")
                    return

Sorry if I'm missing something.
My tests are successful toggling screen curtain, so I can't check what happens when this can't be done.
Kind regards








WWAHost: bring back browse mode for Store apps in Windows 8.x?

 

Hi all,

 

I’m wrestling with the following GitHub issue:

https://github.com/nvaccess/nvda/issues/9117

 

Background: Windows 8.x introduced hosted web apps inside a dedicated app called WWA Host. In 2012, Mick created an app module that tells NVDA that this is an app, not a browse mode document. Although it brought peace to web apps support in Windows 8.x, it does not represent reality in 2019 where we have more web apps popping up on Microsoft Store on Windows 10. In fact, progressive web apps (PWA’s) on Windows 10 are really interfaces to web services that behave like native apps, and they use EdgeHTML as rendering engine, thereby making app role coercion fall apart.

 

I bring this to your attention for a number of reasons. First, I think we need to think about current reality when it comes to supporting web apps hosted inside wwahost.exe, as they are web apps more than native apps from the old days. Second, we can now use a flag in app modules to specify that an app should not be using browse mode at startup, thereby allowing older apps to appear to be native apps to users. Third, I’m working on a pull request that will allow people to write dedicated app modules for web apps hosted inside WWA Host, and based on current pull request work, app role coercion fails because NVDA will load the app module associated with the app in use without loading the app module class.

 

Therefore I’m in favor of bringing back browse mode for apps hosted on WWA Host, and let individual app modules choose whether they wish to disable browse mode. This is more applicable on Windows 8.x as most apps (at least older ones) are really a hybrid of native app and a web service, given they are hosted inside wwahost.exe (written with web in mind); on Windows 10, no change is necessary as PWA’s hosted inside wwahost.exe are meant to be web apps, although the flag to disable browse mode may come in handy for some.

 

Comments are appreciated.

Cheers,

Joseph

Superantispyware button names no longer read

Brian's Mail list account
 

Hi I may have mentioned this before, but in the Python 3 Alpha branch the buttons mostly say button on thee main page of this software when focus is moved to it, but on the latest stable the buttons say what they do.
I know this piece of software can be a pain at times, but generally it works if you launch it from the tray via the update menu item, and then click OK when it is done and then the page reads as focus is properly passed to it.
As I say. I wondered how come this should be so different in the Alpha snap. I guess I could cobble together a ticket with logs etc, but the look of the logs apart from the spoken words seems to be the same.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Re: Superantispyware button names no longer read

James Scholes
 

The log content may be the same, but the primary reason to file a ticket is to allow NVDA contributors to track and prioritize. If there's a bug (which there clearly is), please file an issue.

Regards,

James Scholes

On 09/09/2019 at 8:26 am, Brian's Mail list account via Groups.Io wrote:
Hi I may have mentioned this before, but in the Python 3 Alpha branch the buttons mostly say button on thee main page of this software when focus is moved to it, but on the latest stable the buttons say what they do.
I know this piece of software can be a pain at times, but generally it works if you launch it from the tray via the update   menu item, and then click OK when it  is done and then the page reads as focus is properly passed to it.
As I say. I wondered how come this should be so different in the Alpha snap. I guess I could cobble together a ticket with logs etc, but the look of the logs apart from the  spoken words seems to be the same.
Brian
bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Re: Superantispyware button names no longer read

Ralf Kefferpuetz
 

I can't confirm that. Using latest Win10, latest SuperAntiSpyware and latest NVDA Alpha SuperAntiSpyware reads all
buttons as it did all the time.

Cheers,
Ralf

-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via Groups.Io
Sent: Montag, 9. September 2019 09:26
To: NVDA Dev list on groups.io <nvda-devel@groups.io>
Subject: [nvda-devel] Superantispyware button names no longer read

Hi I may have mentioned this before, but in the Python 3 Alpha branch the buttons mostly say button on thee main page of
this software when focus is moved to it, but on the latest stable the buttons say what they do.
I know this piece of software can be a pain at times, but generally it works
if you launch it from the tray via the update menu item, and then click OK
when it is done and then the page reads as focus is properly passed to it.
As I say. I wondered how come this should be so different in the Alpha snap. I guess I could cobble together a ticket
with logs etc, but the look of the logs apart from the spoken words seems to be the same.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

Re: Superantispyware button names no longer read

Brian's Mail list account
 

This is windows 7, and 2019.2 reads them but not in the alpha snaps, it just says button.
Weird.

Maybe its uia is more capable in 10 than 7, and the fall back does not work so well in apalphas?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Ralf Kefferpuetz" <ralf.kefferpuetz@...>
To: <nvda-devel@groups.io>
Sent: Monday, September 09, 2019 11:48 AM
Subject: Re: [nvda-devel] Superantispyware button names no longer read


I can't confirm that. Using latest Win10, latest SuperAntiSpyware and latest NVDA Alpha SuperAntiSpyware reads all
buttons as it did all the time.

Cheers,
Ralf
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's Mail list account via Groups.Io
Sent: Montag, 9. September 2019 09:26
To: NVDA Dev list on groups.io <nvda-devel@groups.io>
Subject: [nvda-devel] Superantispyware button names no longer read

Hi I may have mentioned this before, but in the Python 3 Alpha branch the buttons mostly say button on thee main page of
this software when focus is moved to it, but on the latest stable the buttons say what they do.
I know this piece of software can be a pain at times, but generally it works
if you launch it from the tray via the update menu item, and then click OK
when it is done and then the page reads as focus is properly passed to it.
As I say. I wondered how come this should be so different in the Alpha snap. I guess I could cobble together a ticket
with logs etc, but the look of the logs apart from the spoken words seems to be the same.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users






Re: Superantispyware button names no longer read

Lukasz Golonka
 

I cannot confirm on Windows 7 x64. NVDA reads all buttons. Have your
tried with a clean config without any add-ons etc?

--
Regards
Lukasz

On Mon, 9 Sep 2019 15:36:03 +0100
"Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io> wrote:

This is windows 7, and 2019.2 reads them but not in the alpha snaps, it just says button.
Weird.

Maybe its uia is more capable in 10 than 7, and the fall back does not work so well in apalphas?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- From: "Ralf Kefferpuetz" <ralf.kefferpuetz@...>
To: <nvda-devel@groups.io>
Sent: Monday, September 09, 2019 11:48 AM
Subject: Re: [nvda-devel] Superantispyware button names no longer read


I can't confirm that. Using latest Win10, latest SuperAntiSpyware and
latest NVDA Alpha SuperAntiSpyware reads all
buttons as it did all the time.

Cheers,
Ralf
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's
Mail list account via Groups.Io
Sent: Montag, 9. September 2019 09:26
To: NVDA Dev list on groups.io <nvda-devel@groups.io>
Subject: [nvda-devel] Superantispyware button names no longer read

Hi I may have mentioned this before, but in the Python 3 Alpha branch the
buttons mostly say button on thee main page of
this software when focus is moved to it, but on the latest stable the
buttons say what they do.
I know this piece of software can be a pain at times, but generally it
works
if you launch it from the tray via the update menu item, and then click
OK
when it is done and then the page reads as focus is properly passed to
it.
As I say. I wondered how come this should be so different in the Alpha
snap. I guess I could cobble together a ticket
with logs etc, but the look of the logs apart from the spoken words seems
to be the same.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users







Re: Superantispyware button names no longer read

Brian's Mail list account
 

Yes did that before.
I'm going to have to find another machine or do a reinstall then.
Another odd thing is that auto update of the snap is not functioning either, even though manual update does work.

Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users

----- Original Message -----
From: "Lukasz Golonka" <wulfryk1@...>
To: <nvda-devel@groups.io>
Sent: Monday, September 09, 2019 4:10 PM
Subject: Re: [nvda-devel] Superantispyware button names no longer read


I cannot confirm on Windows 7 x64. NVDA reads all buttons. Have your
tried with a clean config without any add-ons etc?

--
Regards
Lukasz

On Mon, 9 Sep 2019 15:36:03 +0100
"Brian's Mail list account via Groups.Io" <bglists=blueyonder.co.uk@groups.io> wrote:

This is windows 7, and 2019.2 reads them but not in the alpha snaps, it just says button.
Weird.

Maybe its uia is more capable in 10 than 7, and the fall back does not work so well in apalphas?
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users
----- Original Message ----- From: "Ralf Kefferpuetz" <ralf.kefferpuetz@...>
To: <nvda-devel@groups.io>
Sent: Monday, September 09, 2019 11:48 AM
Subject: Re: [nvda-devel] Superantispyware button names no longer read


I can't confirm that. Using latest Win10, latest SuperAntiSpyware and
latest NVDA Alpha SuperAntiSpyware reads all
buttons as it did all the time.

Cheers,
Ralf
-----Original Message-----
From: nvda-devel@groups.io <nvda-devel@groups.io> On Behalf Of Brian's
Mail list account via Groups.Io
Sent: Montag, 9. September 2019 09:26
To: NVDA Dev list on groups.io <nvda-devel@groups.io>
Subject: [nvda-devel] Superantispyware button names no longer read

Hi I may have mentioned this before, but in the Python 3 Alpha branch the
buttons mostly say button on thee main page of
this software when focus is moved to it, but on the latest stable the
buttons say what they do.
I know this piece of software can be a pain at times, but generally it
works
if you launch it from the tray via the update menu item, and then click
OK
when it is done and then the page reads as focus is properly passed to
it.
As I say. I wondered how come this should be so different in the Alpha
snap. I guess I could cobble together a ticket
with logs etc, but the look of the logs apart from the spoken words seems
to be the same.
Brian

bglists@...
Sent via blueyonder.
Please address personal E-mail to:-
briang1@..., putting 'Brian Gaff'
in the display name field.
Newsgroup monitored: alt.comp.blind-users








Re: WX.Menu item help text: where is it used?

Robert Hänggi
 

I suppose that this text is never used because it is only applicable
for windows that have both, a menu bar and a status line.
That's obviously not the case for a systray icon that has just a bunch of menus.
The top window is actually hidden.
I can't say for sure but I think the status line availability is
defined through the window style attribute.
NVDA doesn't pay much heed to that fact.
Search for instance the status line in NVDA's settings panel (with NVDA+End).
What you get are the buttons and not some kind of informative
description of the item you're focused on (if it were defined in the
first place).
Naturally, it should say that there isn't any status line.
Robert

On 03/09/2019, Noelia Ruiz <nrm1977@...> wrote:
Hi, answering in devel in case lead developers would like to clarify
something or use this discussion for NVDA's improvements.
I think that, in practical terms, the optional help string is never
used by NVDA, never spoken or braillified.
I don't know if this would make sense with the new vision framework,
for instance if this can be highlighted or show in some way.

Cheers

2019-08-30 4:22 GMT+02:00, Luke Davis <luke@...>:
Hello

Perhaps a stupid question, but if I call something like:

gui.mainFrame.sysTrayIcon.preferencesMenu.Append(wx.ID_ANY,
_("&menuItemName..."), _("Some descriptive text"))

where will "Some descriptive text" be used?

WX calls this "help", so I thought I would find it in a mouse hover or
tooltip
of some kind, but in attempting this with both the keyboard and the
actual
mouse, in NVDA 2017.3, I can not get anything spoken.

The docs for WX.Menu 4.1.0 say:

An optional help string associated with the item. By default, the handler
for
the wxEVT_MENU_HIGHLIGHT event
displays this string in the status line.

Which helps me not at all.

Thanks

--
Luke Davis
Moderator: the new NVDA Help mailing list! (NVDAHelp+subscribe@groups.io)
Author: Debug Helper NVDA add-on
(https://github.com/XLTechie/debugHelper)





Errors when using outlook 365.

Andy B.
 

Hi,

 

When I open Outlook 365, I get the following error in the log window:

 

ERROR - RPC process 6260 (nvda_slave.exe) (07:15:05.269):

__main__.main:

slave error

Traceback (most recent call last):

  File "nvda_slave.pyw", line 93, in main

  File "comHelper.pyc", line 22, in _lresultFromGetActiveObject

  File "comtypes\client\__init__.pyc", line 180, in GetActiveObject

  File "comtypes\__init__.pyc", line 1247, in GetActiveObject

  File "_ctypes/callproc.c", line 946, in GetResult

WindowsError: [Error -2147221021] Operation unavailable

 

 

 

Andy Borka

Accessibility Engineer

 

PR with appVeyor build failing

Cyrille
 

Hello

I have submitted a PR for NVDA: #10212.
However the appVeyor build fails with the following message:

vocalizeChangeTracking 97341fe0
Failed 4 hours ago in 1 min 38 sec
Error sending GitHubPullRequest notification: Error commenting on GitHub pull request: {"message":"Validation Failed","errors":[{"resource":"IssueComment","code":"unprocessable","field":"data","message":"Body cannot be blank"}],"documentation_url":"https://developer.github.com/v3/issues/comments/#create-a-comment"}

Any idea what it is due to?
If I need to make modifications, should I push a new commit? Will the PR be updated accordingly?
In this case, do I need to squash the 2 commit or let them independant.

Moreover, new commits have been pushed to master. Should I rebase my branch on master? Or merge master into my branch? (this seconde one seems a bad idea...)

Thanks,

Cyrille