Throwing exceptions for this seems a little odd.
I've always felt that a GUI app should prevent invalid data from even being entered in a control, which can be done using event handlers. For data that is inconsistent between several controls on a form, that should be validated when OK is pressed or whatever, and if the data isn't OK, prevent the form from closing and indicate the error.
The validation can also be done prior to pressing OK, but it shouldn't prevent the data being entered, only indicate the problem (and perhaps disable the OK button until its fixed). Basically, the inconsistent value entered in this control may not be inconsistent once the user has edited the value in the next control he's moving on to.
Try to avoid message boxes for reporting these errors - a status bar or a read-only text control within the form is better.
A function/method should be defined that does all the consistency checks for the form, but it shouldn't throw an exception. Bad input isn't the "exceptional" case from typical users - it happens all the time, especially when I'm the user. More to the point, you should only use exceptions when error-handling would otherwise mess up the structure of your code, which shouldn't be the case in an "is the data in this form OK - yes, fine, accept and close" event handler.
The function should just return an error code to indicate which error to report - or report the error itself and return an error flag.
Not so long ago, wxWidgets wasn't even exception-safe - IIRC, you still have to enable exception-safety as an option when you build the library.