Validate dialog event (PR #26013)

26 views
Skip to first unread message

RobertRoeb

unread,
Dec 4, 2025, 1:41:38 PM (8 days ago) Dec 4
to wx-...@googlegroups.com, Subscribed
  • This PR is only about the wxDialogValidateEvent commit, ignore the two other fixes
  • Adds wxDialogValidateEvent as an alternative to using Validate() and wxValidator classes
  • Obviously based on an event alone
  • Derived from wxNotifyEvent to allow veto, corresponding to returning false from Validate()
  • Will add docs when name and principle agreed

You can view, comment on, or merge this pull request online at:

  https://github.com/wxWidgets/wxWidgets/pull/26013

Commit Summary

  • dd2efd5 Fix crash when deleting wxTextCtrl in key handler
  • 49088fe Applied Paul C's better patch to prevent GTK wxTextCtrl crash
  • 39038c8 Add wxDialogValidateEvent to inform about the need to validate

File Changes

(5 files)

Patch Links:


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/26013@github.com>

VZ

unread,
Dec 4, 2025, 1:44:19 PM (8 days ago) Dec 4
to wx-...@googlegroups.com, Subscribed
vadz left a comment (wxWidgets/wxWidgets#26013)

Sorry, I didn't even have time to look at this yet, but it would have been really nice to post to wx-dev before adding something like this. We already have so much API in this area that I'd like to see some strong arguments in favour of adding even more to it.


Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/26013/c3613828653@github.com>

RobertRoeb

unread,
Dec 4, 2025, 3:24:44 PM (8 days ago) Dec 4
to wx-...@googlegroups.com, Subscribed
RobertRoeb left a comment (wxWidgets/wxWidgets#26013)

It was impresion that discussions here are more concrete and effective. Either way, as I wrote, we have the validators and I would really like to know if they actually are used. There is also wxInitDialogEvent - not sure when you would need that instead of just adding data during dialog creation, and also something like modal dialog close event and window close event, which other things. I propose an event that would get sent across native and generic dialogs when pressing OK and or some other affirmative button.
And events are easier for language bindings than overriding virtual functions across languages.
wxWidgets does almost everything by events. It should do this as well, I think.


Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/26013/c3614188519@github.com>

VZ

unread,
Dec 4, 2025, 4:00:04 PM (8 days ago) Dec 4
to wx-...@googlegroups.com, Subscribed
vadz left a comment (wxWidgets/wxWidgets#26013)

It was impresion that discussions here are more concrete and effective.

Yes, GitHub PRs are good for discussing the details. But for more high level discussion I think ML is better and it's easier to find threads in its archives (and then follow them to GitHub, as they typically contain references to the PRs, while there are almost never any links in the other direction).

Speaking of details, you really should do git rebase -i origin/master validate_dialog_event and leave only the relevant commit in this branch (and then force push it here).

Either way, as I wrote, we have the validators and I would really like to know if they actually are used.

Yes, extensively.

There is also wxInitDialogEvent - not sure when you would need that instead of just adding data during dialog creation,

I don't know about this one either.

I propose an event that would get sent across native and generic dialogs when pressing OK and or some other affirmative button. And events are easier for language bindings than overriding virtual functions across languages. wxWidgets does almost everything by events. It should do this as well, I think.

Language bindings are a good argument, but in C++ overriding virtual functions is much more convenient. E.g. it allows to call the base class member first, which may be important, while with the events you can only process the event in the derived class and skip it to let the base class have it later.

Anyhow, my fear is that by adding events to the existing mix of virtual functions and validators we risk making things even more confusing as there will be I don't know how many different ways of handling this in a derived class (e.g. "process the event, then skip it to let the base class function use validators for the inherited controls"). Other than language bindings I really don't see a good reason to complicate things further here. I wonder how does wxPython and co handle this now, i.e. do they provide some way of overriding TransferData{To,From}Window() or a replacement mechanism?


Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/26013/c3614298951@github.com>

RobertRoeb

unread,
Dec 10, 2025, 4:42:59 PM (2 days ago) Dec 10
to wx-...@googlegroups.com, Subscribed

Closed #26013.


Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.Message ID: <wxWidgets/wxWidgets/pull/26013/issue_event/21489443013@github.com>

Reply all
Reply to author
Forward
0 new messages