[Tfug] Poor man's GUI

[Bexley Hall]

Hi Don,

On 3/10/2014 5:10 PM, Freeman, Don wrote:
> Suppose you have a dropdown with possible choices. Your user makes a choice
> and then does a saveas and saves it as an htm file. The result files will
> show this:
>
> 	<select name="ctl00$MainContent$DriveAlone_DDL" id="DriveAlone_DDL">
> 	<option value="0">0</option>
> 	<option value="1">1</option>
> 	<option value="2">2</option>
> 	<option selected="selected" value="3">3</option>
> 	<option value="4">4</option>
> 	<option value="5">5</option>
> 	<option value="6">6</option>
> 	<option value="7">7</option>
> 	</select>

Remember, *I* create the original file.  This places constraints on
what the browser can do to it when it "saves" it.

E.g., if my options were A, B, C, D and listed in *that* order,
the browser-saved version can't change them to fred, barney, wilma,
pebbles!

I suspect it can't even change the "option values" assigned to each of
them -- nor should it have reason to do so!

> Which indicates 3 was the selected value. I find it difficult to imagine how
> your application could make sense of this without another step to parse it

Same way *any* library parses HTML.  I.e., the "3" applies to the
choice for *this* "menu control" -- not some other menu control
on the page.

If the browser can't rename the control, then I won't care where it
has moved this control "physically" in the file that it saves -- it
will still have to be present in the form of a "menu control" (I
call controls "widgets").

> out. Another choice would be to write some vbscript that would look at the
> controls and their values and then generate a string that could be saved as
> a text file unencumbered with all the additional clutter.

That's just an added step.  I.e., the same information is present
in the saved HTML file.

You want:

browser.saveas -> vbscript -> textfile -> application

I'm folding "vbscript -> textfile" *into* "application".  I.e.,
let application parse the saved HTML file (instead of your vbscript
doing that) and extracting the settings for each option.

E.g., when it encounters the "DriveAlone_DLL" menu widget in the
HTML, it KNOWS what a menu widget looks like, syntactically.
So, it knows how to find the "selected" entry and store that in:

int DriveAlone_DLL;

(or whatever the application decided to call that "setting", internally)

I'm pretty sure this should work -- *if* the browser (ALL practical
browsers) save files in a known format (so I can craft a parser to
extract the relevant fields:  "control" values).

If a particular browser wants to clutter up the file with lots of
syntactically inert cruft, that's just more characters my parser
will have to "skip over".

Likewise, I am *assuming* the above mentioned issues are invariant...
that the browser can't arbitrarily change stuff from the original
file that would meaningfully alter its *interpretation*.

But, I don't know what contractual agreements the browser(s) *must*
observe.  I'd hate to find each handles this in a very different
manner (e.g., replacing the *invisible* "option value"s in your
example with ROMAN NUMERALS... "Heck, the user doesn't see these
so we can change them at will!")