RE: xPLHal scripting matches

[Tony Tofts]

> I think I am still missing something here because as I
> understand it if you included the above line and also wanted
> to include say the following filter later in the XML file
<snip>
> could never be picked up by my second filter because the
> first filter will have trapped it. So I couldn't set up
> filters within xPLHal to intercept all class=CID messages and
> all device=CBus messages - neatly. I agree I could add a
> test within the the CID trap to see if it was a CBus message
> and take appropriate action but that is highly unstructured.

I forgot the fact that you wanted to do both...

> I think you missed the next line in my original message which
> you <snipped> it reads...

Yep, sorry.

> Maybe it wasn't clear what I was trying to convey here
> but what I meant is that if the 'action' parameter is absent
> in the XML file then you default it to 'break' which is
> exactly what happens currently... every current script would
> continue to run unmodified wouldn't it ???

It's clear, I just missed it! It's been a _very_ long week :-(

> I think my proposal achieves this - whereas the other option
> would cause a change in script actions and/or would require
> changes to the XML file. Which is exactly what you're trying
> to avoid isn't it ??

Don't quite follow this, but I've probably missed something again...

Your solution gets around the having to add an extra parameter to the xml
file (though an error trap will be needed to prevent a crash on reading the
non-existant parameter). And will leave the processing sequence as it is
now, for those that don't add the extra parameter.

Can the group comment on whether they are happy for this change at this
time, please?
Are there any objections/recommendations or further suggestions?

Thanks
Tony