Limit character number in field

[jacque]

It failed because it wasn't concatenating the existing content with the new keypress. The fix was to first check that the key is acceptable (number or dot) and then check whether the existing text combined with the new character met the criteria.

For example, if the field already had "12" in it and you typed "3", the original handler would accept it in all cases, because 3 is both a number and is less than 100. But that would result in "123" which is out of bounds. The new handler checks that it is a number (true) and then looks at it combined with the existing text, resulting in "123" which isn't okay.

[dunbarx]

I have 36 fields, and not all of them have the same limits, so I may have to code them individually. All of them are unlocked and I wished that if the user didn't entered a number within the limits stablished in the code then the field remained empty. In so many fields I think it would be boring or annoying to the user answering to 36

IT is your responsibility to be kind to your users. That is a good thing.

You stay in the card script, and with a single "mouseUp" handler. But as you see already, if the various fields all have their own peculiar needs, then you must deal personally with each of them. So you are looking at a single "switch" construction with possibly a maximum of 36 "case" statements. Fortunately, unlike "if-then" constructions, switch constructions are FAR easier to manage, regardless of their length. And then you need not worry about handlers in any particular field, which will be a godSend. (er, a Godsend?) Anyway, are you familiar with these? Write back if not, and we can give examples. Like the "target" you need this tool in the worst way.

This is not daunting at all, with "switch".

Craig

[jacque]

Rather than list out all possible limits, I'd just set a custom property on each field and the original handler can just check the property rather than a hard coded number. This allows easy changes and fields can be added or deleted without changing the script.

In fact this situation is an ideal candidate for a behavior script.

[dunbarx]

Jacque makes a point, but to me it is a matter of style.

If I have a suite of somewhat similar controls, I would rather see them all listed, perhaps by name, including their peculiar needs, in a switch control structure rather than a custom property within each one. I just feel I can check them out and change them better in that form. This would really be better if there was more than just one simple characteristic of each field.

For example, if it was only a matter of limiting the entry to a range of values, as you first mentioned, then the custom property could hold those values, and a single short handler work its magic as Jacque suggested. Well and good.

But if there were additional limits and issues about that field, in almost any way, then an explicit case statement is likely more readable and manageable. Each case statement contains a "mini" handler that is open to any procedure at all.

But that is up to you.

Craig

[vascoribeiro]

Jacque makes a point, but to me it is a matter of style.

If I have a suite of somewhat similar controls, I would rather see them all listed, perhaps by name, including their peculiar needs, in a switch control structure rather than a custom property within each one. I just feel I can check them out and change them better in that form. This would really be better if there was more than just one simple characteristic of each field.

For example, if it was only a matter of limiting the entry to a range of values, as you first mentioned, then the custom property could hold those values, and a single short handler work its magic as Jacque suggested. Well and good.

But if there were additional limits and issues about that field, in almost any way, then an explicit case statement is likely more readable and manageable. Each case statement contains a "mini" handler that is open to any procedure at all.

But that is up to you.

Craig

Thank you for your answers... I'm having some difficulties understanding the full picture of what you'r trying to tell me, sorry about that. This is due to 2 things: I'm completely new to programming, and english is not my first language
But I get that you may have a solution to a faster and simpler way to code my fields, and that is very interesting because, although I can code them, I tend to loose a lot of time coding each field. (Not to speak searching for ways to do what I want... For example I spent 2 days trying to understand how I could only express a number with 2 decimals)

So... This is one of the cards I have:

LeanLab.jpg.zip

(100.68 KiB) Downloaded 255 times

The upper fields are the ones we are talking about. The others will only show a variety of results based on the input of the user.
the fields on the left have all different limits, for example a flow should be between 0.1 and 10. The fields that are on the right are for time (that I have to think about a limit) and percentages (each line is coded so that the sum have to be 100%). This will calculate how much solution A, B, C and D the user will need to his work, per Injection and to his complete work. I have other cards, and will need to add fields and upgrades to this (for example It would be interesting to have the possibility to calculate automatically how to prepare the solutions mentioned above, having in mind that each one may have a variety of components), but...
This is it for now!

If you could provide one or two code examples I would be very grateful.

And it's never too much to thank all for your answers and patience to noob as I am. I feel very welcome here.

[dunbarx]

Let's start with a simple exercise.

On a new card create three wide fields. Name them "F1","F2" and "F3". In the card script:

Code: Select all

on mouseUp
   if "field" is not in the name of the target then exit to top
   put the short name of the target into tClickedField
   ask "Enter a number"
   
   if it is a number and it >= 0 and it <= 100 then
      switch tClickedField
         case "F1"
            put it && "(simple)" into fld tClickedField
            break
         case "F2"
            put it * 2 && "(doubled)" into fld tClickedField
            break
         case "F3"
             put it ^ 2 && "(squared)" into fld tClickedField
            break
      end switch
   end if
end mouseUp

Click on a field.

