Hi all:

This is an FMP 5.5 question. I'm using WordCount() to determine how many items are selected from a checkbox field. Everything goes well so long as the user chooses from the list (these are clothing sizes, so the main list is "sm" "med", "lg", "xl", etc.). However, they need to enter custom sizes at times, and there are too many to put in the list. I've just discovered that their syntax for sizes can go like this:

"4", "5/6", "6", where "5/6" is an actual size.

Unfortunately, WordCount() takes that "/" and determines that it is dividing two words. I'm sure that I will discover other strange punctuations (the client is a textile factory), so I want my calculation to keep on top of what they do no matter what, within reason. I think using WordCount() is going to prove my undoing, as I just realized while writing this that someone might type in "Extra Large" and it will count as two words, thus two entries...

Any suggestions?

Thanks

-Stanley

Hi all:

This is an FMP 5.5 question. I'm using WordCount() to determine how many items are selected from a checkbox field. Everything goes well so long as the user chooses from the list (these are clothing sizes, so the main list is "sm" "med", "lg", "xl", etc.). However, they need to enter custom sizes at times, and there are too many to put in the list. I've just discovered that their syntax for sizes can go like this:

"4", "5/6", "6", where "5/6" is an actual size.

Unfortunately, WordCount() takes that "/" and determines that it is dividing two words. I'm sure that I will discover other strange punctuations (the client is a textile factory), so I want my calculation to keep on top of what they do no matter what, within reason. I think using WordCount() is going to prove my undoing, as I just realized while writing this that someone might type in "Extra Large" and it will count as two words, thus two entries...

Any suggestions?

Thanks

-Stanley

Hi all:

This is an FMP 5.5 question. I'm using WordCount() to determine how many items are selected from a checkbox field. Everything goes well so long as the user chooses from the list (these are clothing sizes, so the main list is "sm" "med", "lg", "xl", etc.). However, they need to enter custom sizes at times, and there are too many to put in the list. I've just discovered that their syntax for sizes can go like this:

"4", "5/6", "6", where "5/6" is an actual size.

Unfortunately, WordCount() takes that "/" and determines that it is dividing two words. I'm sure that I will discover other strange punctuations (the client is a textile factory), so I want my calculation to keep on top of what they do no matter what, within reason. I think using WordCount() is going to prove my undoing, as I just realized while writing this that someone might type in "Extra Large" and it will count as two words, thus two entries...

Any suggestions?

Thanks

-Stanley

Can't quite visualize the thing from your description. How about something like:

PatternCount(

Substitute (

StandardSizes & "

Can't quite visualize the thing from your description. How about something like:

PatternCount(

Substitute (

StandardSizes & "

Can't quite visualize the thing from your description. How about something like:

PatternCount(

Substitute (

StandardSizes & "

I suspect you are placing at least 2 unwarranted burdens upon yourself: (1) Trying to limit yourself to using just one field for everything, and (2) Allowing clerks to enter whatever the hell they want.

(I hear this strident voice in the background saying, "This is the way we've done it for 30 years, and this is the way we want to keep doing it.)

they need to enter custom sizes at times, and there are too many to put in the list.

What is 'too many' in the scheme of things? Dozens? Hundreds? Or, to word this differently, is it possible to identify every possible size? If so, why torture the developer (yourself) with trying to guess what the data entry clerk meant?

Put another way, imagine a ballot or survey or even a large columnar menu of options. It is reasonble for them to run down a column clicking on the items they want? No rule says you can't use more than one field to assemble your information, even one or more fields per column; see what I mean?

Say you create 3 columns with a total of 5 categories (only if you need categories) which will result in at least 3 fields (1 per column) OR 5 fields (1 per category). Do NOT give the user the field option of OTHER or EDIT. If you want to process everything en mass, create a calc text field that concatenates the other 3 (or 5) fields together. (In a worst case scenario, if you had thousands instead of dozens of items, you might even have multiple pages.)

Since you have total control over these fields, you also have control whether commas or blanks separate the entries, and you can use PatternCount() to count the number of, say blanks or commas, and therefore deduce the number of entries selected.

HOWEVER

I suspect you are placing at least 2 unwarranted burdens upon yourself: (1) Trying to limit yourself to using just one field for everything, and (2) Allowing clerks to enter whatever the hell they want.

(I hear this strident voice in the background saying, "This is the way we've done it for 30 years, and this is the way we want to keep doing it.)

they need to enter custom sizes at times, and there are too many to put in the list.

What is 'too many' in the scheme of things? Dozens? Hundreds? Or, to word this differently, is it possible to identify every possible size? If so, why torture the developer (yourself) with trying to guess what the data entry clerk meant?

Put another way, imagine a ballot or survey or even a large columnar menu of options. It is reasonble for them to run down a column clicking on the items they want? No rule says you can't use more than one field to assemble your information, even one or more fields per column; see what I mean?

Say you create 3 columns with a total of 5 categories (only if you need categories) which will result in at least 3 fields (1 per column) OR 5 fields (1 per category). Do NOT give the user the field option of OTHER or EDIT. If you want to process everything en mass, create a calc text field that concatenates the other 3 (or 5) fields together. (In a worst case scenario, if you had thousands instead of dozens of items, you might even have multiple pages.)

Since you have total control over these fields, you also have control whether commas or blanks separate the entries, and you can use PatternCount() to count the number of, say blanks or commas, and therefore deduce the number of entries selected.

HOWEVER

I suspect you are placing at least 2 unwarranted burdens upon yourself: (1) Trying to limit yourself to using just one field for everything, and (2) Allowing clerks to enter whatever the hell they want.

(I hear this strident voice in the background saying, "This is the way we've done it for 30 years, and this is the way we want to keep doing it.)

they need to enter custom sizes at times, and there are too many to put in the list.

What is 'too many' in the scheme of things? Dozens? Hundreds? Or, to word this differently, is it possible to identify every possible size? If so, why torture the developer (yourself) with trying to guess what the data entry clerk meant?

Put another way, imagine a ballot or survey or even a large columnar menu of options. It is reasonble for them to run down a column clicking on the items they want? No rule says you can't use more than one field to assemble your information, even one or more fields per column; see what I mean?

Say you create 3 columns with a total of 5 categories (only if you need categories) which will result in at least 3 fields (1 per column) OR 5 fields (1 per category). Do NOT give the user the field option of OTHER or EDIT. If you want to process everything en mass, create a calc text field that concatenates the other 3 (or 5) fields together. (In a worst case scenario, if you had thousands instead of dozens of items, you might even have multiple pages.)

Since you have total control over these fields, you also have control whether commas or blanks separate the entries, and you can use PatternCount() to count the number of, say blanks or commas, and therefore deduce the number of entries selected.

HOWEVER