Limiting number of characters in a field


#1

I can do this by checking the content with a procedure after I exit. Or I can ascertain the window/field in a Case structure in a .KeyDown procedure and cobble something up there.

I like to avoid .KeyDown because it bothers me that I’m adding “overhead” to every keystroke.

But there are so many filters already available as data cell “specs” - All Caps, numeric or date, restricted characters, etc. that it seems natural to also - in the same place - be able to specify the maximum number or characters? I guess also the minimum number of characters would be as useful. So that would be two check boxes and fields in attributes; max characters and min characters.

It also seems there are only three basic actions you’d want to take - return to the field with the insertion bar at the front, return to the field with the insertion bar at the back, return to the field with all the content selected.

But you wouldn’t want the user trapped. That is, if you return the user to the field if she leaves it in an invalid state, she may get “trapped”. Let’s say someone clicks into an inventory stock no field and then realizes they don’t have that number just yet. If they click out to another field, and a procedure kicks in determining the field they left didn’t have valid content, and it returns them to said field, then you’d imagine they’d start humming the song, "The Man Who’ll Never Return (to the other database fields) https://www.youtube.com/watch?v=Dh994JcEfkI

I can do the character checking inside my own procedures but I’m wondering if I’m missing something “built-in” to the field attributes in Pan 6 that would do it.

If those character limits are not built into PanX, they’d be a great addition because a “spec” on the number of characters in a field, blends nicely with the other restrictions/auto settings (all caps, etc.) already there.


#2

The “auto” procedure I meant was .KeyDown


#3

Maximum # of characters is straightforward – just prevent extra characters from being typed in.

Minimum # is tricky – what do you do if the number of characters entered is less than the minimum? You can’t lock the user out of the rest of the program until they type enough characters! So perhaps just a warning. This is similar to the problem of what to do if the field doesn’t allow unique or duplicate values – whatever solution is decided on there could work for this also. See issue #167.

I have filed a Bitbucket issue on this: Issue 508


#4

I had a further thought on this. It would be really cool if you could specify a regular expression that must be matched for valid input. This would allow both minimum and max to be implemented, or more complicated stuff like email addresses, must start with a letter, etc. I’ve updated the Bitbucket issue with this suggestion (but this won’t happen for quite a while).


#5

Jim,

This requirement came about because a user said he wanted a five digit
stock number in a field. BUT - as often happens when people start out
with another database - his original data has thousands of exceptions -
entries with more or less than five and even alpha characters; it’s a
messy world.

I was thinking a “feature” would stop him with a beep if a sixth
character were entered in the field. But as you surmised it gets more
difficult if you require a minium number because people start stuff with
imperfect data. I’m guess a warning is better that trapping him/her in
the field until they satisfy conditions.

Paul
QuickData