@Tre4shunter
What is the purpose of the ReadOrders/ReadItems timers?
If ReadOrders is waiting for an external COM method to return (such as
Execute (ADO Connection)), the ReadItems timer won't execute. In between COM method calls, the ADO_Read function could be interrupted by the ReadItems timer, causing the first ADO_Read call to be suspended while the second one executes. I'd guess you don't actually want them to execute at the same time, otherwise it would have made much more sense to create two secondary scripts instead of one. Why wouldn't you just call them in sequence?
Calls such as
S1.G["ItemData"] will not be responsive if S1 is waiting for a COM method to return. Rather than having the main script poll for a result, the secondary script should notify the main script when it is ready. Rather than using LoadFile, I would suggest you use ObjRegisterActive directly, or some other method of communication, such as
WM_COPYDATA.
LoadFile creates the
client object and registers it. The secondary script then retrieves (a COM proxy for) this object, which it also assigns to
client. LoadFile.Serve creates an object in the secondary script and passes it back to the main script by assigning it to
client._proxy. If
client had any methods, the secondary script could call them; or it could assign results directly to properties such as
client.ItemData. However, LoadFile only uses it to pass the secondary proxy back, so it doesn't keep a reference to
client.
In short, you can create your own registered object with a method which the secondary script should call when both operations are completed.
WM_COPYDATA is simpler and would probably work just as well or better for your purpose. When the secondary script completes its work, it can combine both results and send them with a single WM_COPYDATA message. When the message is received by the main script, a function is called and it retrieves the results from the WM_COPYDATA parameter.