You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Allow -> Than basically allows the overflow and render it way beyond the width of the edittext, which is the way is working right now.
Hide -> With this option it will allow and receive the excesive input, but it will hide it to the eye
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.
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.
The text was updated successfully, but these errors were encountered:
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
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:
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.
The text was updated successfully, but these errors were encountered: