Another interesting thing

[stanl]

This is where I want to avoid (but always seem to) get into an argument with Tony over whether or not the issue is a Winbatch problem.

I wrote a simple WB web-scraping app to reconcile transfer calls from our dialer into a lookup web site. There are 2 possible results (1) transfer code is not found (2) it is found and results recorded to a db table (3) server error (which is legitimate and can be recorded).

So... looking at over 5,000 codes:  The script works as written.... but when compiled and executed gives an unknown error or on line While oIE.readystate != 4  (which is a UDF check for IE processing).

Point is I can run the script on my home PC (through VPN to work) but would prefer to run the compiled script at work.

[JTaylor]

I always hate these as sometimes it is VERY difficult to resolve.   If it will run on a computer that no one is using while running you might try adding a Display(.1,"Hey","Flush Please") before any Navigates or other points where it seems to lock up.   Sometimes the pipeline gets plugged up and that or Message() flushes it out.

Not sure if the code being Signed and run from Program Files would make a difference or not either.  Tony would have a better answer to this one.

Good luck.  These drive me CRAZY sometimes.

Jim

[stanl]

Jim;

Actually the offending line is part of a standard UDS I have used for years. I have some older scraping apps for like Edmunds.com  and all work fine compiled using the UDS. Also, the particular project is done so even if a compiled exe had worked, I would be deleting it. Oh, and for the script in question I used 10 for ndelay.

Code (WINBATCH) Select Expand


#DefineSubroutine ieready(ndelay)
IntControl(73,1,0,0,0)
t = 0
While oIE.readystate != 4
   t = t+1
   display(.5,"Loading... Please Be patient... WebSite may be busy...","Attempt %t% on Page %page%")
   If t>ndelay Then Return(0)
EndWhile

t=0
While oIE.Document.readystate != "complete"
   t = t+1
   display(.5,"Document is...",oIE.Document.readystate)
   If t>ndelay Then Return(0)
EndWhile
Return(1)

:WBERRORHANDLER
ErrorProcessing(0,1,0,0)
oIE=0
Exit

#EndSubroutine



[JTaylor]

Yes.  It has been my experience that it works fine for some sites but not for others.   If you haven't you might try putting the Display() right before the navigate and not within the loop.  Might not make any difference but if it is going to help it will be at that point.  Amount of delay doesn't really seem to matter in my experience.  It doesn't seem to be a timing issue but rather a clog in the plumbing.   This, or at least a related, issue is why there is an invisible option for Display().

Jim

[stanl]

So are you suggesting that the speed of the exe versus running from studio might be a timing issue with respect to the particular URL?

[JTaylor]

No.  I think I lost of the part about where it works in Studio but not compiled in my thinking along the way.   Not sure that negates anything I've suggested trying but does make me a bit less certain about the issue.    I have run into this issue, the error part, upon a number of occasions but I think it has always been consistent between the script and the exe.   I almost never use Studio so can't speak to that part.  Sorry if I have wasted your time.

Jim

[stanl]

Not at all. The script was actually disposable code, just written to save hours of work. I made the EXE to run from a desktop at work I can RDP to, so I could run it without staying logged in to VPN. For the fun of it I might just remove the reference to the udf, replace with a 2 second time delay as the URL is actually quite fast in responding and see if the exe works when re-compiled.

[JTaylor]

A curiosity question...I know it works from Studio as a script but what if you just run the script from Windows Explorer?   Does it work that way?   Not sure how Studio mediates the execution of the script so may not make any difference but just something that crossed my mind.

Jim

[td]

Running a compiled vs uncompiled script can only changes two  possible things from a script functioning perspective:  the location of the scrip (computer and/or directory) and the integrity level of the process (UAC manifest setting.)