RE: xPLHal scripting matches

[Tony Tofts]

> incremented) defaulting to a sequential action. This forces
> sequential processing however you could alternatively
> presumably issue the 'fork' earlier - at the start of your
> script thus permitting your current thread to continue to run
> , and effectively spawning another parallel thread later in
> the filter matches - this would offer the choice of having
> concurrency or sequential running. ] Or is this rubbish ??? :-)

The processing of filters to decide which script to run is _inside_ the
thread.
i.e. the message gets a thread, then processing is done. This ensures
timely
processing of each incoming message.

The checking of the constructs for the sub to run is a loop, so by removing
the 'exit' from the loop, all matching subs will be forced to run.

This still gives the problem that a sub could run multi-times for a single
message. There is a way around this, by recording the sub names run and if
it's already been run move onto the next match.

However, there is no way for a script to safely/reliably send any flag back
to the thread that called it...

By my reckoning we can make changes to
A) Process all matches
B) Prevent a duplicate routine running

I think we can do without a sys.break, since it is the responsibility of
the
each vbscript to determine if it should be taking any action anyway.

Comments?

Regards
Tony