Seeing it now, and I thank you. I
had always read that explanation to refer to
<select
name="... where multiple is an option, and that
you used
oHtml:getVar() to retrieve
the values of any variable. I have only seen
<input type="... to refer to
NAME-VALUE pairs, which I understood to mean one-to-one. It
wasn't that :getVar() could read an array that surprised me;
it was that
<input> could write an
array.
The fact that the web browser assigns
an array of character strings should be the lead in the story, but,
instead, it was buried at the bottom. I think I know
why. If you are hand coding screens in Frontpage, this array
feature doesn't matter, because you are creating the screen line by
line, even in visual mode, and you give each variable a unique
name. But with the power of WAA and looping code, we are
building big dynamic pages and naming page variables from
almost zero effort. This approach makes a row/column
data browser a piece of cake, a project of ten lines or so.
And it makes gathering in the data and storing it just as easy and
a lot less prone to buggy code. Any
html screen created from more than one record in a dbf can
probably benefit from taking an array approach.