Caxton Scripting with .NET

You can extend the behaviour of Caxton by placing a .NET assembly named CaxtonScript.dll in the Kappris folder named in the config.ini file. Caxton copies the dll down from that location to the user's %TEMP% folder and loads it from there.

This zip file CaxtonScriptSources.4272.zip contains the Visual Studio C#.NET solution and a CHM file for developing your own CaxtonScript.dll. Developing your own CaxtonScript is made easier by Visual Studio's intellisense auto-completion, syntax highlighting and integrated debugger. But if you don't have Visual Studio 2008 or later you can still develop your own CaxtonScript; you can edit source code using a plain text editor (though you won't get syntax-completion or intellisense) and build using the msbuild tool supplied as part of .NET:

  msbuild CaxtonScript.sln /t:rebuild /p:Configuration=Debug;Platform=x86

To be able to step CaxtonScript methods in a debugger, you need the pdb and dll files. Caxton copies the dll to %TEMP% on its own - you'll need to manually copy the corresponding pdb file to %TEMP% to be able to step the code. 

Even if you do not have Visual Studio you can still debug your code as it runs within Caxton, using the mdbg tool supplied with the Microsoft SDK, which is a free download. Mdbg is the managed code debugger.

Stepping Caxton with mdbg, the managed code debugger supplied with .NET

Assuming you already have a Kappris print job from a previous run of Caxton because you set Caxton Always Keep=True in config.ini, there will be a folder with a datestamp name on it below %TEMP%\Kappris. Use the name of the datestamp folder as an argument to Caxton. Run this at the command prompt:

  mdbg path\to\Caxton.exe 20110407121750265

and once the mdbg> prompt appears, set a breakpoint on the ConstructJobname function, specifying its namespace and parent class. For instance:

  b CaxtonScript.CaxtonScriptClass.ConstructJobname

Once the breakpoint hits, use sh 20 to list 20 source code lines, p to list the local variables, p name to examine variable name and n to step the code a line at a time. g to continue execution from the current point - don’t use r as this restarts the program. When you’re done, use q to exit mdbg. There’s complete help within mdbg by hitting the  ?  key.

An alternative way to specify breakpoints is to insert this line after the opening curly bracket at the start of the function you want to debug:

  System.Diagnostics.Debugger.Break();

If you were to run mdbg on the debug build of Caxton then mdbg would break on the first executable line of Caxton. But it doesn’t break when the retail build of Caxton is used. Pasting the break command in like this is OK so long as you remember to remove it again once debugging is complete!

So once you’ve installed the .NET stuff you’ll be able to debug your Caxton scripts even if Visual Studio isn’t installed.

If your command prompt has color set to 07 (so the foreground colour is the dimmer of the two possible brightnesses) then mdbg uses colour, which is cool:

 
 
If you have Visual Studio, you can set Caxton Visible=True and Caxton Wait To Proceed=True in config.ini, and then when Caxton's [Proceed] button appears, you can attach the debugger to the Caxton process.

Alternatively, check out the SOSEX windbg extension for managed code debugging.