A follow-up to the other post from last year, I have now experienced this in a new and disturbing way.
Unfortunately, when checking in the changes the Lansa Editor changed the pings to double-pings, rendering my code buggy.
This happened in v.12.5 and continues to happen in v.14: When I write XSLT I may write something that is perfectly valid and correct (at least, most of the time) and which produces no errors.
But then, when I reload the command handler the next day, I am not getting the same code. The Lansa Editor has rewritten my code to something else that is perfectly valid and correct (and indented differently) but which the Lansa Editor now reports an error in.
Without a doubt this is an error that comes from the rewriting and now, everytime I save, compile or check-in, I see this:
It happens when I have used <![CDATA[ … ]]> and <xsl:text disable-output-escaping=”yes”> … </xsl:text>. The Lansa Editor removes the <![CDATA[ … ]]> and replaces the characters with the proper entities, but chokes on it itself.
It turns out that the error I got trying to access the XSLT source (not the missing shortcut, the crash) was due to a bug in the editor. I had a
with no <tbody>. Yes, I know.
But the editor checked the XSLT and appears to think it is fine. Then the renderer took over and crashed, due to the missing <tbody>.
Fortunately I found the XSLT in the temp cache so with the supplier’s help I could regenerate the XSLT (deleting all my work) and reinsert my code, now with the <tbody> tag.
Hmmm – it appears that the SHIFT+F9 is no longer, in Lansa Editor v.14, a shortcut to the most recently used technology service XSLT. And at the moment F10 causes a crash: