"Bob Bridges" <rhbridg.RemoveThisNode@xxxxxx> wrote in message
news:42A49137-AF00-4F2B-A699-2777B8B2DEE3@xxxxxx
Quote:
>A few comments:
>
> 1) I didn't realize you could just add the values of fields to a URL; I
> thought I had to get my program to fill in the values of the text boxes,
> drop-down lists etc, and then simulate a click on the correct button. I
> should spend more time in this forum.
Adding field values to a URL is what the browser does in response to the
interactions you have with the mouse and the keyboard. Here, for example, is
the URL generated by a simple GOOGLE search for "look at this":
http://www.google.ca/search?hl=en&q=...e+Search&meta=
You could simply type in those calculated URL's, but it is generally easier
to interact with the GUI interface - unless you are a script.
Quote:
> 2) I've had occasion to automate access to the occasional web page that
> didn't assign names to the fields I wanted, so getElementById wasn't
> avaailable. (In fact, at least one made a point of assigning random names
> with each new invocation; I suppose they wanted to prevent the black hats
> from ruining their site with undesirable automated attacks.
They also want to increase the likelihood that visitors will see (and click
on) ads they have on their page that help pay their bills. Writing a script
to interact with a page is most likely *not* going to click on these links
(although you could consider attempting to add that "feature" to your code).
Quote:
> Thus I've
> developed some methods of getting at some fields (once I've identified
> them)
> by other means than ...ById or ...ByName. In fact I've had to do it often
> enough that I've written a Class and methods for the purpose, though of
> course I'm still tweaking it. If you've had to do this once, it's a
> lead-pipe cinch you'll want to do it again and again; I think you may as
> well
> make up your mind to write your own class to save you time.
Most probably.
Quote:
> 3) One of the ways of getting at fields without a name or ID is to
> navigate
> down the ChildNode tree. But finding an element in the tree, so that
> you'll
> know where to navigate to, is MUCH harder than finding it in the raw HTML
> code - more useful, sometime, but harder. I eventually surrendered to
> inevitability and wrote a method for my class that maps an entire HTML
> document tree - wrote it in VBA/Excel, that being my need at the moment,
> but
> the concept shouldn't be hard to transfer to VBS and text output.
I hinted at the possibility of developing a script-friendly web page DOM,
but I now think it more likely for web page developers to obfuscate the
situation by making it harder to navigate programmatically. Or perhaps some
might publish code for others such as yourself to use that presses the
buttons of their sponsours. Then again, the sponsours might not like to find
out that their buttons are being pushed by scripts that are not likely to
buy their products...
Quote:
> I mention all this partly to solicit comments and partly with an eye to
> exchanging useful code relating to this problem.
Definitely a good idea.
/Al
Quote:
> --- Al Dunbar wrote:
> Most web pages are designed to present the human user an interface with
> visual clues that make it intuitively obvious how to interact with the
> page
> using keyboard and mouse via common controls and navigation standards. You
> could develop two pages that looked and operated exactly the same, but
> using
> completely different HTML coding underneath, so I suspect that James'
> statement that "You will need to look at the source code of the page" is
> right on the money. Not only that, but you might find that internal
> changes
> in the page you are accessing might eventually break your external code.
>
> I wonder if a standard will eventually arise (a document object model
> approach, perhaps) that will make web pages more navigable by external
> script. This could, of course, result in fewer ads being seen, so perhaps
> there are forces working against this approach.
>
> --- "James Whitlow" <jwhitlow.60372693@xxxxxx> wrote: Quote:
>> You will need to look at the source code of the page to determine
>> that.
>> In the example you posted, I right clicked, selected 'View Source' and
>> searched for 'Booking Date:' & then 'Date:' under that. I searched up for
>> 'action' to find the post URL. I then looked at the names of the input
>> fields.... The date field is named 'Date' & the Report radio buttons are
>> named 'report'. Just take the Post URL, add a question mark and then the
>> field names followed by an equal sign and the value you wish to pass.
>> Separate the fields with ampersands. In this case, I added
>> '?Date=082208&report=D' to the end of the Post URL.
>>
>> I am not sure of a way to get the field names other than digging
>> through the HTML source code. There are probably others in the group that
>> can offer you a better way to do this. Firefox 2.x used to provide the
>> fields names in 'View Page Info', but Firefox 3.x does not.
>>
>> If you have trouble with the above, just advise the field names you
>> are
>> looking for and either myself of someone else from the group can probably
>> help you determine them.
> Quote:
>> "LuisE" <legonzales@xxxxxx> wrote: Quote:
>>> ...what should I change if I need to use different fields of the form?