Help with Looping Form.fieldnames to get count

[Fatlipcdn]

Hi all,

I have searched the forum for the answer for this, and have found similar posts, but not quite what I am looking for.

I have a form that submits values likes this: (All dynamically generated)

APEN_INFRACTION_1	0
APEN_INFRACTION_2	0
APEN_INFRACTION_3	0
APEN_INFRACTION_4	0
APEN_INFRACTION_5	0
APEN_INFRACTION_TYPE_1	0
APEN_INFRACTION_TYPE_2	0
APEN_INFRACTION_TYPE_3	0
APEN_INFRACTION_TYPE_4	0
APEN_INFRACTION_TYPE_5	0
APEN_PER_1	1
APEN_PER_2	1
APEN_PER_3	2
APEN_PER_4	0
APEN_PER_5	0
APEN_PLAYER_1	1
APEN_PLAYER_2	1
APEN_PLAYER_3	1
APEN_PLAYER_4	1
APEN_PLAYER_5	1

The problem I am having is that when I am looping to set a value, the count moves beyond the form value that exists in the form.field. Obvioulsy it is looping all form fields, so the count of fields is greater than the form variable I am looking to cfset to something else.

Example, if I loop this with the form values above:

<cfset acount=0>
<cfloop list="#form.fieldnames#" index="apen">
<cfset acount=#acount#+1>   
<cfif isDefined(FORM["APEN_PER_" & #acount#]) AND FORM["APEN_PER_" & #acount#] NEQ ''>
Boo
</cfif>

The loop moves past  "APEN_PER_5" and goes to "APEN_PER_6" which throws an error because it doesn't exist.

I would love to just loop the form field as a list, but for obvious reasons, I can't (or can I?).

Any Ideas how to get the individual column count from the form field in this scenario?

Thanks all,

Greg

[-__cfSearching__-]

<cfloop list="#form.fieldnames#" index="apen">

It is much easier if you store the total number of fields in a hidden form field. Then use that value in a from/to loop

...

</cfloop

[Fatlipcdn]

cfsearching,

The problem is that I could have 60 form rows heading my way, or 3. With what you helped me with on Sunday, I knew how many records I needed to process, in this case I don't.

Thanks!

Greg

[-__cfSearching__-]

I knew how many records I needed to process, in this case I don't.

Oh, okay. I thought you had control over the input form.

[Fatlipcdn]

I wish.. but not in this case. You never know how rowdy these crazy hockey players will get, thus how many penalties will get submitted.

I know there are some javascript ways I can do it, but I will look at that later.

Thanks for all your help. I am making HUGE use of the FORM["text" & #v#] options you helped me with Sunday. What a world that has opened up!

[Fatlipcdn]

Answered my own question with this one.

Just looped the field names and if it contained certain text strings, increased a counter.

<cfset acount=0>
<cfloop list="#form.fieldnames#" index="apen">
    <cfif #apen# CONTAINS "APEN_PER">
    <cfset acount=#acount#+1>
    </cfif>
</cfloop>
<cfoutput>#acount#</cfoutput>

Thanks,

Greg

[-__cfSearching__-]

Is there a reason you cannot just store the number of fields in the first place? Contains should be used with caution, as similar field names can lead to a false positive.

<cfif #apen# CONTAINS "APEN_PER">

<cfset acount=#acount#+1>

BTW: Remove the extra # signs. They are not needed

[Dan_Bracuk]

Regarding:  Is there a reason you cannot just store the number of fields in the first place?

I think it's a bad idea.  It has limited usefulness and has to be changed whenever something else on the form changes.  Looping through formfields is reasonably simple once you get the hang of it.

[-__cfSearching__-]

> It has limited usefulness and has to be changed whenever something else on the form changes.

No. If done properly it is keyed off of a dynamic value. It is not a) hard-coded like the fieldnames method and b) in this scenario the fieldnames method is far more likely to require changes when fields are added.

> I think it's a bad idea.  Looping through formfields is reasonably simple

> once you get the hang of it.

Personally, I think storing a single number is much simpler than depending on a bunch of variable field names/strings. Especially when CONTAINS is used. String comparisons are notoriously error prone, and people often misunderstand how the operator works. Then run into problems when similar field names are added and the result is wrong or unexpected behavior. There is far less room for error in a single numeric comparison. Granted nothing is suitable for every case.