A while ago it was discovered that mushclient tries to handle timers like so:
1. Timer goes off.
2. Script call gets stacked for it in the list.
3. Script calls are executed.
4. Timer is reset.
Turns out that 3 and 4 are backwards and if the script takes longer than 1 second to execute its code, the timer will go off a second time, then a third, then a fourth, ad infinitum. Oops!
Now this is not usually an issue, however in at least one case when trying to use the Inet ActiveX control to pull info from a web page at 30 minute intervals, it blew up. So here is the solution>
Several different attempts where made to use enabletimer to temporarilly disable the offending timer, but I could never get it to work properly. However.. It may be possible to enable a second timer in the same place as the "Fired", "False" line above and have that timer reactivate the original.
Note however that do to the extreme delay caused by this kind of internet command, a means to execute the script as a seperate thread that won't hang the client would be prefered. Such a thing would however require a number of serious restrictions, since it would be acting independent of the rest of the client, save for data sent to and retirieved by it. An external program would probably be better in most cases, but such a thing can't be quickly adapted to changed made in a web page structure, etc.
What would be needed is a shell program that runs scripts externally, but talks to the client as though it was part of it. Possible, but only if you know how to do it, which I don't. lol
In any case, skipping over the offending code has the effect of causing the second call to the sub to exit soon enough to reset the timer, thus breaking a nasty cycle. As long as you can handle the serious lag that an Inet http command causes, it will fix the problem. I don't however recommmend even thinking about trying to use Inet's FTP protocal with it. ;) lol
1. Timer goes off.
2. Script call gets stacked for it in the list.
3. Script calls are executed.
4. Timer is reset.
Turns out that 3 and 4 are backwards and if the script takes longer than 1 second to execute its code, the timer will go off a second time, then a third, then a fourth, ad infinitum. Oops!
Now this is not usually an issue, however in at least one case when trying to use the Inet ActiveX control to pull info from a web page at 30 minute intervals, it blew up. So here is the solution>
sub Longdelays (tname)
if world.getvariable("Fired") = "TRUE" then
exit sub 'Skip the whole mess that will cause a new delay and
'send us into an infinite loop.
end if
world.setvariable "Fired", "TRUE"
...
The Inet or other command that has a long execution delay.
...
world.setvariable "Fired", "FALSE" ' This line will 'only' execute
'after the script has gotten past the
'command(s) lagging the script.
end subSeveral different attempts where made to use enabletimer to temporarilly disable the offending timer, but I could never get it to work properly. However.. It may be possible to enable a second timer in the same place as the "Fired", "False" line above and have that timer reactivate the original.
Note however that do to the extreme delay caused by this kind of internet command, a means to execute the script as a seperate thread that won't hang the client would be prefered. Such a thing would however require a number of serious restrictions, since it would be acting independent of the rest of the client, save for data sent to and retirieved by it. An external program would probably be better in most cases, but such a thing can't be quickly adapted to changed made in a web page structure, etc.
What would be needed is a shell program that runs scripts externally, but talks to the client as though it was part of it. Possible, but only if you know how to do it, which I don't. lol
In any case, skipping over the offending code has the effect of causing the second call to the sub to exit soon enough to reset the timer, thus breaking a nasty cycle. As long as you can handle the serious lag that an Inet http command causes, it will fix the problem. I don't however recommmend even thinking about trying to use Inet's FTP protocal with it. ;) lol