A script is a simple text file, so you can type anything in it, even complete nonsense. But even scripts that look perfectly fine at first glance can behave very different than the programmer intended. In the simplest case, the compiler throws an error message and displays the faulty line. You should be able to fix that unaided. Otherwise just go again through the C tutorial.
In less trivial cases you'll see an error message when the script is running, and it may be not as informative. The worst case is code that gives no error message at all, but just does not do what it should, or even crashes or freezes. Don't panic: Any programmer encounters such issues all the time. Beginners can often not imagine that they made a mistake, and suspect a Zorro bug. Seasoned programmers are used to bugs in their code and know how to find and fix them. So get out of beginner mode as soon as possible. Utilize the many books and online seminars about the C language and script writing with Zorro. If you cannof find a bug in your script, check also your historical data - maybe it has gaps, outliers, or irregular time stamps that cause strange results. If you're really stuck, we provide a script fixing service. But first try to solve the problem on your own.
The best way to avoid bugs is good coding style that allows quick reading and understanding the code. This should be no problem with strategy scripts that are normally short and have a linear structure. Still, even a 20-line script can be written as a cluttered lump of spaghetti code. Some suggestions for avoiding bugs already when writing the script:
All error messages at compiling the script are simple syntax errors. Something is mistyped, or a bracket, quotation mark, or semicolon is missing (often in a previous line), or an object got the same name as a pre-defined function or variable (their names can be found in the include\functions.h and include\variables.h files), or a variable had a wrong type, or a function had wrong parameters. The script file and line in question is printed in the error message. This makes those errors easy to identify and fix, even for a beginner.
More subtle errors are not detected by the C compiler, but produce a message at runtime. Under error messages you'll find a list of all such errors and warnings, and their likely reasons. Messages related to opening and closing positions are listed under Log; known issues with brokers are described on the related page (FXCM, IB, Oanda, MT4, etc). The answers to many typical issues of script development can be found in the FAQ list.
If you see a strange number like like "1.#J" or "1.#IND" in the log or message window, or got Error 037, Error 011, or similar errors, you're likely having a buggy expression. Such as a division by zero at the begin of the simulation when indicators are not yet initialized and price series are still a flat line. A quick workaround for division bugs is replacing A / B with A / fix0(B).
If you see "(Null)" in the log, it's usually printing an uninitialized string.
If you see a runtime error message (like "Error 123: ....") in the message window, but have no clue at which part of your code the problem happens, the quickest way to find it is placing watch("?...") statements before suspicious places. The parameter is then displayed at the end of the error mesage. For instance, watch("?10") will add a (10) at the end of all subsequent error messages, and watch("?TEST") will add (TEST). You can remove the statements when the error is fixed.
If you trade live and see an error message beginning with an exclamation mark "!", it's a message from your broker, often giving the reason for not opening or closing a trade. For details, see Log about a list of all possible messages in a live trading session.
If backtest results seem not to be right, first look into the log (LOGFILE must be set). Select one or two trades and check them from begin to end. Script parameters can affect trade results in many different ways - make sure to check them all, and also read the remarks on their manual pages. Look for outlier trades with extremely high profits or losses. If needed, make sure that your script can deal with events such as price shocks or stock splits.
Most typical coding errors are easy to spot:
Other errors are not as easy to find. Typical problems:
You want your script to do something, but it refuses to obey and does something else instead. That's a bug. The worst bugs are those that go unnoticed. That's why you should always carefully check the log, even if you don't get any error messages and all seems ok. If you notice something wrong in the log - for instance, the script trades too often, or not often enough, or at the wrong time - first go through your code. Sometimes you will directly see what's wrong, sometimes not. Then you must debug it.
Debugging strategy scripts is a special case of program debugging. You're normally interested in the behaviour of a variable or signal from bar to bar. There are several methods to observe the behavior of variables, either from code line to code line, or from bar to bar, or during the whole test run:
A strategy in the visual debugger
DayOffset += 100./1440; // in a tock function: fast forward by factor 100 DayOffset += 10*BarPeriod/1440; // in the run function: fast forward by factor 10 DayOffset = FRIDAY - dow(NOW); // pretend it's Friday
They seem more serious, but are often easier to identify and fix than the bugs that only cause wrong behavior. You can encounter three types of crashes:
For fixing a freeze, first check all loops and recursions in your script and make sure that they terminate. Loops waiting for user input should check with a wait() call if the [Stop] button was hit. Most crashes are normally easy to fix when they happen regularly or always at the same bar or script position. They are only hard to find when they happen irregularly and their reason is not immediately obvious. Zorro has several mechanisms for detecting hard-to-find problems:
If the problem is not caused by the script - for instance, when it happend while trading a Z system - you need to look for an external reason. Activate diagnostics mode as above. If the program then freezes or crashes again, you can see in the last line of the diag.txt at which place it happened. This can indicate which module on your PC is possibly malfunctioning. There are websites and forums on the Internet with more hints for PC troubleshooting.
The hopefully least likely reason of script troubles is a bug in Zorro. Look first in the bug list. If you think you've encountered a new Zorro bug that no one else has seen before, please report it to firstname.lastname@example.org. Please describe what's happening under which circumstances and how to reproduce the problem; please include your script, the log, and all related data such as asset list and asset history. Do NOT send screenshots, videos, or photos that you took from your monitor (unless we ask for them). You need no support ticket for bug reports. If the bug can be confirmed, it will appear on the bug list and will normally be fixed within a few days.
Don't be disappointed when your bug report is quickly returned with the remark "no Zorro bug", since this happens with most of them. You can then safely assume that you'll be able to fix that bug. Use the methods described above, or hire our script fixing service.
If you're really stuck, you can subscribe a support ticket and contact email@example.com. There are two levels of support. Standard support will answer all Zorro questions by email usually within 24-48 hours on business days, and provide a solution for any technical problem. Priority support is for quickly solving urgent problems. It includes coding help and reviewing code snippets, alternatively by Skype chat, and usually within 2 hours from 8:00 - 18:00 CET on business days including Saturdays. The subscriptions can be cancelled anytime.
You don't need a support ticket:
What Zorro support cannot do is teaching the C language and debugging, fixing, or programming your script. For C, there are lots of books, tutorials, and online courses available. For fixing your script, hire our service at firstname.lastname@example.org. Depending on code complexity, it takes usually 1-2 hours to find and fix a bug. You can also hire a service for installing a system on your VPS, or for writing specific asset lists and data conversion scripts. The most frequent support issues are listed here.