-
-
Notifications
You must be signed in to change notification settings - Fork 30.4k
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
Provide an API in tkSimpleDialog for defining custom validation functions #56932
Comments
tkSimpleDialog.askstring allows empty input. The attached patch adds validation to the input to ensure it is not empty. |
But what if the empty string is valid input? This change would be backward incompatible. I think this should instead be a feature request for exposing _QueryDialog so that you can subclass it and provide your own getresult function. |
What about adding a validatecommand option like on Tkinter.Entry? For what I am trying to do it was sort of a kludge to validate the entry because an empty string was invalid, but in the interface design, it would have been "rude" to validate after the dialog closes and then keep popping up another tkSimpleDialog.askstring until the input is correct. It almost makes askstring useless because I can't validate on close. That wouldn't break backwards compatibility would it? |
Adding an option would also be a reasonable feature request, but I think exposing _QueryDialog would be a more general solution, since it would apply to more than just strings. While not backward incompatible, either of these is a new feature and so can only go into 3.3. |
I'm not sure if I misunderstood you, or you misunderstood me, but adding an option to the askstring dialog that would take a function handle would also allow you to use it for things other than strings (ints,etc.) Tkinter Entry does this: you set the validatecommand option to a function handle that returns true or false to determine whether the input was valid. I will try and code an example over the weekend. |
A bit of both, I think. The current function is actually 'getvalue' and is responsible for retrieving the value, validating its type, and converting to that type (the current ones do both in the same operation). It feels to me like a cleaner interface to decouple retrieval and validation/conversion, so that the validation function gets passed a string and returns the desired type. But in that case, having the string dialog take the validation/coercion function makes the name of the askstring function just wrong. So, I still think the cleaner API is to expose the class and let the application subclass to provide the validation function. |
I think we have to reject this issue. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: