Topics

Errors with Magix Sound forge #addontesting


Tom Kingston
 

Hi,

I'm a Window-Eyes user and script writer. I'm migrating to NVDA and discovered the following while writing an add-on for Magix (previously Sony's) Sound forge Pro mastering suite, which I wrote the Window-Eyes script for. This is on Windows 10 64-bit. The new version of Sound forge is also 64-bit. But that's about the only change. That is to say, I only had to make a few trivial changes in my Window-Eyes script for the previous version to keep it running fine.

No code I place in overlay classes will execute. I stripped it down to the simplest of tasks and that made no difference. I look at the DevInfo and my class is there under Python object and Python class mro. If I copy and paste the same code, e.g. event_nameChange into the main app module and comment out the overlay it runs fine.

I've tried to solve two different problems. For example, when I open the program NVDA+End reads the status bar fine. But if I do anything, even so much as open a menu and escape out of it, I then get either the line above the status bar or some other random snippet of text. I tried to work this out with no luck. Although I didn't spend a lot of time on it. Then I decided to try a processing window. I did spend considerable time on this. I landed in a similar situation.

I do know that Magix overhauled the accessibility implementation. NVDA presents the window differently than Window-Eyes. With either I come in on a Presets combo-box. I Tab and with Window-Eyes it is a series of sliders and edit boxes, with a few check boxes and buttons. The edit boxes reflect the values of presets and changes made with the sliders. With NVDA some of the sliders are gone and the edit boxes do the job of both: a value can be entered, and arrowing up and down changes the control value. However these changes are not reflected in the edit boxes. They remain empty. Hence my use of event_nameChange. This also eliminates the reading of all preset values.

Here, from the debug log, is what I assume to be the crux of the matter. Prior to running Sound forge I disabled all add-ons and removed the few I've written from the scratchpad folder.

DEBUGWARNING - watchdog._watcher (16:38:27.815):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 233, in <module>
File "core.pyo", line 519, in main
File "wx\core.pyo", line 2134, in MainLoop
File "gui\__init__.pyo", line 1003, in Notify
File "core.pyo", line 489, in run
File "IAccessibleHandler.pyo", line 900, in pumpAll
File "IAccessibleHandler.pyo", line 757, in processForegroundWinEvent
File "IAccessibleHandler.pyo", line 532, in winEventToNVDAEvent
File "NVDAObjects\IAccessible\__init__.pyo", line 40, in getNVDAObjectFromEvent
File "IAccessibleHandler.pyo", line 342, in accessibleObjectFromEvent
File "oleacc.pyo", line 265, in AccessibleObjectFromEvent

DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (16:38:27.862):
oleacc.AccessibleObjectFromEvent with window 393784, objectID -4 and childID 0: [Error -2147024809] The parameter is incorrect
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:38:27.871):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole (16:38:27.874):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None, None, None, 0, None))

Any suggestions will be greatly appreciated.

Regards,
Tom


Tom Kingston
 

Here's another observation I forgot to mention.
When I'm in the main Sound forge window and open the Python console I can step up through the parents of the focus window to the desktop. But when I'm in the processor window I can only step up one level to the field name. beyond that they're all None. Conversely, with the Window-Eyes equivalent for VBScript I can step up to the desktop, regardless of where I am.
Perhaps this is part of the problem?
Thanks,
Tom

On Sat, Apr 27, 2019 at 06:05 PM, Tom Kingston wrote:


Hi,

I'm a Window-Eyes user and script writer. I'm migrating to NVDA and
discovered the following while writing an add-on for Magix (previously
Sony's) Sound forge Pro mastering suite, which I wrote the Window-Eyes
script for. This is on Windows 10 64-bit. The new version of Sound forge
is also 64-bit. But that's about the only change. That is to say, I only
had to make a few trivial changes in my Window-Eyes script for the
previous version to keep it running fine.

No code I place in overlay classes will execute. I stripped it down to
the simplest of tasks and that made no difference. I look at the DevInfo
and my class is there under Python object and Python class mro. If I
copy and paste the same code, e.g. event_nameChange into the main app
module and comment out the overlay it runs fine.

I've tried to solve two different problems. For example, when I open the
program NVDA+End reads the status bar fine. But if I do anything, even
so much as open a menu and escape out of it, I then get either the line
above the status bar or some other random snippet of text. I tried to
work this out with no luck. Although I didn't spend a lot of time on it.
Then I decided to try a processing window. I did spend considerable time
on this. I landed in a similar situation.

I do know that Magix overhauled the accessibility implementation. NVDA
presents the window differently than Window-Eyes. With either I come in
on a Presets combo-box. I Tab and with Window-Eyes it is a series of
sliders and edit boxes, with a few check boxes and buttons. The edit
boxes reflect the values of presets and changes made with the sliders.
With NVDA some of the sliders are gone and the edit boxes do the job of
both: a value can be entered, and arrowing up and down changes the
control value. However these changes are not reflected in the edit
boxes. They remain empty. Hence my use of event_nameChange. This also
eliminates the reading of all preset values.

Here, from the debug log, is what I assume to be the crux of the matter.
Prior to running Sound forge I disabled all add-ons and removed the few
I've written from the scratchpad folder.

DEBUGWARNING - watchdog._watcher (16:38:27.815):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 233, in <module>
File "core.pyo", line 519, in main
File "wx\core.pyo", line 2134, in MainLoop
File "gui\__init__.pyo", line 1003, in Notify
File "core.pyo", line 489, in run
File "IAccessibleHandler.pyo", line 900, in pumpAll
File "IAccessibleHandler.pyo", line 757, in processForegroundWinEvent
File "IAccessibleHandler.pyo", line 532, in winEventToNVDAEvent
File "NVDAObjects\IAccessible\__init__.pyo", line 40, in
getNVDAObjectFromEvent
File "IAccessibleHandler.pyo", line 342, in accessibleObjectFromEvent
File "oleacc.pyo", line 265, in AccessibleObjectFromEvent

DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (16:38:27.862):
oleacc.AccessibleObjectFromEvent with window 393784, objectID -4 and
childID 0: [Error -2147024809] The parameter is incorrect
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
(16:38:27.871):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
(16:38:27.874):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
None, None, 0, None))

Any suggestions will be greatly appreciated.

Regards,
Tom


derek riemer
 

That shouldn't be happening. You shouldn't be able to not get to the desktop object. Can you send a message to nvda-devel as well? The core developers monitor that.


On Sat, Apr 27, 2019 at 4:46 PM Tom Kingston <tom.kingston@...> wrote:
Here's another observation I forgot to mention.
When I'm in the main Sound forge window and open the Python console I can step up through the parents of the focus window to the desktop. But when I'm in the processor window I can only step up one level to the field name. beyond that they're all None. Conversely, with the Window-Eyes equivalent for VBScript I can step up to the desktop, regardless of where I am.
Perhaps this is part of the problem?
Thanks,
Tom


On Sat, Apr 27, 2019 at 06:05 PM, Tom Kingston wrote:

>
> Hi,
>
> I'm a Window-Eyes user and script writer. I'm migrating to NVDA and
> discovered the following while writing an add-on for Magix (previously
> Sony's) Sound forge Pro mastering suite, which I wrote the Window-Eyes
> script for. This is on Windows 10 64-bit. The new version of Sound forge
> is also 64-bit. But that's about the only change. That is to say, I only
> had to make a few trivial changes in my Window-Eyes script for the
> previous version to keep it running fine.
>
> No code I place in overlay classes will execute. I stripped it down to
> the simplest of tasks and that made no difference. I look at the DevInfo
> and my class is there under Python object and Python class mro. If I
> copy and paste the same code, e.g. event_nameChange into the main app
> module and comment out the overlay it runs fine.
>
> I've tried to solve two different problems. For example, when I open the
> program NVDA+End reads the status bar fine. But if I do anything, even
> so much as open a menu and escape out of it, I then get either the line
> above the status bar or some other random snippet of text. I tried to
> work this out with no luck. Although I didn't spend a lot of time on it.
> Then I decided to try a processing window. I did spend considerable time
> on this. I landed in a similar situation.
>
> I do know that Magix overhauled the accessibility implementation. NVDA
> presents the window differently than Window-Eyes. With either I come in
> on a Presets combo-box. I Tab and with Window-Eyes it is a series of
> sliders and edit boxes, with a few check boxes and buttons. The edit
> boxes reflect the values of presets and changes made with the sliders.
> With NVDA some of the sliders are gone and the edit boxes do the job of
> both: a value can be entered, and arrowing up and down changes the
> control value. However these changes are not reflected in the edit
> boxes. They remain empty. Hence my use of event_nameChange. This also
> eliminates the reading of all preset values.
>
> Here, from the debug log, is what I assume to be the crux of the matter.
> Prior to running Sound forge I disabled all add-ons and removed the few
> I've written from the scratchpad folder.
>
> DEBUGWARNING - watchdog._watcher (16:38:27.815):
> Trying to recover from freeze, core stack:
>    File "nvda.pyw", line 233, in <module>
>    File "core.pyo", line 519, in main
>    File "wx\core.pyo", line 2134, in MainLoop
>    File "gui\__init__.pyo", line 1003, in Notify
>    File "core.pyo", line 489, in run
>    File "IAccessibleHandler.pyo", line 900, in pumpAll
>    File "IAccessibleHandler.pyo", line 757, in processForegroundWinEvent
>    File "IAccessibleHandler.pyo", line 532, in winEventToNVDAEvent
>    File "NVDAObjects\IAccessible\__init__.pyo", line 40, in
> getNVDAObjectFromEvent
>    File "IAccessibleHandler.pyo", line 342, in accessibleObjectFromEvent
>    File "oleacc.pyo", line 265, in AccessibleObjectFromEvent
>
> DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent (16:38:27.862):
> oleacc.AccessibleObjectFromEvent with window 393784, objectID -4 and
> childID 0: [Error -2147024809] The parameter is incorrect
> DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
> (16:38:27.871):
> accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
> None, None, 0, None))
> DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
> (16:38:27.874):
> accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
> None, None, 0, None))
>
> Any suggestions will be greatly appreciated.
>
> Regards,
> Tom
>





--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com





Brian's Mail list account
 

Not technical enough to do other than observe here, but that error log is one I often see when nvda goes very sluggish on a particular window.
Its as if something is swamped by data and locks the processor core up and nothing happens till everything sorts itself out.
Brian

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

----- Original Message -----
From: "derek riemer" <driemer.riemer@...>
To: <nvda-addons@nvda-addons.groups.io>
Sent: Sunday, April 28, 2019 4:44 AM
Subject: Re: [nvda-addons] Errors with Magix Sound forge #addontesting


That shouldn't be happening. You shouldn't be able to not get to the
desktop object. Can you send a message to nvda-devel as well? The core
developers monitor that.

On Sat, Apr 27, 2019 at 4:46 PM Tom Kingston <tom.kingston@...>
wrote:

Here's another observation I forgot to mention.
When I'm in the main Sound forge window and open the Python console I can
step up through the parents of the focus window to the desktop. But when
I'm in the processor window I can only step up one level to the field name.
beyond that they're all None. Conversely, with the Window-Eyes equivalent
for VBScript I can step up to the desktop, regardless of where I am.
Perhaps this is part of the problem?
Thanks,
Tom


On Sat, Apr 27, 2019 at 06:05 PM, Tom Kingston wrote:


Hi,

I'm a Window-Eyes user and script writer. I'm migrating to NVDA and
discovered the following while writing an add-on for Magix (previously
Sony's) Sound forge Pro mastering suite, which I wrote the Window-Eyes
script for. This is on Windows 10 64-bit. The new version of Sound forge
is also 64-bit. But that's about the only change. That is to say, I only
had to make a few trivial changes in my Window-Eyes script for the
previous version to keep it running fine.

No code I place in overlay classes will execute. I stripped it down to
the simplest of tasks and that made no difference. I look at the DevInfo
and my class is there under Python object and Python class mro. If I
copy and paste the same code, e.g. event_nameChange into the main app
module and comment out the overlay it runs fine.

I've tried to solve two different problems. For example, when I open the
program NVDA+End reads the status bar fine. But if I do anything, even
so much as open a menu and escape out of it, I then get either the line
above the status bar or some other random snippet of text. I tried to
work this out with no luck. Although I didn't spend a lot of time on it.
Then I decided to try a processing window. I did spend considerable time
on this. I landed in a similar situation.

I do know that Magix overhauled the accessibility implementation. NVDA
presents the window differently than Window-Eyes. With either I come in
on a Presets combo-box. I Tab and with Window-Eyes it is a series of
sliders and edit boxes, with a few check boxes and buttons. The edit
boxes reflect the values of presets and changes made with the sliders.
With NVDA some of the sliders are gone and the edit boxes do the job of
both: a value can be entered, and arrowing up and down changes the
control value. However these changes are not reflected in the edit
boxes. They remain empty. Hence my use of event_nameChange. This also
eliminates the reading of all preset values.

Here, from the debug log, is what I assume to be the crux of the matter.
Prior to running Sound forge I disabled all add-ons and removed the few
I've written from the scratchpad folder.

DEBUGWARNING - watchdog._watcher (16:38:27.815):
Trying to recover from freeze, core stack:
File "nvda.pyw", line 233, in <module>
File "core.pyo", line 519, in main
File "wx\core.pyo", line 2134, in MainLoop
File "gui\__init__.pyo", line 1003, in Notify
File "core.pyo", line 489, in run
File "IAccessibleHandler.pyo", line 900, in pumpAll
File "IAccessibleHandler.pyo", line 757, in processForegroundWinEvent
File "IAccessibleHandler.pyo", line 532, in winEventToNVDAEvent
File "NVDAObjects\IAccessible\__init__.pyo", line 40, in
getNVDAObjectFromEvent
File "IAccessibleHandler.pyo", line 342, in accessibleObjectFromEvent
File "oleacc.pyo", line 265, in AccessibleObjectFromEvent

DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent
(16:38:27.862):
oleacc.AccessibleObjectFromEvent with window 393784, objectID -4 and
childID 0: [Error -2147024809] The parameter is incorrect
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
(16:38:27.871):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
None, None, 0, None))
DEBUGWARNING - NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
(16:38:27.874):
accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
None, None, 0, None))

Any suggestions will be greatly appreciated.

Regards,
Tom


--
Derek Riemer
Improving the world one byte at a time! ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁
⠐⠞⠖
• Accessibility enthusiast.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Skier.

• Personal website: https://derekriemer.com


Tom Kingston
 

Sure. I'll do that. But I checked with Magix last night and they've released a new version. So just for the heck of it I'll do a clean install of that first to see if by any chance things have changed.

Regards,
Tom

On 4/27/2019 11:44 PM, derek riemer wrote:
That shouldn't be happening. You shouldn't be able to not get to the desktop object. Can you send a message to nvda-devel as well? The core developers monitor that.
On Sat, Apr 27, 2019 at 4:46 PM Tom Kingston <tom.kingston@... <mailto:tom.kingston@...>> wrote:
Here's another observation I forgot to mention.
When I'm in the main Sound forge window and open the Python console
I can step up through the parents of the focus window to the
desktop. But when I'm in the processor window I can only step up one
level to the field name. beyond that they're all None. Conversely,
with the Window-Eyes equivalent for VBScript I can step up to the
desktop, regardless of where I am.
Perhaps this is part of the problem?
Thanks,
Tom
On Sat, Apr 27, 2019 at 06:05 PM, Tom Kingston wrote:

>
> Hi,
>
> I'm a Window-Eyes user and script writer. I'm migrating to NVDA and
> discovered the following while writing an add-on for Magix
(previously
> Sony's) Sound forge Pro mastering suite, which I wrote the
Window-Eyes
> script for. This is on Windows 10 64-bit. The new version of
Sound forge
> is also 64-bit. But that's about the only change. That is to say,
I only
> had to make a few trivial changes in my Window-Eyes script for the
> previous version to keep it running fine.
>
> No code I place in overlay classes will execute. I stripped it
down to
> the simplest of tasks and that made no difference. I look at the
DevInfo
> and my class is there under Python object and Python class mro. If I
> copy and paste the same code, e.g. event_nameChange into the main
app
> module and comment out the overlay it runs fine.
>
> I've tried to solve two different problems. For example, when I
open the
> program NVDA+End reads the status bar fine. But if I do anything,
even
> so much as open a menu and escape out of it, I then get either
the line
> above the status bar or some other random snippet of text. I
tried to
> work this out with no luck. Although I didn't spend a lot of time
on it.
> Then I decided to try a processing window. I did spend
considerable time
> on this. I landed in a similar situation.
>
> I do know that Magix overhauled the accessibility implementation.
NVDA
> presents the window differently than Window-Eyes. With either I
come in
> on a Presets combo-box. I Tab and with Window-Eyes it is a series of
> sliders and edit boxes, with a few check boxes and buttons. The edit
> boxes reflect the values of presets and changes made with the
sliders.
> With NVDA some of the sliders are gone and the edit boxes do the
job of
> both: a value can be entered, and arrowing up and down changes the
> control value. However these changes are not reflected in the edit
> boxes. They remain empty. Hence my use of event_nameChange. This
also
> eliminates the reading of all preset values.
>
> Here, from the debug log, is what I assume to be the crux of the
matter.
> Prior to running Sound forge I disabled all add-ons and removed
the few
> I've written from the scratchpad folder.
>
> DEBUGWARNING - watchdog._watcher (16:38:27.815):
> Trying to recover from freeze, core stack:
>    File "nvda.pyw", line 233, in <module>
>    File "core.pyo", line 519, in main
>    File "wx\core.pyo", line 2134, in MainLoop
>    File "gui\__init__.pyo", line 1003, in Notify
>    File "core.pyo", line 489, in run
>    File "IAccessibleHandler.pyo", line 900, in pumpAll
>    File "IAccessibleHandler.pyo", line 757, in
processForegroundWinEvent
>    File "IAccessibleHandler.pyo", line 532, in winEventToNVDAEvent
>    File "NVDAObjects\IAccessible\__init__.pyo", line 40, in
> getNVDAObjectFromEvent
>    File "IAccessibleHandler.pyo", line 342, in
accessibleObjectFromEvent
>    File "oleacc.pyo", line 265, in AccessibleObjectFromEvent
>
> DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent
(16:38:27.862):
> oleacc.AccessibleObjectFromEvent with window 393784, objectID -4 and
> childID 0: [Error -2147024809] The parameter is incorrect
> DEBUGWARNING -
NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
> (16:38:27.871):
> accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
> None, None, 0, None))
> DEBUGWARNING -
NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
> (16:38:27.874):
> accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
> None, None, 0, None))
>
> Any suggestions will be greatly appreciated.
>
> Regards,
> Tom
>
--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.
•    Personal website: https://derekriemer.com


Tom Kingston
 

I'm preparing my message for the nvda-devel group and wanted to know if the following is a known bug. When I step up through parents every two steps returns a result for the same object. To clarify here's a brief test from the Python console I've done in Sound forge, Notepad, Notepad++, and Thunderbird.
print True if focus.windowHandle == focus.parent.windowHandle and focus.parent.parent.windowHandle == focus.parent.parent.parent.windowHandle else False
The result is always True.

Thanks,
Tom

On 4/28/2019 3:54 PM, Tom Kingston wrote:
Sure. I'll do that. But I checked with Magix last night and they've released a new version. So just for the heck of it I'll do a clean install of that first to see if by any chance things have changed.
Regards,
Tom
On 4/27/2019 11:44 PM, derek riemer wrote:
That shouldn't be happening. You shouldn't be able to not get to the desktop object. Can you send a message to nvda-devel as well? The core developers monitor that.

On Sat, Apr 27, 2019 at 4:46 PM Tom Kingston <tom.kingston@... <mailto:tom.kingston@...>> wrote:

    Here's another observation I forgot to mention.
    When I'm in the main Sound forge window and open the Python console
    I can step up through the parents of the focus window to the
    desktop. But when I'm in the processor window I can only step up one
    level to the field name. beyond that they're all None. Conversely,
    with the Window-Eyes equivalent for VBScript I can step up to the
    desktop, regardless of where I am.
    Perhaps this is part of the problem?
    Thanks,
    Tom


    On Sat, Apr 27, 2019 at 06:05 PM, Tom Kingston wrote:

     >
     > Hi,
     >
     > I'm a Window-Eyes user and script writer. I'm migrating to NVDA and
     > discovered the following while writing an add-on for Magix
    (previously
     > Sony's) Sound forge Pro mastering suite, which I wrote the
    Window-Eyes
     > script for. This is on Windows 10 64-bit. The new version of
    Sound forge
     > is also 64-bit. But that's about the only change. That is to say,
    I only
     > had to make a few trivial changes in my Window-Eyes script for the
     > previous version to keep it running fine.
     >
     > No code I place in overlay classes will execute. I stripped it
    down to
     > the simplest of tasks and that made no difference. I look at the
    DevInfo
     > and my class is there under Python object and Python class mro. If I
     > copy and paste the same code, e.g. event_nameChange into the main
    app
     > module and comment out the overlay it runs fine.
     >
     > I've tried to solve two different problems. For example, when I
    open the
     > program NVDA+End reads the status bar fine. But if I do anything,
    even
     > so much as open a menu and escape out of it, I then get either
    the line
     > above the status bar or some other random snippet of text. I
    tried to
     > work this out with no luck. Although I didn't spend a lot of time
    on it.
     > Then I decided to try a processing window. I did spend
    considerable time
     > on this. I landed in a similar situation.
     >
     > I do know that Magix overhauled the accessibility implementation.
    NVDA
     > presents the window differently than Window-Eyes. With either I
    come in
     > on a Presets combo-box. I Tab and with Window-Eyes it is a series of
     > sliders and edit boxes, with a few check boxes and buttons. The edit
     > boxes reflect the values of presets and changes made with the
    sliders.
     > With NVDA some of the sliders are gone and the edit boxes do the
    job of
     > both: a value can be entered, and arrowing up and down changes the
     > control value. However these changes are not reflected in the edit
     > boxes. They remain empty. Hence my use of event_nameChange. This
    also
     > eliminates the reading of all preset values.
     >
     > Here, from the debug log, is what I assume to be the crux of the
    matter.
     > Prior to running Sound forge I disabled all add-ons and removed
    the few
     > I've written from the scratchpad folder.
     >
     > DEBUGWARNING - watchdog._watcher (16:38:27.815):
     > Trying to recover from freeze, core stack:
     >    File "nvda.pyw", line 233, in <module>
     >    File "core.pyo", line 519, in main
     >    File "wx\core.pyo", line 2134, in MainLoop
     >    File "gui\__init__.pyo", line 1003, in Notify
     >    File "core.pyo", line 489, in run
     >    File "IAccessibleHandler.pyo", line 900, in pumpAll
     >    File "IAccessibleHandler.pyo", line 757, in
    processForegroundWinEvent
     >    File "IAccessibleHandler.pyo", line 532, in winEventToNVDAEvent
     >    File "NVDAObjects\IAccessible\__init__.pyo", line 40, in
     > getNVDAObjectFromEvent
     >    File "IAccessibleHandler.pyo", line 342, in
    accessibleObjectFromEvent
     >    File "oleacc.pyo", line 265, in AccessibleObjectFromEvent
     >
     > DEBUGWARNING - IAccessibleHandler.accessibleObjectFromEvent
    (16:38:27.862):
     > oleacc.AccessibleObjectFromEvent with window 393784, objectID -4 and
     > childID 0: [Error -2147024809] The parameter is incorrect
     > DEBUGWARNING -
    NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
     > (16:38:27.871):
     > accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
     > None, None, 0, None))
     > DEBUGWARNING -
    NVDAObjects.IAccessible.IAccessible._get_IAccessibleRole
     > (16:38:27.874):
     > accRole failed: (-2147024809, 'The parameter is incorrect.', (None,
     > None, None, 0, None))
     >
     > Any suggestions will be greatly appreciated.
     >
     > Regards,
     > Tom
     >





--
Derek Riemer
Improving the world one byte at a time!        ⠠⠊⠍⠏⠗⠕⠧⠬ ⠮ ⠸⠺ ⠐⠕ ⠃⠽⠞⠑ ⠁⠞ ⠁ ⠐⠞⠖
•    Accessibility enthusiast.
•    Proud user of the NVDA screen reader.
•    Open source enthusiast.
•    Skier.

•    Personal website: https://derekriemer.com