Debugging made easier

December 22nd, 2005 by Andy Nicholas - Viewed 13761 times -




The hyperlinks generated in the Script Editor when an script error is thrown can be very helpful in finding exactly where a problem has occurred. The only issue is that if you are using an external editor, the line number is not communicated to the editor to make it automatically scroll to the line of code that produced the error.

Most standalone text editors allow for a command line parameter to indicate which line number to position the cursor when opening a new file. By making a quick change to one of XSI”s scripts, we can communicate this to the external editor. To make this change, follow the steps below.

(By the way, I take no responsibility if something goes wrong and you have to reinstall XSI to get everything working again!)

  1. Navigate to C:\Softimage\…\Application\Commands
  2. Create a backup copy of “SDKHelpers.js” and call it something like “SDKHelpers.js_backup”.
    Note: it is important to change the file extension to something other than “js” as otherwise it will try to install the same commands twice and you”ll get a conflict.
  3. Navigate to line 106. It should be inside the “ShowFileForEdit_Execute” function at the line which says :
    if ( -1 != strExternalEditor.search( /%s/ ) )
  4. Replace everything inside that “if” clause, i.e:

        // (Mis)use the XSIUtils.Translate() API
        // to replace a %s token in the string with the file
        // name. This gives us lots of flexibility for supporting
        // different command line options for showing an external editor

        strCmd = XSIUtils.Translate( strExternalEditor, "None", in_file ) ;
        logmessage( "Launching " + strCmd, siVerbose ) ;
        XSIUtils.LaunchProcess( strCmd, false ) ;

    With this:

        strExternalEditor = strExternalEditor.replace(/%s/,in_file);
        if ( strExternalEditor.search( /%l/ ) != -1)
        {
            strExternalEditor = strExternalEditor.replace(/%l/,in_linenum);
        }
        XSIUtils.LaunchProcess(strExternalEditor);

  5. Save the file and restart XSI.

You can now use %l (that”s a lowercase L) in the filename for your external editor to pass the line number at the correct position in the command line options. Note that the original script already allowed for a %s parameter to be passed as a location to insert the filename to edit, and we have retained that functionality.

So for example, for JEdit you would use this in the external editor setting in the Script Editor Preferences:

    c:\jedit\jedit %s +line:%l

Personally, I use Crimson Editor, and my external editor setting is:

    C:\Program Files\Crimson Editor\cedt.exe /L:%l %s

Now if a script throws an error, you can click on it and your external editor will open the file at the correct line. This should make it a lot easier to use your external editor with XSI.

Have a good Christmas break!

4 Responses to “Debugging made easier”

  1. Looking forward to go back to work and try this trick on Visual Studio ; )

    Ciao Andy!

  2. To use it in Visual Studio, I think you need to do something like this:

    “C:\Program Files\Microsoft Visual Studio .NET\Common7\IDE\devenv.exe” “%s” /command “GoToLn %l”

    I”ve not tested it from XSI, but it should work.

  3. Excellent tip Andy! We will incorporate support for the %l into the official version of that script file so that people won”t have to modify the file to take advantage of this good idea.

    I”m glad advanced users are looking at that code and tweaking it to their personal taste, that was part of the reason it was exposed as JScript rather than internal code. We”ll try to keep improving the official version thanks to your suggestions.

    Also its a good tip to use Crimson Editor, I wasn”t familiar with it but find that it works better as a free external editor than Scintilla. E.g. if don”t reopen the same file multiple times, it uses multiple tabs by default and with this tip it can go to the correct line number!

    -Andrew

  4. Thanks Andrew. It”s v handy that you”ve exposed those scripts. I”ll have to make sure I dig through them at some point to see what else I can hack :-)