Adding VBscript to onclick Event

[CrimsonDiva]

Hi,

I'm trying to make an entry into a logfile whenever a user tries to download a PDF from my site. This is the code that I have right now (which is, of course, not working):

<A HREF=&quot;docs/myfile.pdf&quot; onClick=&quot;<%=Call LogHit(&quot;/private/reports/ama&quot%>&quot;> View PDF</A>


LogHit is a function written in vbScript. Is there a way to call this vbScript function in an onclick Event Handler?

 

[Tarwn]

That function is an ASP function. ASP code processes Server-side and then sends the results to the user. By the time the body onLoad event is just starting to fire, the server is already done processing the ASP script and is deallocating the memory that was used.
There is no connection between the client and the server, so there is never really any way to call a client-side script from the server or a server-side script from the client. The server processes it's script which creates output. That output is sent to the client. The client processes what it received. If the client needs another page, the send a query to the server and the server starts creating another page.
What you could do is have an ASP file that you could pass it the name of the PDF you want. It would then log that pdf file and Response.Redirect to the file so that the client would rceeive the file, but the server would still have a chance to log it.

-Tarwn [sub]01010100 01101001 01100101 01110010 01101110 01101111 01101011 00101110 01100011 01101111 01101101 [/sub]
[sup]29 3K 10 3D 3L 3J 3K 10 32 35 10 3E 39 33 35 10 3K 3F 10 38 31 3M 35 10 36 3I 35 35 10 3K 39 3D 35 10 1Q 19[/sup]
Get better results for your questions: faq333-2924
Frequently Asked ASP Questions: faq333-3048

 

[dilettante]

Not picking on you CrimsonDiva, but people seem to continually misunderstand the most basic realities of web development. Maybe it seems that way because everyone asks these questions only once, but since everyone asks the same question over and over again the rest of us start pulling out our hair.

You need to step back a minute and realize that the web was designed to let you enter a page's address and pull back a &quot;web document&quot; to view. These documents can have links that you can click on, saving you the trouble of manually entering URLs to request additional documents.

Forms were added soon after, but they follow the same model. Submitting a form is really just requesting another document, along with some parameters as well as the address of that document.

CGI, ASP, and other &quot;active web&quot; technologies rely on a server being able to tell when a request isn't for a static document. The web server then passes the request to a program or a scripted page or something. This &quot;active web&quot; logic is supposed to process the request and build up a web document (page) to be returned to the browser.

That's about it really.

Think of it this way: it is sort of like very fast email. You (via your browser) send a brief email to the server. The server gets this, figures out what you want, and emails it back to you (at your browser) where you can view it.

So clearly you can't &quot;run code&quot; over email. And you can't run code over HTTP either.

What you CAN do is make requests via HTTP and get back results.

Problem is, downloading a PDF is usually the same as downloading static HTML, or a JPEG, or about anything else. The server handles this as part of its static document processing. Your ASP code never SEES the request.

Instead you need to have the link the user clicks on go to an ASP page. This ASP page would do your logging and stream the PDF back to the user. So now you need to do the work that the server normally does for you.

Here's a simple example returning an Excel document:

http://support.microsoft.com/default.aspx?scid=kb;en-us;276488

I assume you can't just extract what you need from the IIS logs for some reason?

 

[CrimsonDiva]

dilettante, Thank you for your comments, but they really didn't help much at all. Tarwin provided the best solution to my problem. I used it, and it's working fine.

dillettante, I completely understand HOW the web works and how pages are processed. The question I asked has nothing to do with forms or running code over HTTP. I really don't know what pursuaded you to put the response that you did. But, to each his own.

Tarwin, thanks again for your help!

Diva