Skip to content

Conversation

@chaoticgd
Copy link
Member

@chaoticgd chaoticgd commented Nov 24, 2025

Description of Changes

  • Add a AsyncDialogs namespace containing functions designed to replace the static helper functions from the QInputDialog and QMessageBox classes.
  • Update the dialog boxes in the debugger to use these functions instead.

Rationale behind Changes

This brings us one step closer to fixing #13450.

I was a bit reluctant to do this, since I know that asynchronous code is usually harder to read than synchronous code, but after some consideration I've come to the conclusion that this is the only sane way to fix these crashes.

In particular, in the case of the debugger it's not possible to safely block requests to delete the debugger window while a dialog box is open, because that would risk breaking hardcore mode compliance.

Tell me what you think about the API.

Suggested Testing Steps

Test all the dialog boxes in the debugger.

Fixes a crash on exit:

  • Open the debugger.
  • Start big picture mode.
  • Launch a game.
  • Bring up the big picture pause menu with the escape key.
  • In the debugger, right-click on a register to change its value.
  • Enter an invalid hex value. Don't dismiss the error message.
  • From big picture mode, shutdown PCSX2.
  • On master, PCSX2 will crash. With the PR, no crash.

This also fixes a similar crash that happens when hardcore mode is enabled.

Did you use AI to help find, test, or implement this issue or feature?

No.

@TheTechnician27
Copy link
Contributor

TheTechnician27 commented Nov 27, 2025

I'm sure you did your homework before writing 500 lines, but looking through the code, I don't immediately see the benefit of rolling our own versions of these dialog boxes. The Qt documentation, when it warns about exec(), recommends just using the existing ones but asynchronously with open(). This isn't addressed in the PR description and seems to be just taken as a given. Does the Qt implementation simply not work for async somehow? Does this make the call to the message box less messy or such that you don't have to remember to call open() later? Is there an example comparison of what a call would look like with QMessageBox and AsyncDialogs?

@chaoticgd
Copy link
Member Author

chaoticgd commented Nov 27, 2025

I'm sure you did your homework before writing 500 lines, but looking through the code, I don't immediately see the benefit of rolling our own versions of these dialog boxes. The Qt documentation, when it warns about exec(), recommends just using the existing ones but asynchronously with open(). This isn't addressed in the PR description and seems to be just taken as a given. Does the Qt implementation simply not work for async somehow? Does this make the call to the message box less messy or such that you don't have to remember to call open() later? Is there an example comparison of what a call would look like with QMessageBox and AsyncDialogs?

All the built-in Qt functions I'm replacing are helper functions that are hardcoded to use QDialog::exec. If I used QDialog::open directly it would turn one line into five to ten lines, every single time we wanted to popup an error dialog.

In the case of the QMessageBox ones the Qt documentation actually warns us about this.

@chaoticgd
Copy link
Member Author

Is there an example comparison of what a call would look like with QMessageBox and AsyncDialogs?

Yes, the diff of this PR serves as that example. These helpers functions let you replace the built-in Qt ones in a more or less one-to-one fashion. If you want to make a more complex custom message box you should still use QMessageBox directly.

@JordanTheToaster JordanTheToaster added this to the Release 2.8 milestone Dec 5, 2025
@chaoticgd chaoticgd removed the request for review from TheTechnician27 January 1, 2026 00:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants