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

A gui.nvdaControls.MessageDialog with default type of standard, should no longer throw a None conversion exception #16223

Merged
merged 1 commit into from Feb 26, 2024

Conversation

XLTechie
Copy link
Contributor

Link to issue number:

None

Summary of the issue:

Using gui.nvdaControls.MessageDialog with standard type (the default), generates this exception:

ERROR - unhandled exception (03:21:22.395) - MainThread (16784):
Traceback (most recent call last):
  File "gui\nvdaControls.pyc", line 335, in _onShowEvt
  File "gui\nvdaControls.pyc", line 294, in _playSound
TypeError: 'NoneType' object cannot be interpreted as an integer

This is happening because there is no sound assigned for standard type dialogs, but the method which plays sound does not check for this. Which, ironically, caused a sound, at least in test builds.

Description of user facing changes

Beta/alpha users will no longer hear an error sound when one of these is used.

Description of development approach

Check whether the int is actually a None, before trying to play the sound. If so, don't play it.

Testing strategy:

TBD

Known issues with pull request:

none

Code Review Checklist:

  • Documentation:
    • Change log entry
    • User Documentation
    • Developer / Technical Documentation
    • Context sensitive help for GUI changes
  • Testing:
    • Unit tests
    • System (end to end) tests
    • Manual testing
  • UX of all users considered:
    • Speech
    • Braille
    • Low Vision
    • Different web browsers
    • Localization in other languages / culture than English
  • API is compatible with existing add-ons.
  • Security precautions taken.

@AppVeyorBot
Copy link

See test results for failed build of commit de6c3c19d3

…longer throws a None conversion exception because no sound is assigned.
@XLTechie XLTechie marked this pull request as ready for review February 26, 2024 07:52
@XLTechie XLTechie requested a review from a team as a code owner February 26, 2024 07:52
@XLTechie XLTechie requested review from seanbudd and removed request for a team February 26, 2024 07:52
Copy link
Member

@seanbudd seanbudd left a comment

Choose a reason for hiding this comment

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

Thanks

@seanbudd seanbudd merged commit 5115dd2 into nvaccess:beta Feb 26, 2024
1 check passed
@nvaccessAuto nvaccessAuto added this to the 2024.2 milestone Feb 26, 2024
@XLTechie XLTechie deleted the fixNoPlaySoundIfNone branch February 27, 2024 00:54
@seanbudd seanbudd modified the milestones: 2024.2, 2024.1 Feb 28, 2024
Adriani90 pushed a commit to Adriani90/nvda that referenced this pull request Mar 13, 2024
…longer throws a None conversion exception because no sound is assigned. (nvaccess#16223)

Summary of the issue:
Using gui.nvdaControls.MessageDialog with standard type (the default), generates this exception:

ERROR - unhandled exception (03:21:22.395) - MainThread (16784):
Traceback (most recent call last):
  File "gui\nvdaControls.pyc", line 335, in _onShowEvt
  File "gui\nvdaControls.pyc", line 294, in _playSound
TypeError: 'NoneType' object cannot be interpreted as an integer
This is happening because there is no sound assigned for standard type dialogs, but the method which plays sound does not check for this. Which, ironically, caused a sound, at least in test builds.

Description of user facing changes
Beta/alpha users will no longer hear an error sound when one of these is used.

Description of development approach
Check whether the int is actually a None, before trying to play the sound. If so, don't play it.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants