Handling requotes in MT4 | Forex Factory

Options

Go to
Permalinks
Print Thread

Similar Threads

Requotes ----- 3 replies

Brokers and Requotes. 6 replies

REQUOTES explained please 4 replies

Dealing with Requotes in an EA 8 replies

Requotes 10 replies

Attachments: Handling requotes in MT4
Exit Attachments

Handling requotes in MT4

  • #1
  • First Post: Edited 6:39am Nov 2, 2018 5:52am | Edited 6:39am
Sure this has been covered before but would like to revisit it. Would like to confirm ideas or get new ideas

How do you handle requotes in MT4 within an EA?

Of course in manual trading in MT4 you can set an additional price differential (max slippage) and quickly re-click or resubmit an order manually as soon as you get a requote and usually it will get filled on the 2nd or 3rd try.

But on an EA, unless you have effective error checking and code to resubmit the order, your EA is dead on that trading cycle and could completely mess up your current trading algo's cycle thus turning a winning strategy into a losing one because of unfilled orders.

The simplest solution is to widen the spread by increasing the slippage on the ordersend, however I feel that once broker gets a feel for how much you are willing to give up on the slippage they will add a buffer to the spread whenever they can get away with it.

I want to keep a tighter slippage range and keep hitting the server at the offer until the order gets taken. Of course in fast moving markets this could take several attempts just like in manual trading, but with an EA it would only take mlliseconds or seconds at the longest.. I want the EA to do the work and need to have the orders filled exactly when the algo says trade.

How do you handle it?

Many say, use a "while" loop. This sounds good but if you have an EA that can have multiple open orders and hedges, an improperly coded while loop has the potential of submitting multiple trades when there should only be one for that magic number. For example if there is a delay in the reply from the server, your EA could end up submitting multiple trades until it gets a fill.

I have not tested the following code on a live market yet, intend to do so next week. However would like to get some opinions/feedback from some others who have tackled this problem of handling requotes in a live EA.

Here is the code that tests well, but as we know live trading in a fast moving market like the DOW will be the real test...

Do you see any potential hazards here? Or non useful code? The GV part is for another part of the EA and gets written after server returns a ticket number for the open trade.

