Interview with Stanislav Starikov: Features of New MQL5 - page 14

 
Great improvements! Looking forward to them! Thank you Stan!
 
phy:

What kind of changes will occur on server-side with MT5?


There seem to be many deficiencies to overcome/workaround when a Dealer, or more specifically a Broker, attempts to integrate MT4 with their systems.

To complete phy's question, will there be server-side automation like in Strategy Runner ?

 
Rosh:

Have you seen 'Tetris'? In addition I can tell a debugger will be too.

Personally I'm very unexcited by the new language features. The answers to the following kinds of question will potentially have a much, much bigger impact on most EA developers than new language features such as classes and inheritance:

  1. Are there going to be true market orders?
  2. Are there going to be OCO orders?
  3. Are trading functions still going to be synchronous, or are they going to be become asynchronous?
  4. Will there be partial fills? If so, are they going to be avoidable?
  5. Is the current position-based model going to be replaced by an order-based model? In other words, are "positions" simply going to become a derived function of the orders you have placed, as they are in other platforms, with the implication that the distinction between MODE_TRADES and MODE_HISTORY disappears?
  6. If yes to 5, is it going to be necessary - as it is on other platforms - to place t/p and s/l as separate orders rather than additional attributes of an opening order?

(These may be regarded as "MT5" features rather than "MQL5" features. But items 3 onwards would have a much greater impact on MQL developers, in terms of re-learning and re-writing existing code, than the sort of changes and additions demonstrated by the Tetris example.)

 

@jjc

"Are trading functions still going to be synchronous, or are they going to be become asynchronous?"

I think probably it's going to become asynchronous. OrderSend() will return a ticket of an unfulfilled order, and it's execution will be treated by execution events...

"Will there be partial fills? If so, are they going to be avoidable?"

If I would allow partial fills, then first partial fill should be without slippage, exactly like trading in a level II environment.

"Is the current position-based model going to be replaced by an order-based model? In other words, are "positions" simply going to become a derived function of the orders you have placed, as they are in other platforms, with the implication that the distinction between MODE_TRADES and MODE_HISTORY disappears"

This question seems a bit strange. All active orders, that make your current positions, are in MODE_TRADES, even the pending ones. So finding out your position completely excludes MODE_HISTORY.

"If yes to 5, is it going to be necessary - as it is on other platforms - to place t/p and s/l as separate orders rather than additional attributes of an opening order?"

You can always set TP/SL with an OrderModify(). Not needed to be intial parameters.

I'm waiting MT5 for lots of time. I have projects that need multiasset backtesting - and can't be done at all, also projects that either need events in order to work or need events for a quicker backtesting, so I'm fooling myself all the time with MT4 just to let the time pass....

 
TheEconomist:

This question seems a bit strange. All active orders, that make your current positions, are in MODE_TRADES, even the pending ones. So finding out your position completely excludes MODE_HISTORY.

It's "strange" in MT4, but it's entirely normal in other platforms. I wouldn't be at all surprised if MT5/MQL5 moves to a model where you place orders rather than opening positions. To "close a position", you then place an order in the opposite direction. In other words, you just place orders, and nothing but orders. "Positions" are then calculated automatically by the platform/broker from your order history, rather than being something you have direct control over. As a result, there is no distinction between "current" orders and "historic" orders (i.e. MODE_HISTORY and MODE_TRADES) - your position is simply a product of all the orders you have ever placed. This is perfectly normal in most trading environments. It's also normal to need to place a t/p or s/l as separate orders (on an OCO basis). If anything, it's MT4/MQL4 which is exceptional and strange.


I wouldn't be at all surprised if MT5/MQL5 moves towards this model, particularly because it would (a) solve the problems with the new NFA rule in the US, and (b) because it would open up MT5/MQL5 to DMA futures and equity trading.

 
jjc:

 To "close a position", you then place an order in the opposite direction. In other words, you just place orders, and nothing but orders. "Positions" are then calculated automatically by the platform/broker from your order history, rather than being something you have direct control over. As a result, there is no distinction between "current" orders and "historic" orders (i.e. MODE_HISTORY and MODE_TRADES) - your position is simply a product of all the orders you have ever placed. This is perfectly normal in most trading environments. If anything, it's MT4/MQL4 which is exceptional and strange.


I wouldn't be at all surprised if MT5/MQL5 moves towards this model, particularly because it would (a) solve the problems with the new NFA rule in the US, and (b) because it would open up MT5/MQL5 to DMA futures and equity trading.


So that means that current position on all contracts must be found by the station by requesting all orders that were opened on that account, from its opening to the current time, add lots on long trades and subtracting the short ones. I wonder how would that would work when a high frequency system will make a few hundred trades daily. Second, there will be a problem with pending orders. If you open a pending buy and a pending sell, the system should report no trades. It will report one trade if one is filled, and it will close the position when the second order is filled - that is how is going to be in the broker report - however for the trader, the orders will be kept intact and the trader will see both orders active. When one of them is closed and position is unhedged, in the broker report will appear like an order launch of the ticket that was not closed...pretty confusing... 

P.S. Don't forget that equity and futures trading exist also outside US. The rest of the world has no problem with hedging, and US brokers will be dumped by clients if they don't solve the problem. Of course, retail fx brokers... as for real, level II futures brokers that are involved in fx too, this would not happen, because their clients do not need it too much, they are not fx captive clients . All other types of financial instruments (probably might not be the case for bonds) - and I mean equities, futures, and options - these are traded in the same type of account, and clients look to pair trade or arb - they will most likely not open hedges the way fx traders do.

 
TheEconomist:

So that means that current position on all contracts must be found by the station by requesting all orders that were opened on that account, from its opening to the current time, add lots on long trades and subtracting the short ones. I wonder how would that would work [...]

Typically, on such a platform, an automated system maintains state information keeping track of the orders which it itself has placed. It doesn't repeatedly scan the entire order history reported by the platform. That's one of the reasons why such a change in MT5/MQL5 would be at least as significant for EA developers as new language features such as classes and inheritance.


P.S. Don't forget that equity and futures trading exist also outside US. The rest of the world has no problem with hedging, and US brokers will be dumped by clients if they don't solve the problem.

I know - I'm British. (And I know of a lot of accounts which have been transferred from US to UK because of the new NFA rule).

 

I have listened to the interview but have not been able to go through the 14 pages of thread as yet, but as a test engineer I would ask for a couple of helpful strategy tester improvements, since I would doubt we will be getting a real debugger with MQL5


1) Hot key the Pause/Start and speed arrow functions through out the different MST presentation windows. I can't tell you how many times I have wanted to be able to pause or speed up MST when in the graph or journal windows.


2) Allow docking of MST client in the MetaEditor. I believe the prodictivity improvements are self apparent.


3) PLEASE AT LEAST implement a puase/resume function that will allow us to have a break on condition. THere is nothing worse than having to fumble around a specific bar trying to stop the MST at the proper place to see why a condition did not trigger.


As Always,

I PRAISE your efforts to give the masses the tools to compete with the bankers (and others) that today seem intent on crushings every person on earths ability to make a better life for themselves.

 
johnmcglaughlin wrote >>

I have listened to the interview but have not been able to go through the 14 pages of thread as yet, but as a test engineer I would ask for a couple of helpful strategy tester improvements, since I would doubt we will be getting a real debugger with MQL5

1) Hot key the Pause/Start and speed arrow functions through out the different MST presentation windows. I can't tell you how many times I have wanted to be able to pause or speed up MST when in the graph or journal windows.

2) Allow docking of MST client in the MetaEditor. I believe the prodictivity improvements are self apparent.

3) PLEASE AT LEAST implement a puase/resume function that will allow us to have a break on condition. THere is nothing worse than having to fumble around a specific bar trying to stop the MST at the proper place to see why a condition did not trigger.

As Always,

I PRAISE your efforts to give the masses the tools to compete with the bankers (and others) that today seem intent on crushings every person on earths ability to make a better life for themselves.

For 1) You can use the Pause/Break key on your keyboard. I know what you mean, this drove me crazy too. I found this tip on this forum but it does not seem to be documented.

Also, in this thread I did read that they are going to have a real debugger. How 'real' or how good it's going to be we will just have to see.

What I am excited about is the new OOP language features and the new events. Event-driven programming is a must and will enable us to throw away much of the code we

had to write just to figure out what basic events have happened.

 
vangrosh:

For 1) You can use the Pause/Break key on your keyboard. I know what you mean, this drove me crazy too. I found this tip on this forum but it does not seem to be documented.

Also, in this thread I did read that they are going to have a real debugger. How 'real' or how good it's going to be we will just have to see.

What I am excited about is the new OOP language features and the new events. Event-driven programming is a must and will enable us to throw away much of the code we

had to write just to figure out what basic events have happened.

Bummer my pause /break key must not be mapped correctly.


I have tried in full screen mode as well, though that won't help the situation as I would be looking at the journal and full screen removes un docked windows as well.

oh now that I think of it...

4) Since the article eluded to NET usage (gasp) it would be very helpful to either

a) reference sub windows to the MT4 Main client Window monitor/screen/multiscreen id rather than the last opened location (I think this is coordinate based ) so that we can get at parameters when working remotely on single screen monitor.

b) treat undocked windows as MS windows so that they can be moved resized or Maximized when lost

basically come up with a method that assures we can get back subscreens with out having resort to blowing the terminal.ini file away.

Thanks

John

Reason: