At 9:56 pm -0400 01/04/01, Ronald J Kimball wrote:
>On Sun, Apr 01, 2001 at 09:59:22PM +0100, Alan Fry wrote:
>> A "use Mac::Events" statement appears to interfere with the workings
>> of a web browsers even if the 'Mac::Events' module is not actually
>> used in the script. By all the laws of the Medes and Persians (and
>> Camels) it should be possible to "use" any module without penalty
>> should it not, since the 'methods' of the module should merely lie
>> dormant in the script unless called into action?
>
>Err, no. First, when you use a module, that module is compiled and
>executed. BEGIN, CHECK, and INIT blocks are called (depending on the Perl
>version) and code outside of any subroutine is executed. Second, the
>module's import() method is called.
>
>This hypothetical module would impose penalties in several ways upon use:
>
>package UhOh;
>
>BEGIN {
> sleep 10000000;
>}
>
>for ($i = 1; $i < 1000; $i++) {
> push @x, [@x];
>}
>
>sub import {
> exit;
>}
>
>__END__
>
>These are extreme examples, of course, but it's quite possible that an
>actual module could execute code upon being used that would cause problems.
Thanks -- UhOh.pm is a very informative (if malign!) 'module'.
Fiddling with the values a bit it is possible to see it right through
to the 'exit' in the last subroutine so it shows the sequence of
events very clearly.
However in the case of the script involving the browser the problem
does not seem to arise during the BEGIN sequence but later on as the
script runs. For instance the script 'hangs' at the lines:
ICGeneralFindConfigFile($ICInstance); # open InternetConfig
ICLaunchURL($ICInstance, 0, $url); # launch browser
If a 'force quit' is invoked for MacPerl, and after MacPerl has gone
away, InternetConfig does its stuff and launches the default browser.
From this I get the feeling that somehow the presence of 'Events.pm'
somehow traps the AppleEvent sent (by whom?) to the browser. Does
this make sense?
Empirically I find that a 'WaitNextEvent' after those InternetConfig
lines 'clears the air' and the launch proceeds. To be precise, one
'Wait' seems enough for 'Netscape' and about three are needed for
'IE'.
That is kind of interesting, but, as a fix, pretty much in the realm
of pious hope programming.
Although 'WaitNextEvent' has the side effect of introducing a delay
(probably until the next 'idle' event turns up?) the delay itself is
not significant. For example replacing the 'WaitNextEvent' with a
four-element 'select()' timer does not have the same remedial effect.
I would dearly love to find a way of finding out what is actually
going on and would be very grateful for any suggestions.
Alan Fry
