@JopSmith,
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.
