
I have been having great success with metatraffic thus far, but, on my asp pages the processor usage dropped dramatically when I use -
[code]
<% Server.Execute("/metatraffic/track.asp") %>
[/code], instead of -
[code]
.
[/code]
Unfourtunately, I *really* need the screen rez info, which, according to the "readme.htm" is not available unless you use the javascript logging method. Does anybody know any "tricks" or what to do to get the asp method to capture the screen rez?.
Phillip Ulberg
Webmaster / Sys Admin
wsrb.com
capture screen rez using asp
Good day,
There is no way around it, unfortunately.
Screen resolution is only available via javascript, simply because javascript pulls the information from the client's browser.
ASP pages are built on the server, then sent over to the client, so client browser's info is not available while the page is being built by the server.
If the performance is your main concern, then just be a bit patient. The developper is actually working on Version 2 which will be less ressources hungry.
The fact that the screen resolution isn't available via VBscript/ASP is not because something was overlooked, it is simply the nature of the things, actually ASP - VBScript - JavaScript.
Bye for now...
capture screen rez using asp
Hi,
Well actually Daneil you can include JavaScript directly into the track.asp to include screen size and width.
Just place this JavaScript Code at top of track.asp.
document.cookie = "screenwidth=" + escape(window.screen.width);
document.cookie = "screenheight=" + escape(window.screen.height);
And to retreive this info via VBscript just need to do this
Request.Cookies("screenwidth")
Request.Cookies("screenheight")
The reason this can be done is JavaScript and VBscript format the Cookies in the same way.
Only way it won't work is if cookies are disabled in the cleints Browser so you may want to add code to check for cookies in above JavaScript Code.
Hope this helps.
www.doitasp.com
capture screen rez using asp
Tangent,
I understand your concept, but it goes against the flow of the actions no ?
First, "track.asp" is executed/built on the server. When ready to be sent, the page having the "track.asp" included in it will then be sent by the server over to the client.
When the client's browser renders the page, the embedded javascript code will then be executed, however the information is not passed back to the server.
So using an approach similar to what you are suggesting, the "cookie" will be always one hit behind the real situation, because the cookie will be read by the server and the database will be updated only on the following call to "track.asp", assuming "track.asp" is validating the cookie content in order to apply it to the db.
Anyhow, your approach can be considered, however it implies that both javascript AND the cookies are enabled on the client's browser, whereas the "track.js" approach requires only javascript.
The complexity of the problem here resides in the timing at which the information becomes available. With your suggestion, the record in the DB would have already been logged, however the cookie information would not be up-to-date, although we can assume that people won't change screen resolution on the fly while on a site, at least very seldomly.
The cookie approach simply alleviates the need to pass the information via parameters, as it would be done using the "track.js" method.
Globaly, when mixing server-side and client-side scripts in a process, it is difficult to get the things in synch.
Thanks for your input...