Step-By-Step ACSIL Debugging
- Enabling Debugging
Step-by-step debugging is possible Using the Microsoft Visual C++ Development Environment.
In order to perform debugging using this environment, your custom studies DLL file must be built with Visual C++.
- To access the debug functions we require, you must first change to Expert Mode - from the top menu in Visual Studio, select Tools >> Settings >> Expert Settings.
- Set the active configuration to Debug.
- Build the project by right clicking the project. When you build a project in debug mode, two important files are created. The study dll is one of them. In our example it is My Custom Study.dll .The second file is what is called a PDB file or Program Debug Database. In our example it is called My Custom Study Dll.pdb. If you want to see that project built to the right place and that you are ready to debug, you can check that these two files were created in your data directory.
- Start Sierra Chart, open a chart and add My Custom Study to the chart. For the sake of this howto, disconnect Sierra Chart from the datafeed.
- With Visual Studio, attach to the Sierra Chart process - from Visual Studio�s main menu, select Debug >> Attach to Process.
- In the Attach to Process dialog, Attach to must be set to native.
- From the list of Available Processes, select the Sierra Chart process and click Attach.
- In order to step through the code, we will set a break point. A breakpoint tells visual studio to stop program execution at a specific line of code. In order to set a breakpoint, click in the gutter which is found to the left of the source code area (see image below).
- In Sierra Chart, refresh the chart by selecting Chart >> Recalculate. This will cause Sierra Chart to recalculate all studies, which in turn will call the study function and halt at our breakpoint.
Basic command for stepping through your code
Once Sierra Chart program execution is halted by a breakpoint there are 3 basic commands to continue execution from this point.
- Step Over: can be accessed from the debug menu in visual studio or by pressing f10 on the keyboard. This command executes the current line at which the debugger is currently on and will move to the next line. If the current line is a function call, the function will be evaluated but the debugger will not drop in to the function code (that is why it is called Step Over).
- Step Into: can be accessed from the debug menu in visual studio or by pressing f11 on the keyboard. This command executes the current line at which the debugger is currently on and will move to the next line. If the current line is a function call, the debugger will drop in to the function code (that is why it is called Step Into).
- Start Debugging: can be accessed from the debug menu in visual studio or by pressing f5 on the keyboard. When the debugger has halted at some line, executing this command will cause the debugger to continue execution and will halt at the next breakpoint it encounters.
It is common to need to see the values of the variables in your study function. Once the program is halted in visual studio, there are 2 basic ways to do this:
- Hover over - hovering over a variable with the mouse will show the that variables values.
- Locals, Autos and Watch views - each one provides a bit of a different functionality and will be more useful than the other depending on your needs.
Breakpoint With Condition
When debugging code, either during a Backtest, Replay or by Recalculating, it is often the case where you need to debug a specific bar in the chart. Say that bar is bar number 5,000 in the chart. How can you stop on that bar specifically? One way to do this is to set a break point and watch sc.Index. When you reach 5,000, you know you have your bar. But that can take quite a while. A more efficient way to do this is by using a conditional breakpoint.
In Visual Studio, do the following:
- On the line you wish to halt execution, set a breakpoint.
- Right click the breakpoint which brings up a small menu - select Condition....
- In the condition menu, type sc.Index == 5000 (or any other condition for that matter).
Cannot access application GUI while stepping through
In general, Sierra Chart will continue to run normally and you can work with the application GUI while Visual Studio is attached. That said, when you halt execution during with a break point and are stepping through the study function code, the application GUI will no longer be available. This is normal and expected behavior.
Getting Your Code to Run
Your study function does not run all the time. Sierra Chart is responsible for calling your study function upon certain events. At this point your study function code is executed after which control is returned to Sierra Chart.
Some of these events include:
- When opening and applying the study settings dialog.
- When Recalculating the chart. In this case the study function is called for each bar in the chart and in sequence.
- When new trade or quote data is received from the real-time data feed for the symbol of the chart the study function is on. The study function is not called more often than the Chart Update Interval set in Global Settings >> General Settings .
- During a chart replay as data is read from the Intraday data file.
- Any change with trading related data for the symbol. This can be with an order, a position or a fill.
There are other instances when the study is called. How does this relate to debugging? Following the steps above, when you first attach to Sierra Chart process and set a break point, depending on what Sierra Chart is doing, you might not see execution stop at your break point. One way to determine that you have done everything correctly is to force Sierra Chart to call your study. The easiest way to do this is by Recalculating by selecting Chart >> Recalculate on the Sierra Chart menu. Make sure you put a breakpoint on a line in the code that is always reachable (not hidden in some if statement).
*Last modified Thursday, 08th November, 2018.