Now change the handler in the card script to this:

Code: Select all

on mouseUp
   if "field" is not in the name of the target then exit to top
   put the short name of the target into tClickedField
   ask "Enter data"
   
      switch 
         case tClickedField = "F1" and it is not a number
            put it && "(Entry)" into fld tClickedField
            break
         case tClickedField = "F2" and it is an integer
            put it * 2 && "(doubled)" into fld tClickedField
            break
          case tClickedField = "F3" and it is not an integer
            put it ^ 2 && "(squared)" into fld tClickedField
            break
      end switch
end mouseUp

Click on a field.

Can you see the difference both in the way the two switch control structures are built and also in the different way they are used?

Craig

[vascoribeiro]

Wow, as simple as this!? Fantastic.
This way I understand why the ask command, so we can have the input into a container to be "analysed" by our set of conditions.


I was now testing with my code like this:

Code: Select all

on mouseUp
   if "field" is not in the name of the target then exit to top
   put the short name of the target into tClickedField
   ask "Enter data"
   
   switch 
      case tClickedField = "flow"
         if it is a number and it >= 0.1 and it <= 10 then
            put it into fld "flow"
         end if
         break
      case tClickedField = "timeInj"
         if it is a number and it >= 1 and it <= 180 then
            put it into fld "timeInj"
            end if
            break
      end switch
   end mouseUp

Its just the same as you explained me, with the "if" inside each field in this case (I guess I can't get rid of the "ifs" ). For some reason other locked fields (that I used to identify what the user should put in the fields after them), are also affected by this code even not having "field" in their name.

So, in general I have learned this 2 options: coding in the card with this method or coding directly in the field by a "on keydown pKey"... It's interesting and I think I need to test it out. I may use a combination of the 2 methods.

Thank you very much!

[dunbarx]

Congrats.

"Switch" control structures and "if-then" control structures can be merged together in many ways, but I always try to keep to one or the other. So this:

Code: Select all

 switch 
      case tClickedField = "flow"
         if it is a number and it >= 0.1 and it <= 10 then
            put it into fld "flow"
         end if
         break
    

Might be better as something like:

Code: Select all

 switch 
      case tClickedField = "flow" and it is a number and it >= 0.1 and it <= 10
            put it into fld "flow"
         break
    

Which is more readable to you? Which is more manageable? Which is more easily modified? Especially six months from now.

Craig

[teriibi]

So regarding a text input (instead of a number input) ...

there is no such equivalent to "if not number"..as :
"if not text ..or
"if not letter", right ?

planing on limiting inputs to only letters A...z

the only way to go is refering to Numbers always, right ?

Code: Select all

on keydown pkey
   if pkey is a number and pkey is not in "-" then
      beep
   else
      pass keyDown
   end if
end keydown

[SparkOut]

if pKey is in "abcdefghijklmnopqrstuvwxyz" then...

You can get very granular with LC's text munging and chunk expressions. And regex can be used for many of these tests, making highly specific comparisons in one line.

[dunbarx]

teriibi wrote...

\

there is no such equivalent to "if not number"..as :

Well, you can, sort of, by:

Code: Select all

if yourChar is not in "1234567890" then...

You can do this sort of thing with all the types you mentioned (for example, UPPERCASE letters), and so why not write functions that you put in use in either a stack or a backScript?

The danger, of course, or rather the sloppiness, of such a construct, is that it is far more precise to define a character type than to define what it is not. So if you know it is NOT a number, as per the above, you still know very little about what it actually is. Whereas if you do indeed know it is a number, you know exactly what it is not.

Craig

[teriibi]

okie dokie, getting it !
to be...or "not what to be"
tks

[teriibi]

an easier equivalent way to easely restrict user inputs to just "letters" should be available:

For instance if you d want to limit inputs to just numbers and the symbol "-+" for phone numbers fields etc,
You could write s/t like :

Code: Select all

 if pkey is not a number and pkey is not in "-" then
      beep...

(i.e +1-123-6541-6546)

...if you - would - just want to accept letters for names fields and 1 symbol too ?
You d write similarly :

Code: Select all

 if pkey is not a letter and pkey is not in "-" then
      beep...

(that way you could easely accept sarah-jane,Lloyd-Atkinson, etc...)

but since there is no equivalent..it will requires defining it as this:
if pkey is :
- not a number
+ is in "-"
- is not a symbol "+*/?)([]=/&%$......."
PS: adding :
- is not symbol (ASCII 34)
(that last line just to include double quote symbols)

just so that you can accept "-" but disable all the other symbols that you dont want entered by mistake.

Wouldnt it be much more easier and safer to define "letter" as an equivalent expression to "number" ?

[jacque]

The matchtext() function gives you a great deal of flexibility if you can use regular expressions.

[bogs]

if you can use regular expressions.

...and I believe there is still a regEx builder plugin in the IDE, if you need help building regular expressions, like I sometimes do.