Prakash's Martingaled Hanover

[gaheitman]

Steve,

I think the issue is in ShouldWeMartingale(). It's referencing bid and ask, though it might be trying to enter a trade in a different symbol.

Code: Select all

void ShouldWeMartingale()
{
   //Looks to see if a losing trade is >= PointsLossToTriggerTrade in the hole, and sends a fresh martingale trade if so.
   //Trades are in the direction of the losing trade. Sounds bonkers to me, but there you are.
   
   //Calculate lotsize 
   //TicketNo saves the ticket of the most recently sent trade
   if (!OrderSelect(TicketNo, SELECT_BY_TICKET, MODE_TRADES) ) return;
 
   double SendLots = OrderLots() * MartingaleLotMultiplier;
   if (SendLots > MaxLotsAllowed) SendLots = Lot;
   
   RefreshRates();
 
   if (OrderType() == OP_BUY)
   {
      if (OrderOpenPrice() - Ask > (PointsLossToTriggerTrade * Point))
      {
         bool result = SendSingleTrade(OrderSymbol(), OP_BUY, TradeComment, SendLots, Ask, 0, 0);         
      }//if (OrderOpenPrice() - Ask > PointsLossToTriggerTrade * Point)
   }//if (OrderType() == OP_BUY)
   
   
   if (OrderType() == OP_SELL)
   {
      if (Bid - OrderOpenPrice() > (PointsLossToTriggerTrade * Point))
      {
         result = SendSingleTrade(OrderSymbol(), OP_SELL, TradeComment, SendLots, Bid, 0, 0);
      }//if (Bid - OrderOpenPrice() > PointsLossToTriggerTrade * Point)
   }//if (OrderType() == OP_SELL)  
   

}//void ShouldWeMartingale()

EDIT: OK, I'm not just a "problem-pointer-outer", here's one way to fix the code.

Code: Select all

void ShouldWeMartingale()
{
   //Looks to see if a losing trade is >= PointsLossToTriggerTrade in the hole, and sends a fresh martingale trade if so.
   //Trades are in the direction of the losing trade. Sounds bonkers to me, but there you are.
   
   //Calculate lotsize 
   //TicketNo saves the ticket of the most recently sent trade
   if (!OrderSelect(TicketNo, SELECT_BY_TICKET, MODE_TRADES) ) return;
 
   double SendLots = OrderLots() * MartingaleLotMultiplier;
   if (SendLots > MaxLotsAllowed) SendLots = Lot;
   
   RefreshRates();
   
   double sym_bid = MarketInfo(OrderSymbol(),MODE_BID);
   double sym_ask = MarketInfo(OrderSymbol(),MODE_ASK);
   double sym_point = MarketInfo(OrderSymbol(),MODE_POINT);
   
 
   if (OrderType() == OP_BUY)
   {
      if (OrderOpenPrice() - sym_ask > (PointsLossToTriggerTrade * sym_point))
      {
         bool result = SendSingleTrade(OrderSymbol(), OP_BUY, TradeComment, SendLots, sym_ask, 0, 0);         
      }//if (OrderOpenPrice() - sym_ask > PointsLossToTriggerTrade * sym_point)
   }//if (OrderType() == OP_BUY)
   
   
   if (OrderType() == OP_SELL)
   {
      if (sym_bid - OrderOpenPrice() > (PointsLossToTriggerTrade * sym_point))
      {
         result = SendSingleTrade(OrderSymbol(), OP_SELL, TradeComment, SendLots, sym_bid, 0, 0);
      }//if (sym_bid - OrderOpenPrice() > PointsLossToTriggerTrade * sym_point)
   }//if (OrderType() == OP_SELL)  
   

}//void ShouldWeMartingale()

George

Steve, I am still getting error 129 for already open trades (same things as reported by auvergnat). The very last update running here.

[SteveHopwood]

I forgot to adapt the function that calculates whether a trade needs a subsequent Martingale trade adding.

It works by comparing the trade open price with the market, and sending a fresh trade at x pips loss. I forgot to adapt Ask and Bid (for the coders also Point and Digigs) to multi-pair use and so the bot was:

• Incorrectly comparing the open price of the trade with the Bid of the EA hosting chart
  Finding the trade was losing enough to be Martingaled
  Attempting to send the trade at the market price of the host chart
  Finding the price it was attempting to trade was incorrect and telling us about it. Well-behaved sort of bot.
  The forgetting all the previous and trying again at the next ticke. Well behave but thick little bot.

Ok, so there is a vague, dim chance that all is working correctly now. Just remember my signature, ok?

Update in post 1.

George, if you are reading this, you begin to see why I refuse to use version numbers? Not sure which V we would be up to by now, but imagine the size of the EA box in my Navigator window.

[gaheitman]

Isn't that what we use the second monitors for? :>

George, if you are reading this, you begin to see why I refuse to use version numbers? Not sure which V we would be up to by now, but imagine the size of the EA box in my Navigator window.

[gaheitman]

Steve,

You may already be working on this, but in the original Hanover thread Panamamike was asking about controlling trade direction for currencies that are likely to see intervention and referenced the TradeDirectionBySwap() code. In looking at it to see how easy it would be to convert to his desired use I noticed that it is also looking at the symbol() the ea is attached to instead of the symbol to be traded...

George

I forgot to adapt the function that calculates whether a trade needs a subsequent Martingale trade adding.

It works by comparing the trade open price with the market, and sending a fresh trade at x pips loss. I forgot to adapt Ask and Bid (for the coders also Point and Digigs) to multi-pair use and so the bot was:

• Incorrectly comparing the open price of the trade with the Bid of the EA hosting chart
  Finding the trade was losing enough to be Martingaled
  Attempting to send the trade at the market price of the host chart
  Finding the price it was attempting to trade was incorrect and telling us about it. Well-behaved sort of bot.
  The forgetting all the previous and trying again at the next ticke. Well behave but thick little bot.

Ok, so there is a vague, dim chance that all is working correctly now. Just remember my signature, ok?

Update in post 1.

George, if you are reading this, you begin to see why I refuse to use version numbers? Not sure which V we would be up to by now, but imagine the size of the EA box in my Navigator window.

[SteveHopwood]

Steve,

You may already be working on this, but in the original Hanover thread Panamamike was asking about controlling trade direction for currencies that are likely to see intervention and referenced the TradeDirectionBySwap() code. In looking at it to see how easy it would be to convert to his desired use I noticed that it is also looking at the symbol() the ea is attached to instead of the symbol to be traded...

George

No, I wasn't George. I had not realised, or I would have done something about it. Kind of you not to accuse me of being a total thickie.

Your post sent me looking. There turned out to be umpteen such instances of Symbol() used where they should have been substituted by TradePair.

Latest update in post 1.

I have been through the code and made the necessary changes. The only danger now is that I have changed some instances of Symbol() where the change was unwarranted, or that I have replaced it with the incorrect variable. It is possible George; trust me to know about these thingies.

As MH is a child of Hanover, I have made the same changes to Hanover, so users/coders need to download the changes made there as well.

Thanks again George. Yet another piece of priceless bloop-spotting.

[gaheitman]

Steve,

I think I see another potential issue with the code. (I know, I know, who invited this guy?)

Our reliance now on using TradePair causes an issue if TradePair changes. I don't think that TradePair jumps all around during the day, but when it does change, we lose track of all of our open trades.

For example, CountOpenTrades() will set TicketNo = -1 and OpenTrades = 0 since it has this test:

Code: Select all

      if (OrderSymbol() == TradePair && OrderMagicNumber() == MagicNumber)

Currently the code in LookForTradeClosure() is skipped by the return at the top, and that appears to be the only test for a TradePair change.

George

Steve,

You may already be working on this, but in the original Hanover thread Panamamike was asking about controlling trade direction for currencies that are likely to see intervention and referenced the TradeDirectionBySwap() code. In looking at it to see how easy it would be to convert to his desired use I noticed that it is also looking at the symbol() the ea is attached to instead of the symbol to be traded...

George

No, I wasn't George. I had not realised, or I would have done something about it. Kind of you not to accuse me of being a total thickie.

Your post sent me looking. There turned out to be umpteen such instances of Symbol() used where they should have been substituted by TradePair.

Latest update in post 1.

I have been through the code and made the necessary changes. The only danger now is that I have changed some instances of Symbol() where the change was unwarranted, or that I have replaced it with the incorrect variable. It is possible George; trust me to know about these thingies.

As MH is a child of Hanover, I have made the same changes to Hanover, so users/coders need to download the changes made there as well.

Thanks again George. Yet another piece of priceless bloop-spotting.

[SteveHopwood]

Steve,

I think I see another potential issue with the code. (I know, I know, who invited this guy?)

Our reliance now on using TradePair causes an issue if TradePair changes. I don't think that TradePair jumps all around during the day, but when it does change, we lose track of all of our open trades.

For example, CountOpenTrades() will set TicketNo = -1 and OpenTrades = 0 since it has this test:

Code: Select all

      if (OrderSymbol() == TradePair && OrderMagicNumber() == MagicNumber)

Currently the code in LookForTradeClosure() is skipped by the return at the top, and that appears to be the only test for a TradePair change.

George

Cheers George. All this is deliberate. LFTC is disabled; I left the code in place in case I change my mind. These trades are intended to close by hitting tp or sl. It does not matter if TradePair changes; what matters is that the bot does not send duplicate trades for the current TradePair.

To produce as many EA's as I do demands that I have a sell to adapt quickly and easily. The less code I have to delete, the more quickly I can adapt it. This inevitably leaves behind redundant code, but I figure I can remove it if a bot turns out to have legs.

With functions such as LFTC, it is no use simply not calling it. There are people with sufficient knowledge to do a re-compile, but not enough to understand the resulting 'warning', and I have to explain it to them.

Thanks anyway. Please keep going; you are usually right.

[gaheitman]

Steve,

I don't think the ShouldWeMartingale() code will get called if the TradePair changes, since TicketNo = -1. Of course, in real life if the TradePair changes it means our position probably wasn't doing too well in the first place and we already placed our martingale trade. Then again, if we did, and the TradePair changes we won't ever set "upl" equal to anything so won't know when to get out of our trades.

I think my concerns are strictly based on program logic and are not taking into account the data stream the program expects. If we'll get knocked out of our trades at TP or SL long before the TradePair changes, then none of what I'm saying matters much for this bot. It might matter for other multi-currency bots in the future, however.

BTW, there is no question in my mind regarding your speed and ability to produce solutions!

George

Steve,

I think I see another potential issue with the code. (I know, I know, who invited this guy?)

Our reliance now on using TradePair causes an issue if TradePair changes. I don't think that TradePair jumps all around during the day, but when it does change, we lose track of all of our open trades.

For example, CountOpenTrades() will set TicketNo = -1 and OpenTrades = 0 since it has this test:

Code: Select all

      if (OrderSymbol() == TradePair && OrderMagicNumber() == MagicNumber)

Currently the code in LookForTradeClosure() is skipped by the return at the top, and that appears to be the only test for a TradePair change.

George

Cheers George. All this is deliberate. LFTC is disabled; I left the code in place in case I change my mind. These trades are intended to close by hitting tp or sl. It does not matter if TradePair changes; what matters is that the bot does not send duplicate trades for the current TradePair.

To produce as many EA's as I do demands that I have a sell to adapt quickly and easily. The less code I have to delete, the more quickly I can adapt it. This inevitably leaves behind redundant code, but I figure I can remove it if a bot turns out to have legs.

With functions such as LFTC, it is no use simply not calling it. There are people with sufficient knowledge to do a re-compile, but not enough to understand the resulting 'warning', and I have to explain it to them.

Thanks anyway. Please keep going; you are usually right.

[SPR]

Steve, there are 2 EAs in post 1 with the same name. Please delete the "old one". I cannot decide which one is the latest. Version numbers, you see?

[SteveHopwood]

Steve, there are 2 EAs in post 1 with the same name. Please delete the "old one". I cannot decide which one is the latest. Version numbers, you see?

Hmmmmmm. Someone with a death wish, I see. I need a smilie of a madman with a howitzer.

I don't know which was the correct version either. They are probably both the same and I uploaded twice. I have removed them both and uploaded the latest.