Inserted Code
void fBuy1()
{result = OrderSend(Symbol(),OP_BUY,Lots,MarketInfo(Symbol(),MODE_ASK),Slippage,0,0,"Open LONG MN1",MN1,0,Blue);
if ((result == -1) && ((GetLastError() == 129) || (GetLastError() == 135) || (GetLastError() == 138))) fBuy1();
if (result > 0) {GlobalVariableSet("BuyValue1",iOpen(Symbol(),0,0)+(Slippage*Point)); Print("MN1 BUY SHOULD BE OPEN. Ticket #",IntegerToString(result,Digits)," >>  OpenTrades: ", OrdersTotal(), " , Last: ", DoubleToStr(Close[0], Digits), ", AcctMarginLevelInPerc: ", NormalizeDouble(AccountInfoDouble(ACCOUNT_MARGIN_LEVEL),0), ", AcctMarginInEquity: ", NormalizeDouble(AccountInfoDouble(ACCOUNT_MARGIN),0)); ResetLastError();}
if ((result == -1) && ((GetLastError() != 0) && (GetLastError() != 129) && (GetLastError() != 135) && (GetLastError() != 138))) Print("Open Buy MN1 ERROR #", GetLastError());
  • #2
  • Nov 2, 2018 8:46am Nov 2, 2018 8:46am
Add an if statement in your code to confirm prior to placing the order that no other open trade with the same MagicNumber exists.
  • #3
  • Edited 9:45am Nov 2, 2018 9:32am | Edited 9:45am
Quoting Pipologist
...unless you have effective error checking and code to resubmit the order, your EA is dead...
Correct. You need to have effective error checking for all possible cases, no way around this.

Quoting Pipologist
...the simplest solution is to ...increase the (acceptable) slippage...however...once broker gets a feel for how much you are willing to give up...
That's correct, again. Especially with bucket shops (used by many) you can rely on it, it's a big part of their business model.

Quoting Pipologist
...I want to keep a tighter slippage range and keep hitting the server at the offer until the order gets taken. Of course in fast moving markets this could take several attempts...
This is the right approach. I use a slippage parameter of 1 point as bad brokers will reject your order right away if you set slippage to zero. After I got a re-quote I immediately repeat the order with the updated price and keep trying for 5 times until I fail with an hard error. If this limit is too low you are with the wrong broker. Even on NFP I rarely get re-quotes if I'm with a ECN broker. Usually OrderSend() just hangs for plenty of time or even times out.

I would recommend switching brokers if you experience re-quotes on regular symbols as that is a sign of a bucket shop. CFDs are another story as the CFD pricing model is intransparent by definition and similar to OTC. So re-quotes on CFDs just confirm their CFD nature.

Quoting Pipologist
...{code}
Your code will fail in production.
(1) Don't use recursive function calls. Use a loop. :-)
(2) When working with such a loop define a clear "break" condition and stop if something went obviously wrong. Never use an infinite loop, as you do.
(3) Do not check only for errors you expect. Instead check for all known and unknown errors. You will be surprised. And you don't know what the future holds.
(4) Check for plenty of other things: validate every function argument (in reality you will #include your order functions and will have function arguments), MinLot, MaxLot, LotStep, IsStopped(), IsTradeContextBusy()
(5) Implement a messaging mechanism (mail, text message, push, chat, IM, whatever) to get notified on errors in your code. Your code is supposed to run most of the time in a non-supervised mode (on a server or VPS). You want to know when an order function starts to mis-behave.
It takes blood, sweat and enough tears to wash away the blood.
  • #4
  • Nov 2, 2018 10:33am Nov 2, 2018 10:33am
Quoting sakisf
Add an if statement in your code to confirm prior to placing the order that no other open trade with the same MagicNumber exists.
Yeah, order count per magic is/was implemented just not shown in code above.
  • #5
  • Nov 2, 2018 11:22am Nov 2, 2018 11:22am
Quoting emmzett
{quote} Your code will fail in production. (1) Don't use recursive function calls. Use a loop. :-) (2) When working with such a loop define a clear "break" condition and stop if something went obviously wrong. Never use an infinite loop, as you do. (3) Do not check only for errors you expect. Instead check for all known and unknown errors. You will be surprised. And you don't know what the future holds. (4) Check for plenty of other things: validate every function argument (in reality you will #include your order functions and will have function...
Can you tell me specifically why the code would fail in real time trading? I understand my code is unconventional.

I basically used the above code without the resending on requotes live last 2 weeks...The thing that was mucking things up was the requotes which I did not see coming until recently on the DOW cfds because of the wild volatility. So I added the infinite loop on requotes.

Again, don't want a while loop because of possibility of multiple uncounted orders being resent while EA is waiting for a fill confirmation. I'd rather have no order be sent than multiple repeated orders being sent. But, I absolutely don't want to miss a fill because of a requote.

You mentioned that you usually resend on requotes up to 5 times until you get a "hard error", what type of error do you expect to get after 5 requotes and 5 resends not getting filled?

I want the EA to keep sending on requotes or invalid price until filled, thus the infinite loop which breaks with a ticket number. The Inf Loop here is only for price related errors which I want filled immediately and if there is a fatal error that over loads the broker server in an inf loop, they can disable EA temporarily and I will address it and reload it later.

I am mostly concerned with requotes not getting filled or accidentally sending redundant orders on the same parameter or same magic number.

Any other errors, I'm not concerned with in real time because I can control and address those later.

But requotes on fast moving stock index cfds I want nailed down. If they don't fill a sent order on the bid or offer, I want the next bids or offers.

Order functions pertaining to Lots and lot sizes are in another part of code pertaining to MM not shown here are validated so not worried about those.

Not familiar with IsStopped(). In what case would it occur specifically? Have never had to confront that one in multiple years of using EAs.

Currently not using multiple EAs on same account so not concerned with IsTradeContextBusy(). Would IsTradeContextBusy() be true within a single EA environment?

This EA is sending multiple orders across 6 magic numbers, in this case with different parameters with up to 12 different order counts...six buys and six sells and up to 3 to 4 open positions max at a time. Not a run of the mill EA. All those functions are validated.

Sorry I can't show the rest of the EA. Just concerned with handling of requotes right now.
  • #6
  • Edited 4:58pm Nov 2, 2018 12:55pm | Edited 4:58pm
Quoting Pipologist
{quote} Can you tell me specifically why the code would fail in real time trading? I understand my code is unconventional. I basically used the above code without the resending on requotes live last 2 weeks...The thing that was mucking things up was the requotes which I did not see coming until recently on the DOW cfds because of the wild volatility. So I added the infinite loop on requotes. Again, don't want a while loop because of possibility of multiple uncounted orders being resent while EA is waiting for a fill confirmation. I'd rather have...
Outside of the program event handlers, your functions should never rely on global variables if at all possible. Also, there's nothing wrong with recursion, however there's several important things your function is missing and there's no way the last if statement could ever be evaluated so it is pointless in-effect. Perhaps something like this would make a bit more sense...
Inserted Code
bool market_order_no_requotes(const int order_type,
                              double volume,
                              const int magic=0,
                              uint max_tries=10)
{
   if(max_tries == 0)
      return false;
   ResetLastError();
   RefreshRates();
   double price = order_type == OP_BUY ? Ask : Bid;
   int ticket = OrderSend(_Symbol, order_type, volume, price, 1, 0.0, 0.0, NULL, magic, 0, clrLime);
   if(ticket >= 0)
      return true;
   switch(GetLastError()){
      case ERR_TOO_FREQUENT_REQUESTS:
      case ERR_TOO_MANY_REQUESTS:
         Sleep(1000);
      case ERR_TRADE_CONTEXT_BUSY:
      case ERR_PRICE_CHANGED:
      case ERR_OFF_QUOTES:
      case ERR_BROKER_BUSY:
      case ERR_REQUOTE:
         return market_order_no_requotes(order_type, volume, magic, --max_tries);
   }
   return false;
}
  • #7
  • Nov 2, 2018 3:05pm Nov 2, 2018 3:05pm
Quoting Pipologist
{quote} Can you tell me specifically why the code would fail in real time trading...
I will answer more detailed tomorrow as I'm quite busy at the moment. In between study Nick's post, please.

Quoting Nicholishen
{quote} Outside of the program event handlers, your functions should never rely on global variables...
Thank you Nick.
It takes blood, sweat and enough tears to wash away the blood.
  • #8
  • Nov 2, 2018 5:27pm Nov 2, 2018 5:27pm
I wanted to drop by with a quick follow up. The snippet I posted earlier doesn't require using the recursion pattern and could just as easily have been refactored using a for loop. OP, I'm not sure why you think that using a loop could result in several orders because OrderSend is a blocking call (synchronous).
Inserted Code
bool market_order_no_requotes(const int order_type,
                              double volume,
                              const int magic=0,
                              uint max_tries=INT_MAX)
{
   for(int i=0; i<max_tries; i++){
      RefreshRates();
      ResetLastError();
      double price = order_type == OP_BUY ? Ask : Bid;
      int ticket = OrderSend(_Symbol, order_type, volume, price, 1, 0.0, 0.0, NULL, magic, 0, clrLime);
      if(ticket >= 0)
         return true;
      switch(GetLastError()){
         case ERR_TOO_FREQUENT_REQUESTS:
         case ERR_TOO_MANY_REQUESTS:
            Sleep(1000);
         case ERR_TRADE_CONTEXT_BUSY:
         case ERR_PRICE_CHANGED:
         case ERR_OFF_QUOTES:
         case ERR_BROKER_BUSY:
         case ERR_REQUOTE:
            continue;
      }
      break;
   }
   return false;
}
  • #9
  • Edited Nov 3, 2018 1:14am Nov 2, 2018 7:37pm | Edited Nov 3, 2018 1:14am
Quoting Nicholishen
I wanted to drop by with a quick follow up.
Thank you for the code examples, I will study them and implement where I can.

The reason for the GV is to "lock in" a synthetic order open price and to use that synthetic price with percentage based SL and TP exits.

This EA in testing mode always bases entry prices on custom indi movement and Close[1] at the end of each bar and Open[0] at bid for sells and bar open bid plus tester slippage for buys. In reality the market is going to give me whatever it can at that price and time unless it's a limit order which may not get filled. However I need the EA to fill at the same time as in testing mode regardless of reasonable spread for that moment in time. So for example, currently I have synthetic openprices at bid or bid plus slippage, of course I may get filled at slippagex2 or x3 but it's ok as long as I get filled at the time algo says buy or sell.

One of the exit params is based on the time and percentage Close[1] is away from the orderopenprice at the end of each bar. By using the actual orderopenprice, just a few pips difference in the orderopenprice between testing (simulated price mode) and actual openprice mode changes the overall percentage move between open and end of bar, and thus changes the exit time by a bar or several bars which results in different results between testing mode and live mode. In short, I need the live EA to open and close trades at the end of the same bars in test mode regardless of difference in slippage...I'm not concerned with a few pips slip in either direction in terms of overall profitability, but I am concerned with missing an exit or an entry because of a few pips difference in calculation between test mode on a live account and live mode on a live account.

Therefore the GV keeps the synthetic orderopenprice which is bid of entrybaropen[0] or entrybaropen[0] plus slippage and closes a SL or TP based on the percentage move away from the synthetic open. This way the EA is entering and closing trades on the charted prices and not altered according to widening bid/ask. Most of the time the synthetic openprice is within plus or minus 5 pips of the acutual open price. Once the trade is confirmed closed, the GV synthetic open price level is deleted and the EA sets a new GV synthetic open price level on the next trading trade for that magic number. I'm not concerned with 5 pip differentials or occasional 10 pip differentials since SLs and TPs are very wide i.e. 50.00 to 100.0. dow points on SL and 100.00 to 300.00 dow points on TP. Over time, by hitting requotes I will also get occassionally get positive slippage as well so it's a wash, but again live trading EA has to fill at the same time as live testing EA would so I can compare effectiveness of the algos timing.

In short, I don't want the spread of actual live market to muck up the timing of entries and exits on the EA but I also want to prevent broker from saying "hey this guy always has a 10.00 slip in his EA so lets slip it to him."
  • #10
  • Nov 2, 2018 8:39pm Nov 2, 2018 8:39pm
Quoting emmzett
{quote} I will answer more detailed tomorrow as I'm quite busy at the moment. In between study Nick's post, please. {quote} Thank you Nick.
I would love the see the entire implementation from experienced coders like you and nick. Personally, I could not find ways to "beat the system" with MT4 as brokers will always have far superior controls to trick the EA. My research only concluded with "outcome of any strategy must not rely on tight spreads, slippage and trading costs" as a bullet-proof approach to system strategy development.

Also, has anyone done any quantitative research on HOW spreads are widened by the broker? Do bid and ask widen evenly from the midpoint or one goes wider or the other etc? This in itself should become a micro-edge :-
Staying in my lane...
  • #11
  • Oct 24, 2019 3:35am Oct 24, 2019 3:35am
Quoting Nicholishen
"Outside of the program event handlers, your functions should never rely on global variables if at all possible."
I know this is an old thread but I'd like to know your reasons for not using GVs in functions. Are you saying variables used only by a function should only have those variables within the function? Or is there something particular about GVs that will hamper a function from running optimally?

I'm working on something now that may work better with GVs and your comment has me reluctant now because there may be something that I'm not considering.
  • #12
  • Edited 6:29am Oct 24, 2019 6:12am | Edited 6:29am
Quoting Pipologist
{quote} I know this is an old thread but I'd like to know your reasons for not using GVs in functions. Are you saying variables used only by a function should only have those variables within the function? Or is there something particular about GVs that will hamper a function from running optimally? I'm working on something now that may work better with GVs and your comment has me reluctant now because there may be something that I'm not considering.
Let me try to answer that. In general there is nothing wrong with GV. But GVs are not reliable (anyone/any-code can delete them and break your program), not flexible enough (you have only a single data type), slow and considered a poor-man's-approach. Reliable code should be self-contained and independent from factors outside of the execution context, GV break that rule. GV are a bit like global variables so "global" that they are stored in a different universe (context). Nobody would do that in real software development, and so should you.

On the other hand there are some very specific cases where GV make sense. Those cases only exist because of the limitations of MetaTrader. In regular professional programming these cases don't exist, and there is no excuse to use them.

You can compare it a bit to the common approach to exchange data between MQL programs by using plain files. It is possible but very bad practice, a professional would lose it's job by doing so. It just shows that you are a beginner and don't really know how to do things the right/better way. Same goes for using global variables in code where you should use parameters and local variables. Just look at all the spaghetti code in the codebase of mql5.com. That's how clueless people work - and is by the way one of the many reasons for the high fail rate in retail trading.

ps: I don't know why I didn't link to my order logic for your problem in the first place, especially as somebody asked to see it. So here is the requote handling for OrderSend(). It works with a loop and tries to resend the order 5 times after a requote. You could increase that limit or remove it completely but I don't consider an infinite loop good practice. Better use a defined break condition. There is zero risk of an order submitted multiple times (what you are afraid of), and of course the code notifies me by email and text message if a requoted order didn't succeed after those 5 tries. Notifications are configured here.

As a general advice: You should leave a broker who requotes asap.
It takes blood, sweat and enough tears to wash away the blood.
  • #13
  • Oct 27, 2019 8:51am Oct 27, 2019 8:51am
Quoting emmzett
{quote} Let me try to answer that. In general there is nothing wrong with GV. But GVs are not reliable (anyone/any-code can delete them and break your program), not flexible enough (you have only a single data type), slow and considered a poor-man's-approach.
Thanks for the detailed reply. My gut feelings about them were the same as your reply here, anyone could break them and slower, were definitely on my mind. I was just trying to implement some workable solutions. I've re-coded to eliminate all GVs and will find out soon if I did it correctly.

Quoting emmzett
{quote} It just shows that you are a beginner and don't really know how to do things the right/better way.
Yes, years of off and on "programming" just does not come easily to me, even when I go into modes of continuous coding when I have the time. Coding is not my trade, however becoming more reliant on doing it myself. Since I'm not a pro-coder, I tend to make errors real coders would never do.

I think I've pretty much eliminated multiple sends or additional unintended lots. Hopefully the ea is persistent enough looping until I get a fill inside the intended slippage without missing them when the spread is widened or other unforeseen events. Not having trades filled when a signal is triggered is as maddening as having unintended trades filled. I don't mind trades filled several seconds later after several attempts in a fast moving market. Properly coded eas can try get those fills much faster than me hitting the order button several times. This is not a scalping ea so I don't mind the slippage but of course want to avoid it as much as possible too.

I looked at your code, for now it is too detailed for me to digest or implement immediately, however I appreciate your ideas and thought process. I'm sure it will be helpful to many others as well, even pro coders I feel will look at your approach and learn something.
  • #14
  • Oct 27, 2019 9:39am Oct 27, 2019 9:39am
Nobody is born as an experienced "coder", so don't worry and just go on. Experience will follow you immediately. There is a big difference between coding/programming and software development. Structured development requires an understanding of architecture ("structure" if you want to). It's like building a house. Everyone can put stone ontop stone but such a house will not last and break soon. To build a lasting and durable house it needs an architect, to lay the foundation, to use proper materials, to add structure where structure is needed.

If you face/are worried about unpredictable program flow (loops doing unintended things) then there is one major point you should pay attention to, and this point alone will lay the foundation for all your future coding experiences. This one point (the foundation) is error handling. Get used to the habit to finish every single function with an error handler, and popup an alert with whatever error happened.

The most lacking feature of MQL is integrated error handling. Instead of implementing a global error handler in MQL4 MetaQuotes decided to introduce OO features and to invent MQL5 which is a move in the wrong direction because the foundation was/is still missing. As MQL is a scripting language such error handling would have been easy to implement, it doesn't need to be exceptions etc. However MetaQuotes decided to go against best practices and today we see with MT5 where that has led us: a oneway ticket against a wall.

You have to close that gap first, and after you will be surprised how fast you can make progress with general coding. Without error handling all is lost in MQL. Sounds far-fetched but is true.
It takes blood, sweat and enough tears to wash away the blood.
  • #15
  • Oct 27, 2019 9:53am Oct 27, 2019 9:53am
The most simple global error handler can look like this:
Inserted Code
/**
 * Check if an error occurred and signal it. The error is stored in the global var "last_error". After the function returned
 * the internal MQL error code as read by GetLastError() is reset.
 *
 * @param  string location         - the error's location identifier incl. an optional message
 * @param  int    error [optional] - enforces a specific error (default: none)
 *
 * @return int - the occurred or enforced error
 */
int catch(string location, int error=ERR_NO_ERROR) {
   if (!error) error = GetLastError();
   else                GetLastError();
   if (error != ERR_NO_ERROR) {
      string message = StringConcatenate(location, "  [", ErrorToStr(error), "]");
      Alert("ERROR: ", Symbol(), ",", PeriodDescription(Period()), " ", message);
      last_error = error;
   }
   return(error);
}

You use it like in this example:
Inserted Code
/**
 * Main function
 *
 * @return int - error status
 */
int onTick() {
   if (IsBarOpenEvent()) {
      int trend = GetSuperTrend(SuperTrend.MODE_TREND, 1);
      if (trend == 1) {
         ClosePosition(OP_SHORT);
         OpenPosition(OP_LONG);
      }
      if (trend == -1) {
         ClosePosition(OP_LONG);
         OpenPosition(OP_SHORT);
      }
   }
   return(catch("onTick(1)"));
}

This catch() clause goes into each and every function before you return. This way there is zero chance for errors in your code. From there one can go on...

ps: The full error handler can become complex like here, it may support DebugView, email, text message, custom log files, whatever you wish.
It takes blood, sweat and enough tears to wash away the blood.
  • #16
  • Oct 27, 2019 10:05am Oct 27, 2019 10:05am
With such an error handler you can write logic like this:
Inserted Code
   if (!catch("onTick(1)")) {
      // all code worked without errors, let's continue
   }
   else {
      // an unhandled error occurred, we should stop trading
   }

Now it doesn't matter anymore where the error occurred, whether in the line directly before or in a completely different part of your program. You will catch it.
It takes blood, sweat and enough tears to wash away the blood.
  • #17
  • Edited Oct 28, 2019 12:20am Oct 27, 2019 10:04pm | Edited Oct 28, 2019 12:20am
When I first started coding for MT4 I used to bypass printing messages for each event that was triggered thinking only about the end results without confirming the processes as they happened. Of course I ignored error handling until I got errors in live trading. Again thinking that I'd catch them manually if they occurred. I had always thought that printing messages and confirming error messages was redundant since the server and compiler was there to do it. However, now I'm seeing it as having more complete control over the code and what it is doing.

Recently I've been including as many Print messages as possible before and after each function call so I can see when and what the code is doing on the server and not just rely on the server's standard replies. This way I can confirm the code is doing exactly what it should be doing at the same time and compare results against the tester.

I believe that a properly coded algo should be taking the trades at the same time that the tester shows, provided the data points are the same and the spread is accounted for. When the tester shows a new currently open trade, the live algo should have triggered an open trade at the same time on the same data, and closed at the same time as the tester without extra trades or missing entries or exits. When launching a new EA live, I always run the tester several times before and after each live trade to see if they match or how close they are (plus or minus a few ticks for live spread differentials). In practice the trades should match 100% or close to it. As my algos include more variables, getting the live trades to match the current tester's trades has been a challenge, but I think I've got that under control now, or very close to it. I want the trading algos to succeed or fail on their own, if they fail, I'd rather have them fail because of my errors in trading logic instead of errors in coding logic. The whole purpose of an ea for me is to eliminate emotional errors and to free up time.

Eliminating coding errors (technical and logical) has become even more important for me in the process. I understand how the markets function, but going through every line of code multiple times with a fine toothed comb and testing and re-testing until the code is free of controllable errors takes a lot of time. Not making excuses. Even with a perfectly coded ea, probability-wise the trading algo won't be profitable or sustain profitability for a significant period of time, but even so, the code needs to run as expected for that less than 1% outlier algo that validates the extra work and makes it worthwhile.

I'll take a look and see how I can implement even more error handling in the code.
  • #18
  • Edited 9:19am Oct 28, 2019 9:05am | Edited 9:19am
Trying to write perfect and error free code before going production is an illusion. As a human we are only able to prepare for errors we anticipate before they occur. This anticipation depends mainly and foremost on our current experience level: We can only prepare for what we know may happen in the future. We will never be able to prepare for things we don't know yet.

Runtime errors (that's errors in production) may be of logical or syntactical (ie. language) kind. By principe the compiler can help us only with syntactical errors. That means we are always left with an unknown amount of possible logical runtime errors we by definition cannot know before they occur. It is for this type of errors that error handling and logging is so important, as there is no other way to get feedback from running code.

Stop using Print() and start using DebugView for MQL. In my codebase you will not find a single Print() statement. Forget about the builtin terminal log window, DebugView tells you much better what is going on. It's configurable and you can define filters and colors. You may even connect to a remote machine during runtime. The most simple way to use it from MQL is very similar to the catch() function above:
Inserted Code
/**
 * Send a message to the system debugger.
 *
 * @param  string message          - message
 * @param  int    error [optional] - error code
 *
 * @return int - the same error
 *
 * Notes: The terminal must run with Administrator rights for OutputDebugString() to transport debug messages.
 */
int debug(string message, int error = NO_ERROR) {
   if (error != NO_ERROR) message = StringConcatenate(message, "  [", ErrorToStr(error), "]");
   if (IsTesting()) string application = "Tester::";
   else                    application = "MetaTrader::";
   OutputDebugStringA(StringConcatenate(application, Symbol(), ",", PeriodDescription(Period()), "::", WindowExpertName(), "::", message));
 //OutputDebugStringW(StringConcatenate(application, Symbol(), ",", PeriodDescription(Period()), "::", WindowExpertName(), "::", message));
  
   return(error);
}
Full code here. Use it like so:
Inserted Code
/**
 * Main function
 *
 * @return int - error status
 */
int onTick() {
   if (IsBarOpenEvent()) {
      int trend = GetSuperTrend(SuperTrend.MODE_TREND, 1);
      if (!trend) return(last_error);
      if (trend == 1) {
         if (!ClosePosition(OP_SHORT)) return(last_error);
         debug("onTick(1)  open short position closed");
        
         if (!OpenPosition(OP_LONG)) return(last_error);
         debug("onTick(2)  long position opened");
      }
      if (trend == -1) {
         if (!ClosePosition(OP_LONG)) return(last_error);
         debug("onTick(3)  open long position closed");
        
         if (!OpenPosition(OP_SHORT)) return(last_error);
         debug("onTick(4)  short position opened");
      }
   }
   return(catch("onTick(5)"));
}

You want to use excessive debug messages only in the development phase. In production you will remove most debug messages and rely on the error handling with catch().

Try not to prepare for all possible cases. That's not possible and you can't. Find a bullet-proof way to get notified of the unforeseen cases.

ps: Attached a screenshot from DebugView on a live remote machine.
Attached Image (click to enlarge)
Click to Enlarge Name: debugview.png Size: 129 KB
It takes blood, sweat and enough tears to wash away the blood.
  • #19
  • Mar 7, 2020 2:23am Mar 7, 2020 2:23am
Hi, I want to use the following code to overcome re-quote problem, i need your recommendation if it is safe to use this metho


RefreshRates();
bool buyOrder=OrderSend(Symbol(),OP_BUY,LotSize,MarketInfo(Symbol(),MODE_ASK),0,0,0,"Buy",0,0,Green);
while(GetLastError()==138)
{
ResetLastError();
RefreshRates();
buyOrder=OrderSend(Symbol(),OP_BUY,LotSize,MarketInfo(Symbol(),MODE_ASK),0,0,0,"Buy requote",0,0,Green);
}
  • #20
  • Mar 7, 2020 10:48am Mar 7, 2020 10:48am
Quoting maze123
Hi, I want to use the following code to overcome re-quote problem, i need your recommendation if it is safe to use this metho RefreshRates(); bool buyOrder=OrderSend(Symbol(),OP_BUY,LotSize,MarketInfo(Symbol(),MODE_ASK),0,0,0,"Buy",0,0,Green); while(GetLastError()==138) { ResetLastError(); RefreshRates(); buyOrder=OrderSend(Symbol(),OP_BUY,LotSize,MarketInfo(Symbol(),MODE_ASK),0,0,0,"Buy requote",0,0,Green); }
Use a slippage parameter of 1-2 points. Otherwise your code should be good.
It takes blood, sweat and enough tears to wash away the blood.
0 traders viewing now