Does MQL4 support any form of asynchronous notification?

 

Hello,

Is there any way of placing orders asynchronously in MQL4? (that is, at any time other than a new tick notification in start() function)

What I'm trying to do is to place a buy stop and/or sell stop orders within 2 pips of the price just before a news release. I don't want the order to be triggered before the news release time so I can't place it say 1 minute before the release. I can wait up to 2 seconds before the news release time to place the order, but there's no guarantee that a tick will be received at that time.

Any suggestions?

 
catsailor:

Any suggestions?

It seems pending orders are not good for you.

With the mt4ticker software (utility) you can send incoming ticks to your terminal in every defined amount of miliseconds.

 

It is unlikely that you will be able to place a pending order within 2 pips of the current price, many brokers increase their freezerange as well as the spreads just before important news times.

Do you realise that it is not guaranteed that a pending order will be filled at the price that you want? You could have your order triggered at a price much higher or lower than the price on the order.

 

With the mt4ticker software (utility) you can send incoming ticks to your terminal in every defined amount of miliseconds.

Thanks for the suggestion, I'll have a look at it.

It is unlikely that you will be able to place a pending order within 2 pips of the current price, many brokers increase their freezerange as well as the spreads just before important news times.

Do you realise that it is not guaranteed that a pending order will be filled at the price that you want? You could have your order triggered at a price much higher or lower than the price on the order.

I do realize both constraints. However, it seems that most pending orders triggered around news release, and despite the slippage, have a better chance of catching a price jump early on than any market order.

 

For those who are interested, I solved the problem described above by never exiting the start() function. This allows for precise time calculation (with 1 ms resolution) regardless of incoming ticks (See code sample below)

The only disadvantage is that in extreme market conditions, some ticks may be lost if two or more ticks were received within the 1 ms Sleep() function, and occasionally incoming ticks may be delayed by up to 1 ms. However, neither is a deal breaker for my strategy.

This code works fine, except that I found Sleep() is not really accurate and results in about 2 ms delay on my machine. The other thing is that I don't know if there would be any side effects on MT4 by not exiting start(). So far it runs fine but maybe someone knows of any reason why this shouldn't be done.

int start ()
{
    while (!IsStopped())
    {
        /* Process incoming tick here */
        ...

        while (!RefreshRates() && !IsStopped())   /* Check if a new tick is available */
        {
             Sleep(1);                            /* No new ticks, avoid hogging the cpu */
        }
    }
    return(0);
}
 
alladir:


What is the authorization part? The checks MT4 does on the order's prices before sending to the server? Surely that's not so long?


I don't know how it is actually called, it is an assumption based on observation.
 

how did you get on with 1ms sleep time? I do a similar thing but with 100ms. I was going to test different sleep times tomorrow.

If Xt is the execution time (in ms) for the code inside the second while loop, your approximate CPU utilization should be Xt*100/(1+Xt). If this code is deterministic and not doing too much calculations, then Xt should be in the order of few microseconds, thus total CPU utilization will be negligible.

How did you measure the 'actual' sleeping time?

Sleep(1) in a loop for 100,000 times, divide the time difference between before and after the loop by 100,000

Why are pending orders better for catching news events?

Because you avoid all the delays associated with a market order from the time you place it until it gets to the queue, by which time many ticks would have been received. Of course you have better control over slippage with market orders and you may be slipped respectable amount of pips with stop orders, but it's a risk you must be willing to take.
 
catsailor:

Are you implying that all brokers will try to slow you down if you start making money?

Surely there are some brokers out there who will, and I've heard this so many times, but I don't see any reason for an ECN or DMA broker to try and make you lose money, after all they're getting their commission regardless of your success or failure (assuming of course, by claiming to be DMA/ECN, they're not trading against you)

If what you say is true, then there's no point of trading to start with, and all what we're doing becomes a colossal waste of time.

Not all brokers. And not if you start making money in general. But very probably it happens if you start making money using this style. No idea why they do not like it, if all of them claim to be an ECN broker. But they don't like it.

The picture below is FxPro, which was the worst case I ever met. The Buy stop order for 3 contracts was placed 5 seconds before the news release. The price did not gap directly, it was ticking up continuously through the stop order and its TP, and finally, after appx 7 seconds, it has been filled with a huge slippage. And this was happening every time since.

 

But very probably it happens if you start making money using this style

Are you speaking from experience? If yes, was it was just one broker or multiple brokers? Did you compare the tick stream from multiple brokers to see how it looked around the same news release compared to yours?

The following two images are the tick stream from two different brokers around the same news release time (08:30 EST) for EURUSD. As you can see broker 1 on the left had about 7 seconds delay and 17 pip jump between ticks before and after the news (vertical grids are 10 seconds apart) compared to the more uniform ticks from broker 2. However, this was the only time I've seen such a time gap from broker 1 and by no means it is sufficient to judge their performance. My point is that if this happened to you just one time, you can't say the Broker is doing something fishy, even though it looks that way.

Broker 1 Broker 2

Finally, does anyone else on here have a similar experience as Ovo?

 

Sorry I missed the second part of your post with the picture.

I don't think it's allowed to discuss brokers by name on here.

I don't see why your orders didn't get filled at any of the ticks before 0.98200 unless there isn't enough liquidity. It is certainly something to question your broker about and maybe if you don't get a satisfactory answer, it's time to change brokers. I know all my stop orders get filled at the first tick after the trigger price, but I'm trading EURUSD and my order size never exceeds 2 lots.

 

@catsailor:

Humm, how can I put this, been visiting this forum almost daily and read every post trying to answer other peoples questions. I cannot remember when someone posted about how excited they were that such a strategy worked for them. <--Some people might read this and think, well maybe they want to keep it top-secret. If you believe it's top-secret then perhaps no-one winning with this strategy will respond with what you want to hear. You'll just have to test everything yourself, and then report here. Fat_Chance you'll report back no matter which result you get.

Here are some things I want to note.

  • Spreads are high before/during a news event.
  • Stop orders will suffer from Slippage.
  • Brokers freeze platform during these events.
  • Markets is_not always calm before New event.
  • Everyone trying to get orders @ last moments.
  • News may not be delivered on time.
  • You have no_idea which direction it'll go.
  • Hedge orders runs risk of both getting triggered.

If you think you know the results of up_comming news:

  • Why don't you place the market_order minutes ahead?
  • My guess is that you don't know...
  • And market direction is volitile during news release
  • And half the time, it doesn't go in direction of good news

So, somehow, you're trying to guarantee Stop_Orders during news events. You're entering with Stop_Orders and you're also trying to reduce you risk with Stop_Orders. But this is the absolute worse time to be using Stop_Orders. You're thinking, humm, I'm gonna use this lose small_Stoploss and gain this huge_TakeProfit.

  • Don't be surprised should your Long_Orders enter @ the very top due to Spreads.
  • Don't be surprised should your Long_Orders enter @ the very top due to Gaps.
  • Don't be surprised should your Long_Orders enter @ the very top due to Terminal Freezing.
  • Don't be surprised should your small StopLoss take you out most times due all the Above.
  • If you intend to Sand-wish the price in between BuyStop and SellStop... don't be surprised should both get trigger and result in stop_loss.
Reason: