| Subject: | Win32-OLE and timeout issues |
Im new to this system and uncertain if this is the correct way of dealing with this matter. Please advise if it is not.
Ive encountered a difficulty with Win32::OLE while working with IE attempting to measure the load time for pages. With pages contain certain kinds of JavaScript features one completion detection scheme that works reasonably reliably is to use Win32::OLE->MessageLoop and to follow the events (the reasons for this are rather convoluted, but nonetheless true, IEs busy and readystate are NOT reliable indicators of page load complete for many pages) in a perl event handler.
Difficulties arise in determining when the OLE object has stopped issuing events. Once Win32::OLE->MessageLoop has control, there appears to be no mechanism to trigger Win32::OLE->QuitMessageLoop after IE events stop flowing.
I attempted to use alarm and a perl alarm event handler. The basic scheme was to alarm(quiteTime) whenever an event occurred. When the alarm finally fired, then there would have been no events for quietTime and the QuitMessageLoop could be issued from within the perl alarm event handler. Unfortunately, testing reveals that the alarm handler does not execute when Win32::OLE->MessageLoop is active. While inconvenient, Im not sure that this behavior is necessarily a bug.
Ive looked into using Win32::OLE->SpinMessageLoop inside a perl spin loop in this fashion:
while ($timeout > 0) {
Win32::OLE->SpinMessageLoop;
Win32::Sleep($IESpinSleep); # sleep milliseconds
$timeout -= $IESpinSleep;
}
Unfortunately, this drastically alters the timing of the underling IE event stream making the time measurements useless.
I believe there are several approaches to this issue involving timer/timeout features within Win32::OLE. Certainly, it seems reasonable to have a timeout associated with MessageLoop so it does not hang indefinitely when things go wrong. Possibly a Timer callback to a perl event handler within Win32::OLE that is compatible with MessageLoop would be an useful addition.