Idle makes Autoit not auto

[cwem 0]

I'm trying to retrieve stock information based on clients' portfolio (a text file with rows of numbers).

e.g. number.txt

1

94

133

888

1209

1788

3233

Since it involves form submission, I use WinActivate and alike to set values in the form and submit and wait for results returned from a server.

While testing with a few rows does work well, I find that it doesn't work when I have, say, 1000 numbers.

if I don't click the IE that's used for information retrieval occasionally, say, after 10 numbers, autoit won't proceed and remain idle, until I manually activate the window again. I've already used WinWaitActive alike function to ensure synchronization and it's not the server side problem. Has anybody encountered similar problems?

I don't know whether retrieve table regardless whether it exists or not will cause the problem:

--> IE.au3 V2.4-0 Warning from function _IETableGetCollection, $_IEStatus_NoMatch

And does anybody know how to ask autoit to write to a file progressively instead of flushing all the things when the file is closed? Sometimes I have to force termination of my program and 3-day work then becomes none. I don't want to open and close file frequently in order to achieve the effect of writing contents into output files.

Thanks for advice in advance~

[PsaltyDS 25]

I'm trying to retrieve stock information based on clients' portfolio (a text file with rows of numbers).

e.g. number.txt

1

94

133

888

1209

1788

3233

Since it involves form submission, I use WinActivate and alike to set values in the form and submit and wait for results returned from a server.

While testing with a few rows does work well, I find that it doesn't work when I have, say, 1000 numbers.

if I don't click the IE that's used for information retrieval occasionally, say, after 10 numbers, autoit won't proceed and remain idle, until I manually activate the window again. I've already used WinWaitActive alike function to ensure synchronization and it's not the server side problem. Has anybody encountered similar problems?

I don't know whether retrieve table regardless whether it exists or not will cause the problem:

--> IE.au3 V2.4-0 Warning from function _IETableGetCollection, $_IEStatus_NoMatch

And does anybody know how to ask autoit to write to a file progressively instead of flushing all the things when the file is closed? Sometimes I have to force termination of my program and 3-day work then becomes none. I don't want to open and close file frequently in order to achieve the effect of writing contents into output files.

Thanks for advice in advance~

Since you are monitoring a web page, and that page gets refreshed regularly, you may be trying to get access to elements that don't exist at the moment because a refresh is in progress. The particulars will be highly specific to the exact web page and your code for dealing with it.

Use FileOpen() with the append mode to add data to a file. Open and then FileClose() when done writing. Don't keep the file open when not writing to it. If the writes are occasional, so speedy performance is not required, then you might just use FileWriteLine() with a string file path and not bother with the FileOpen/FileClose cycle (FileWriteLine() will do it for you).

[cwem 0]

Since you are monitoring a web page, and that page gets refreshed regularly, you may be trying to get access to elements that don't exist at the moment because a refresh is in progress. The particulars will be highly specific to the exact web page and your code for dealing with it.

Use FileOpen() with the append mode to add data to a file. Open and then FileClose() when done writing. Don't keep the file open when not writing to it. If the writes are occasional, so speedy performance is not required, then you might just use FileWriteLine() with a string file path and not bother with the FileOpen/FileClose cycle (FileWriteLine() will do it for you).

I find that it may be due to 2 reasons:

1) 10-min screen saver shifts focus

2) password protected screen saver login shifts focus

closure of remote desktop is not likely the reason.