This is a VSCode syntax highlighting and formatting language extension for Architect Debug Message Log files.

Go to the Releases page and download the .vsix extension file there. Inside VSCode, open the command pallette with Ctrl+Shift+p, search for and select Extensions: Install from VSIX..., and select the .vsix file that just downloaded. It should prompt you to reload to enable.

To enable on an opened Architect Debug Message Log file, open the command pallette with Ctrl+Shift+p and select Change Language Mode (the shortcut for this is Ctrl+k m), then search for and select Architect (architect).

Alternatively, name the file with a .archlog file extension and the extension should automatically change to Architect language mode.

This extension provides syntax highlighting through a TextMate grammar for Architect Debug Message Log text. Embedded SQL inside SQL STATEMENT braces is also syntax highlighted.

This extension also provides formatting of Architect Debug Message Log text into properly indented and nested statements. This is very useful for understanding the execution of a process because it shows the structure of the process's execution and better matches what you see when viewing the code in Advantage Architect.

To format, open the command pallette with Ctrl+Shift+p and search for and select Format Document. Alternatively, use the default shortcut Shift+Alt+f.

After formatting, the document will show completely unfolded, so I like to use the command Fold All to show what the top-level execution looks like. It helps to know VSCode's default folding shortcuts.

But you can always just click the folding arrows to the right of VSCode's line numbers.

The other useful thing this enables is diffing different parts of the log. For example, I was trying to see the differences in execution between two runs of the same process object (one was working, the other was not). Using the formatted debug log with a diffing tool like Partial Diff let me see the differences between the two parts of the log which helped me troubleshoot the issue pretty quickly.

npm install
vsce package

• It will fail parsing if there's a closing curly brace inside SQL statement (happens for JSON strings)
• End action
  • Example: 22: End: N/A PASSED Next Instruction: 0
• SQL STATEMENT {BEGIN TRANSACTION} failed parse b/c rn I require spaces between curly braces
• the following line causs parse fail: Value = [IV]. Occurs when you set a field manually in debugger
• "Line numbers" inside names pick up syntax highlighting. Change syntax grammar.
  • Example: ... Calculate: ScrOpt: F2:Item ...
• Here's a sticky one that comes up in demo/more-ops.archlog. The last call to _Directed Move - DMR is a dynamic call, but it's at the end and never finishes in the log, so it doesn't have a ... Dynamic Call: Execute PO ... line. So, b/c of the way Architect debug log works, if you go up from the bottom of the log you'll find an ENTERING WANextGeneration._Directed Move - DMR line, but you won't be able to tell that it got there from a Dynamic Call: Execute PO call. So the formatter just wraps up all the lines from the bottom up to the ENTERING line, and calls that a ... Call: _Directed Move - DMR ... line with nested lines, rather than a dynamic call followed by a call.
  • The common issue here would be for calling a business process object from the main menu, so maybe you could hard code it where if the ENTERING line is preceded by the Compare: MNU Dynamic Call = "Yes"? line, then you should be OK to assume that it's a dynamic call.
• Known Limitation: I get rid of application information for calls. I might need to add this back

• Bundle with webpack
• Dynamic Call statement will nest until Entering, but then it doesn't show what PO it Executed. It just says Dynamic Call: Execute PO, instead of Dynamic Call: _Directed Move - DMR - see demo/all-ops.archlog for example.
• In top level, use RETURNING TO statements to infer top level call. For example, if debugging is started inside a busines process object, it'll keep RETURNING TO: <app>.<bpo>. And you can find that in the top level statement list. So then that should be used to create a Call: <bpo> statement with unknown result:
  • N/A: Call: <bpo> N/A
  • and then inside is the rest. So you use all the contextual information you can.
• Split SQL result rows into multiple rows. This would allow to more easily see what was SELECT'ed by the SQL STATEMENT database action.
  • complication is that rn they're space delimited, but the values themselves can include spaces. JSON will surround with double quotes which could be worked around, but it's also possible that ---- THIS IS A SINGLE ERROR MESSAGE could be a valid output.
• Visual Debugger apparently has a "Log Level 5" that will log any time a field changes, not just for those you're watching. Apparently it's visible in the "Application Status Console" or "System Status Console", but maybe not the message log. Check this out and figure out the best way to show this in the formatted document