Showing password input constraints

I’m trying to create a password field that has a number of constraints associated with it. As each one is met, I’d like them to be shown in green. I thought I could do this using the Selected state and setting the conditions on the OnTextChange of the input.

If you look at my example project, you can see that it works if there are lowercase or uppercase characters, but not if both are present. Please could someone help me with the logic so that if one or more constraints are met, the appropriate icon and label turn green?


Password Input Constraints.rp (189.7 KB)


There have been some recent threads with similar questions about how to handle password/input validation. These have had kind of inverted logic of needing to show specific error message or tip when the text lacks specific chars (such as no lowercase) as opposed to showing confirmation of meeting constraints. Same basic approach but I came across some interesting “gotchas” when testing the text for these multiple constraints. Your requirements also beg for “undoing the confirmation” if the text is changed by backspacing. For example, entering an uppercase char should select the Constraint 2 group, but if the only uppercase char is later deleted, the Constraint 2 group should be unselected.

You have a good start, but it is better to use the OnKeyUp event to test the password text string. It also helps to understand just what you are testing in your Case conditions, because the logic may likely seem totally backwards. For instance, we don’t have a direct way to test “does this text have at least 1 lowercase character?” but we can test for “does this text contain alphabetical characters which are only uppercase?” and if that fails then the text must have at least 1 lowercase character.

See this updated file for a solution. I copied your page to v2 and applied a series of cases to the OnKeyUp event:
Password Input Constraints.rp (208.8 KB)

To help me test and debug this I added a “debug” case that simply sets the OnLoadVariable to the password text. I could then look at the Console tab in the HTML to see the contents of the password. You can remove this case if you want.
Here are the rest of the Cases:

  • empty tests the length of “widget This” and if “0” sets all constraints to false. Same idea as testing if text is equal to “”.
  • no lowercase tests If [[This.text]] contains [[This.text.toUppercase()]] which means, does the password contain all uppercase chars. Same idea as you had, where [[This.text]] equates to [[LVAR1]] (where LVAR1 is “text on widget This”) --just easier to set up and easier (for me) to read. It is important to understand this case only tests the alpha chars in the string and ignores numbers and special chars. It also tests if ALL the alpha chars are uppercase. If it passes, there must be alpha chars and all are uppercase. If so, the lowercase constraint fails so the selection state Constraint 1 group is set to “false” for “unselected”. For now, that’s all we care about–we will deal with the uppercase constraint later.
  • lowercase char is the opposite of no lowercase so I simply used an “Else If True” case to set selected of Constraint 1 to “true”. It is important to keep this order of cases where no lowercase immediately precedes lowercase char So, this case is only true if no lowercase is false, which means “there are alpha chars but they are not all uppercase, therefore at least one char is lowercase.” It could be that all the chars are lowercase, which is why we are not yet concerned about handling the uppercase constraint.
  • no uppercase is the same approach as no lowercase except we test [[This.text.toLowercase()]] and (now) handle the Constraint 2 group. It is important to note this case is an IF case and not an ELSE IF case.
  • uppercase char is an ELSE IF case so that it is only called if the previous case fails.
  • numbers tests if the text contains any digits in a brute force manner. Using the built-in “alpha-numeric” or “numeric” tests don’t work, because “ab1” and “abc” are both alpha-numeric and “ab1” is not numeric. Important this is an IF case.
  • no numbers is the opposing case and an ELSE IF.
  • special char tests if the text is not alpha-numeric. This means it contains a char that is not alpha and not numeric, or in other words, “special”.
  • no special chars is the opposing case.
  • at least 8 chars simply tests if the length of the text is greater than or equal to 8.
  • less than 8 chars is the opposing case.

Now, I thought it was a little difficult to quickly see the difference between the default black and selected green states for your constraint groups, so I set them to partial opacity as a default. I also noticed you used an SVG for the checkmarks, so I converted those to shapes (right-clicked them) and used a fill color for the selected state. This also improved the quality of the graphics.


@mbc66 This is awesome! Your explanation makes complete sense and is really easy to follow for a newbie like me.

One quick question - the special character constraint is being triggered when the field is empty. Any ideas?

Thanks so much!

Aha. I hadn’t noticed that. Two things for this: Good programming practice is to put your null or default case last in the sequence of validation tests, so that the default condition won’t be “over-written” unnecessarily. Moving the “empty” Case to the bottom seems to fix it. Probably a more (or just as) reliable method is to add a condition to the “special char” Case to test (If text on This is not alpha-numeric and length of widget This is greater than "0") which would mean it will not get triggered when the field is empty.

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.