Spam in the output window

[AnotherWorkingHomeless]

I can't seem to get the output window under control. I have some criteria to exit positions and print the exit reason, but it seems like regardless of the prequalifying "if" statement to have an open market position, the Print outputs are still being called unnecessarily.

I had tried to combine them with "&&", but Ninjatrader rejected this saying it was impossible. Is there a way to get this under control?



if (Position.MarketPosition == MarketPosition.Long);
//if flat do nothing, nested statement below

{
if (GetCurrentBid(0) >= (Position.AveragePrice + 0.05))
{
ExitLong(Convert.ToInt32(SellHalf), "", "");
Print(Instrument.FullName + " Sold half at " + Close[0]);
}

//set3.25

if (GetCurrentBid(0) >= (Position.AveragePrice + 0.10))
{
ExitLong(Convert.ToInt32(Sell3of4), "", "");
Print(Instrument.FullName + " Sold 3/4 at " + Close[0]);
}




//set 4; stop

if (GetCurrentAsk(0) < (Low[1]))
{
ExitLong(Convert.ToInt32(ShareSize), "", "");
Print(Instrument.FullName + " Exited by Previous Bar Low Violation. Previous Bar Low was " + Low[1]);
}
}

[NinjaTrader_Kate]

Hello AnotherWorkingHomeless,

Thank you for your post.

So if the Current bid is 0.10 above the current price, both the first two sets would try to execute. I'd suggest the following change to the first set:

if (GetCurrentBid(0) >= (Position.AveragePrice + 0.05) [B]&& GetCurrentBid(0) < (Position.AveragePrice + 0.10)[/B])

That way, the first print only prints if it's between those prices when it exits.

For the last set, I would try adding conditions that would keep this from getting executed when the others are true:

if (GetCurrentAsk(0) < (Low[1]) 
[B]&& (GetCurrentBid(0) >= (Position.AveragePrice + 0.05) && (GetCurrentBid(0) < (Position.AveragePrice + 0.10) == false )
                && (GetCurrentBid(0) >= (Position.AveragePrice + 0.10)) == false)[/B])
            {

            }

Please let us know if we may be of further assistance to you.

[bltdavid]

I can't seem to get the output window under control. I have some criteria to exit positions and print the exit reason, but it seems like regardless of the prequalifying "if" statement to have an open market position, the Print outputs are still being called unnecessarily.

I had tried to combine them with "&&", but Ninjatrader rejected this saying it was impossible. Is there a way to get this under control?



if (Position.MarketPosition == MarketPosition.Long); <--- what is this ';' doing here?
//if flat do nothing, nested statement below

{
if (GetCurrentBid(0) >= (Position.AveragePrice + 0.05))
{
ExitLong(Convert.ToInt32(SellHalf), "", "");
Print(Instrument.FullName + " Sold half at " + Close[0]);
}

//set3.25

if (GetCurrentBid(0) >= (Position.AveragePrice + 0.10))
{
ExitLong(Convert.ToInt32(Sell3of4), "", "");
Print(Instrument.FullName + " Sold 3/4 at " + Close[0]);
}




//set 4; stop

if (GetCurrentAsk(0) < (Low[1]))
{
ExitLong(Convert.ToInt32(ShareSize), "", "");
Print(Instrument.FullName + " Exited by Previous Bar Low Violation. Previous Bar Low was " + Low[1]);
}
}

Check my comment above in red.

Your entire logic can be annihilated by a single semi-colon.

Is that ';' necessary there?

[AnotherWorkingHomeless]

bltdavid,

Thank you so much for looking and pointing that out. It totally solved the problem.

[bltdavid]

Thank you so much for looking and pointing that out. It totally solved the problem.

You're welcome!

By now you must realize your code was syntactically correct, since the compiler
never produced an error. This is one of those life lessons in programming, where
you learn the limitations of the compiler's ability to find programming errors, and how
a single misplaced semi-colon can produce disastrous consequences. Believe
me, your not the first person to get bitten like that.

So, what do you do when you're alone? Say, it's 2am and there is no chance
of benefiting from a second pair of human eyes. What can you do?

In this post I'll discuss an insightful and useful coding technique that automatically
avoids this bug in the future.

The first thing to realize is this:

The reason the compiler offered you no help in finding the erroneous semi-colon
is because there was no else if and/or else statement attached to your if
statement.

Yep, pretty simple, eh? Sounds obvious to experienced programmers, but this is usually
one of those painful realizations learned solo by new programmers. The epiphany this
reveals in your mind is like a right of passage to your growing knowledge: some mistakes
in programming are actually huge learning events. Let's investigate that.

In the code example below,
note how the compiler always "finds" the misplaced semi-colon,

if (Position.MarketPosition == MarketPosition.Long)[B][COLOR=#FF0000];  // <-- this ';' is erroneous[/COLOR][/B]
{
    if (GetCurrentBid(0) >= (Position.AveragePrice + 0.05))
    {
        ExitLong(Convert.ToInt32(SellHalf), "", "");
        Print(Instrument.FullName + " Sold half at " + Close[0]);
    }
}
[COLOR=#FF0000]else if [/COLOR](Position.MarketPosition == MarketPosition.Short) [B][COLOR=#FF0000]// <-- compiler error here[/COLOR][/B]
    /* do nothing */ ;
[COLOR=#FF0000]else if [/COLOR](Position.MarketPosition == MarketPosition.Flat)
    /* do nothing */ ;

Why the compiler error so late?

Because the compiler has found a dangling 'else if' that is not properly
attached to the if (or else if) immediately before it. In other words, that
misplaced semi-colon screws up the following code, so the compiler gets
confused and prints an error message.

And that's the point. Do you see it?
That else if statement serves its own useful purpose by "guarding" against
any dumb human errors occurring before it.

That else if forces the compiler to bless you with its help:
You get an error message to study and resolve, which gives you a fighting
chance to find the semi-colon error on your own and resume your 2am
late-night coding session -- all by yourself.

That's one reason why code like this,

if (Position.MarketPosition == MarketPosition.Long)[B][COLOR=#FF0000];  // <-- this ';' is erroneous
    ... do something ... ;[/COLOR][/B]
[COLOR=#FF0000]if [/COLOR](Position.MarketPosition == MarketPosition.Short) [B][COLOR=#FF0000]// <-- no compiler error here[/COLOR][/B]
    ... do something ... ;
[COLOR=#FF0000]if [/COLOR](Position.MarketPosition == MarketPosition.Flat)
    ... do something ... ;

can be a bad idea. Sure, it is syntactically correct, but avoidance of employing the
else if clause means the compiler won't help you find a misplaced semi-colon.

Anyways, this is really basic stuff, but sometimes it helps to understand how
some coding techniques are actually doing more 'protective work' under the
hood than others.

Moral of the story: don't dismiss the importance of else if statements too quickly.

Just my 2˘.

PS:
Naturally, switch statements avoid this issue, since their syntax is completely
different -- but what they really do is introduce a different set of subtle nuances.