Skip to content
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

Add some new "input type" and other additional options for EditText #2222

Open
JoseJohnen opened this issue Apr 9, 2024 · 0 comments
Open
Labels
enhancement New feature or request

Comments

@JoseJohnen
Copy link

Is your feature request related to a problem? Please describe.
I think it's very wastefull not having the option of doing other than input text and hide it, like, for example, if i want an edit text to only receive numbers, i don't have any way to set it for that right now, or if i want it to set the data on a specific way, like dates, i don't have a way to do that out of the box.

Describe the solution you'd like
I would like than EditTexts will have an option to only receive numbers, and maybie other options than allow to limit the input in a similar fashion.

Also an option to stop accepting input when the input cannot be placed within the visible space of the EditText, or maybie a way to control that using options inside the EditText, the options could be:

  1. Allow -> Than basically allows the overflow and render it way beyond the width of the edittext, which is the way is working right now.
  2. Hide -> With this option it will allow and receive the excesive input, but it will hide it to the eye
  3. Disallow -> With this option no matter if you paste or write, it will only receive a certain ammount of characters which is tied to the ammount of characters than are possible to render keeping them inside within the width of the edittext component.
  4. Blocked -> This option disallow all and any type of input.

If this options are done in a way than could be access from code i know they will make the EditText far more flexible and usefull, and will allow it to cover a lot more use cases.

Other good option to have is to have an optional hard limit in the ammount of characters you can have in the edittext, so you can set just a certain ammount of charaters and the EditText will never accept more than that hard limit unless changed, it could be by default -1 (which allow unlimited ammount of characters) and any value equal or bigger than 0 activate the option setting the hard limit to that number, it can be turn off if it's changed back to -1.

It would also be usefull adding an option to forbid certain type of characters, for instance, i may don't want the player authorized to use "[]", "%" or "*" for some reason inside the edittext, for instance because is a name field and the game works online with that name and/or i don't want it to make injections to my database, etc.

In that regards it could also be a good idea if we could add a format in regex or better yet, a dedicated codeblock somewhere to work with the inputs previous to any event so to, for instance, format such input in such a way than i can show it in a better way, alter it in a better way or clean it up if neccesary or disallow it if neccesary for being a forbbiden word etc. But most importantly, allowing this will allow in itself to have a common space to run between all the events before execution of the event itself (or at the start of the same) making the event code far cleaner, more organized and maintanable, that being said, a format option using regex or similar could be enough too.

Describe alternatives you've considered
I speak about that in the section just before this one.

@JoseJohnen JoseJohnen added the enhancement New feature or request label Apr 9, 2024
@JoseJohnen JoseJohnen changed the title Add "content type" and other additional options for EditText Add some new "input type" and other additional options for EditText Apr 9, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant