Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:Andy Galvan Date:08 Aug 2006 03:32 PM
I'm running Stylus StudioŽ 2006 Release 2 Build 591d. When I debug an XSLT, the Call Stack seems to accumulate templates that have been called, but which have subsequently ended. I suspect the call-template with embedded apply-template commands somehow confuses the call stack. Is anyone else having a similar problem?
Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:Andy Galvan Date:08 Aug 2006 06:10 PM
I've created a very simple XSLT that calls and applys templates. If you debug this and stop at the 'Begin' element, the Call Stack shows the match="/" template at line 5.
If you continue and stop again at the 'End' element, the Call Stack shows, "/" (line 6), "A" (line 14), "Called Template1" (line 18), "B" (line 23), "Called Template2" (line 27), and "B" (line 7).
I expected the same Call Stack as the first stop, match="/"
Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:Andy Galvan Date:08 Aug 2006 06:43 PM Originally Posted: 08 Aug 2006 06:24 PM
Microsoft .Net 1.x
Ah... I see that the built in processor works OK. So the Microsoft .Net 1.x processor must be the issue.
Also, the Watch Window doesn't work properly with the Microsoft .Net 1.x processor... try stopping at <xsl:element name="In">. Then, try to "Watch" C or D. I get values with the built in processor, but not with the Microsoft .Net 1.x processor.
I really need to use the Microsoft .Net 1.x processor, since that's the processor that will be used in our production application.
Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:Andy Galvan Date:10 Aug 2006 12:29 PM
Ivan, thanks for acknowledging the issue and offering a short term solution. I do have some stylesheets that require the Microsoft .Net 1.x processor because of msxsl (VB) scripts. These are hard to debug, as it is, and eliminating the Microsoft processor makes it just that much more difficult.
I'm unclear as to the long term resolution. Is this not considered a bug, and something that SS will be fixing?
And what about Microsoft .Net 2.x processor? We will soon be moving to that as a corporate standard for all our applications. What is the SS direction for supporting the Debug feature, using a Microsoft .Net 2.x processor?
Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:Andy Galvan Date:11 Aug 2006 09:39 AM
I needed the current date-time and a GUID. These had to be added to the output xml file during the transform process. I found the VBscript to be the easiest to accomplish this.
Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:Andy Galvan Date:11 Aug 2006 09:54 AM
That's what I originally suggested... but based on the isolated need and wide distribution support of the calling web service, it was deemed "my problem". So, I have a several XSLTs in my arsenal that use VB scripts.
Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:roberto azzimonti Date:11 Aug 2006 12:12 PM
I'm evaluating your Stylus Studio 2006 Enterprise edition 653e.
I also found a (major) problem for us running transformation in debug mode. The order we process the records is crocial. Your product seems to stack lists in reverse order. Consider this fragment of code:
In your editor the node passed to the template is the last one in the list even if we hard-coded position [1]. If we use last() the node passed is actually the first one in the list. We can not use your editor if this is its standard behavior.
Subject:XSLT Debug Call Stack doesn't always pop stack - call-template calls seem to be an issue Author:Minollo I. Date:11 Aug 2006 03:42 PM
Roberto,
we are able to reproduce this problem, and we have a fix for it; the fix will be part of the next Stylus Studio update, but in the meanwhile we can make it available to you if this is a show stopper in your evaluation; please contact us at stylus-field-report@progress.com if you are interested in a module patch.