Is your feature request related to a problem? Please describe.

The MessageDialog API added the ability for developers to simply and easily create dialogs in a powerful and extensible way.

A common use case for message dialogs is a warning that should only be shown once, if the user so chooses. This is typically achieved by showing a checkbox in the dialog, labelled something like "Don't show this message again". If the user checks this box, when they dismiss the dialog, a flag is saved to some form of persistent storage, so the program can refrain from showing the dialog next time.

Unfortunately, as implemented, there is no easy way for authors to achieve this pattern, because:

• Callbacks don't take arguments, so they have no access to the event that fired them or the dialog they were fired on.
• Dialogs are destroyed on close, so can't be inspected (from a WX point-of-view).

Describe the solution you'd like

Send a payload when calling callbacks. This could include information such as:

• the event code and Window ID of the window that triggered it (to allow for generic callbacks in future).
• Values of other controls, such as text boxes, if support is added in future.
• Information about dialog state (for instance, a tristate checkbox value: None for no checkbox; True for checked; and False for unchecked).

Add checkboxLabel getters and setters to the dialog, where a value of None means no checkbox, and a string value enables the checkbox.

Potentially cache the checkbox value when closing the dialog, so that code that creates modal dialogs does not have to worry about using a callback to store checkbox state, but can just query the checkbox state of the MessageDialog object.

Describe alternatives you've considered

• Pass self to callbacks when calling them. This exposes us to the callbacks modifying dialog state, which would require us either implementing complex and circumventable logic to freeze the dialog, or implementing logic to deal with dialog state being changed by callbacks.
• Pass the event object to the callback. This exposes us to the same issues as above, but does raise the possibility of callbacks vetoing closing a dialog. This case is probably best handled by allowing callbacks to return False to veto closing, however.
• Only send dialogs the checkbox state. This is a less extensible solution, as it will require further changing callback signatures when further parameters are to be passed.
• Require developers to subclass MessageDialog for this functionality. This arguably goes against the point of the message dialog API.

Additional context

See wx.RichMessageDialog, which allows similar functionality.