MacEx grab the currently viewed temporary internet file?

[hpram99]

I have macros that are dynamically re-downloading the webpage I'm currently looking at, so I can get the source code and parse certain information out of it.

 

We work on a vpn client through a proxy, on a 512kb line. Re-requesting a 500kb file kinda sucks, so I'm looking for a more efficient way of doing this.

 

I have the url, and tried grabbing the file this way:

 

If file exist:

%userprofile%\Local Settings\Temporary Internet Files\event_edit.asp?event_id=%T7%

Load file into variable

(the page was identified in this folder as "event_edit.asp?event_id=" then the event number)

 

Unfortunately the way windows displays the files in Temp Internet files, is not the real file name. the real filename is just "even_edit.asp"

 

Windows obviously has some way to identify the entire URL of that file - using the index.dat I presume - is there any way I can have macex correctly identify the correct temp file?

 

This might require a 3rd party script like VBS...

 

any suggestions are appreciated.

[Cory]

Check out WGet. It allows one to essentially just download the HTML of the target without having to use a web browser. Then you can parse the HTML in ME3. In fact your macro can be completely invisible to the user. Of course it does much more but I think that's all you need. And it's free.

[hpram99]

Check out WGet. It allows one to essentially just download the HTML of the target without having to use a web browser. Then you can parse the HTML in ME3. In fact your macro can be completely invisible to the user. Of course it does much more but I think that's all you need. And it's free.

 

 

Thanks for looking, but I think you might have skipped over the first line in my original post

 

Unfortunately this is what I am already doing with an MSXML object. I want to AVOID downloading the page, as this is very time consuming (several macros run for minutes, not seconds)

 

 

I also posted this question in a vb/vbs forum, but so far all I've got are crickets

 

 

edit: If needed, would it be possible to move this to the 3rd party forum? I realize this isn't going to be possible in ME natively

[Cory]

No, I understood you. You are downloading a URL over and over again and want to get the raw HTML each time and grab something from it. I do this all the time. I have done it your way but recently I started playing with WGET. With this I can WGET the URL to a file without downloading all the graphics and junk. So I basically copy the URL to a specific text file on the HDD and suck that into a variable in ME3 where I parse out what I want. In my initial tests it works very well.

[hpram99]

No, I understood you. You are downloading a URL over and over again and want to get the raw HTML each time and grab something from it. I do this all the time. I have done it your way but recently I started playing with WGET. With this I can WGET the URL to a file without downloading all the graphics and junk. So I basically copy the URL to a specific text file on the HDD and suck that into a variable in ME3 where I parse out what I want. In my initial tests it works very well.

 

 

wget downloads the page, I already do this, this is not what I'm looking for.

[Cory]

I know that. I was just trying to give you an alternative solution. Sometimes it's best to avoid a problem instead of solving it. If the path you choose has a bridge out you could rebuild the bridge or go back and choose another path.

 

Have you tried monitoring the temp folder for new files? If you refresh it right now and look quick it should be the newest file in there.

[hpram99]

not exactly able to refresh the temp folder because what you see is not what's really on the harddrive, if you browse through DOS you'll see it's actually a bunch of random folder names with no files inside.

 

I've found that extracting this data is not possible through simple scripting (vbs) but requires manipulating the windows shell commands through a real programming language like C++

 

Even then it's fairly undocumented, not reccomended, and difficult.

 

Dropping the idea, we may be dumping macro express soon and moving on to iMacros

 

Thanks for the input anyway.