Another for you

If you have one hotlinks to catch hash fine.

If you put another one in but orphan it (so its disabled) this causes the application to fall over. with a grammar error (in the case of Cisco CVP - Regex error)

Admittedly you should not do that but if you have one global hotlinks handler with the same grammar value surely you should barr another one being created and tell the designer only one global instance should be allowed particularly in the case of short cuts like hash, zero etc.

This also reaffirms the suggestion of a local hotlink handler on a page by page basis which should be there as its supported in the W3C Specification.

Folks,

Listen, we are writing a lot of Audium Applications, and doing a ton of complex stuff (custom components) and heavy workarounds so we know most things inside and out of this tool. Even down to hacking all the XML which can be faster than using the GUI tools at times.

I know about disabling hotlinks, but if you disable a hotlink (orphaned) and create another hotlink (enabled) with the same settings elsewhere in the call flow, the application falls over. You might expect since the first hotlink is disabled that is all fine. I was surprised too. Other element types are not a problem in these situations but hotlinks seem to be.

There is some conflict here. That is what I saw, the moment I deleted the orphaned hotlink (which was floating totally on its own), the application worked again fine.

My point still stands. I would look a little closer at this.
Cheers

admittedly this was prior to 5 so maybe the issue has resolved, but another developer had this issue too.

Cheers