When there’s an underlying problem in code, it usually shows up as a symptom(s).
Tracing backward from the symptom(s), can lead back to the underlying problem.
Poetic Logic.
If no order was taken, was there an order scenario to take!
If yes, for an order not to be made, the order code may not have run!
Usually the order statement fall within a codeblock like ‘IF condition’.
The condition must have been false, not to activate the codeblock.
The condition may be several variables, one or all could have been false.
Finding and following back from the false variables, could lead to the underlying problem.
That’s the easiest way, however not having the full code turns a 2minute job into 2hours.
The hard way, systemically run through the code sequentially, and hope you spot something.
You may find ‘A problem’ but there no way of testing if it is ‘The Problem’ if you can’t run the code.
This is the beginning of the ‘that’s not it!’ start cycle, reward for you efforts, HAHA!
If no entry made,
then line 2, Gain = 0
and line 3, codeblock = false.
Additionally, when barindex = 0, the first bar, ‘BS’ probably defaults to zero,
making line 13 condition true and ‘spread’ = sp1 = 0.6
However, line 29, ‘Myspread = spread * BS’ …
If BS = 0, then any number multiplied by zero equals zero, 0.6 * 0 = 0
Line 34 is the first time ‘BS’ is assigned a value.
So, a guess would be, is ‘MYspread’ being zero, affecting later code, if its used, and is ‘BS’ reset to zero later aswell.
There could be another or simple solutions, but I’m not seeing it.
Anyway, that’s my attempt.
Regards