I have a <select> object with N <option>s. I want to store the entire list to the (MS SQL) database. The stored procedure will take care of database integrity issues. The exact syntax and what "request.form" objects/properties/methods/etc. that are available eludes me.
I know what I want to do: upon SUBMIT, create a new recordset, put ALL the values from the <select> in it then run an SQL stored procedure (no prob' here) to stuff them into the DB.
I understand the response object receives only those radio button & checkbox values that are "selected" - NOT the complete radio button (checkbox) set ... - I assume this is also true of <select>. If so, easy enough to set the "selected" property in script just prior to SUBMIT.
How do I tell how many <options> I have so I can run a loop? In other words, are the same HTML form object properties & methods availble after the form is passed to the server?
I think I don't want to use "recordsetobject.Update" or it's batch variant. Instead, I use "recordsetobject.execute 'stored_procedure' ". Yes?
For fun, and potential future profit, try to use Javascript (ok, Jscript) instead of VBS in any code samples, se vou plaix.
I'm curious, as to how you get them in the first place?
Since you sound like you don't know exactly what the options are, you could write each one to an array if you're looping through a database to create the <select> element, and then write that array to a hidden field and submit that along with the form...
Quote:
I understand the response object receives only those radio button & checkbox values that are "selected" - NOT the complete radio button (checkbox) set ... - I assume this is also true of <select>. If so, easy enough to set the "selected" property in script just prior to SUBMIT.
Now, for checkboxes with different names, that would work - but of course it wouldn't tell you what the user checked, so I don't see the point. It wouldn't work for radio buttons or select elements, I'd try my idea above, perhaps.
P.S. I still don't understand why you wouldn't KNOW what options you have in your select element?!?
__________________
Former ASP Forum Moderator - I'm back!
If you can teach yourself how to learn, you can learn anything. ;)
P.S. I still don't understand why you wouldn't KNOW what options you have in your select element?!?
The user is adding to a list that starts out empty. When the form is submitted, the list could have zero things or it could have many. It simply depends on what the user entered.
Location: Los Angeles, CA Original Location: Philippines
Posts: 10,241
Thanks: 0
Thanked 112 Times in 111 Posts
I supposed you use javascript to do the adding of options programmatically.
you have 2 ways to do this:
#1:
you can have a hidden textbox that contains the added options separated by a comma or something. then in your submit page:
options = request.form("nameOfHidden")
//split using the delimeter used to make an array
arrOptions = split(options,",")
'do your processing here
#2:
make the select tag multiple-select
<select name="..." multiple>
then before submit, select all options using javascript
then in submit page:
for each item in request.form("nameOfSelect")
response.write item
'do your processing here
next
Quote:
Originally posted by RadarBob
The user is adding to a list that starts out empty. When the form is submitted, the list could have zero things or it could have many. It simply depends on what the user entered.
it will bring all values of the options selected in a list. Then you can split the list and use the UBound function to determine how many items were selected. I always use vbscript so I am not sure what the code is in jscript.
it will bring all values of the options selected in a list. Then you can split the list and use the UBound function to determine how many items were selected. I always use vbscript so I am not sure what the code is in jscript.
OK! Now we're gettin' somewhere. So SELECT behaves like checkboxes and radio buttons; only those things selected get passed in the form.
And UBound will give me the # of elements in an array.
Glenngv;
I want to stay away from "special handling". In other words, SELECT is a list that already "knows" each separate entry in the SELECT list. Likewise with arrays. No special processing to parse the list required. So I want to use the properties and methods build into these objects to the greatest extent possible.
However, from my readings I get the distinct impression that when the form is SUBMITted it becomes a Response.form object. I strongly suspect this is no longer the same form with the same method and property attributes it had when it was an HTML form.
You see? When the data was SUBMITted, it was transform from the "document object model" form in HTML to an "ASP model" form that happens to be a sub-object of the ASP Response object. The question then becomes "how is the Response.form different from the HTML <form>? What properties and methods does it have?.... In a 991 page book on "professional" ASP they don't say squat about it.
The Form is not a sub-object. It is just a collection of whatever values were submitted via the post method. The link above will gives you all the form collection properties.
I am not sure what else you would want to do with a <form> server side besides read whatever post data is submitted. What are you looking for it to do?
Before you post, read our: 
how to: Store all <option>s of a <select> object
Now we're gettin' somewhere. So SELECT behaves like checkboxes and radio buttons; only those things selected get passed in the form. 
