Services. Are they up and running yet? - page 22

New comment
 
What does this Service print when there are no open charts in the Terminal? 
#property service

void OnStart()
{
  Print(ChartID());
}
 
In Services, getting the Terminal Handle is difficult.
// Получение хендла Терминала в Сервисе.

#property service

#include <fxsaber\MultiTester\MTTester.mqh> // https://www.mql5.com/ru/code/26132

void OnStart()
{
  printf("%X", MTTESTER::GetTerminalHandle());
}
 
The main problem of Services is not the Terminal Handle - it's all the marginal use cases.
A more important area - building back-office trading support systems (performing calculations of own REs, risk indicators for the whole portfolio, etc.) requires events like OnTradeTransaction etc. - now there are no such account-specific events at all; it is strange and unpleasant that they were forgotten to be added.
Adding these events in Services functionality should be in the first priority of MT5 object development, becausebasic desktop functionality of MT5 is front-office in fact, there is no back at all, and traders who know about trading strategies have to do the back by hand.
 
Sergey Lebedev:
The main problem with Services isn't the Terminal Handle - it's all the margin application cases.
A more important area - building back-office trading support systems (doing calculations of own GOs, portfolio-wide risk indicators etc.) requires events like OnTradeTransaction etc - now there are no such account-specific events at all; it's strange and frustrating that they were forgotten to be added.
Adding these events to the Services functionality should be the first priority in the development of this kind of MT5 object, sincethe basic MT5 desktop functionality is essentially front-office, there is no back-end at all, and traders who know about trading strategies have to do the back-end by hand.

I don't get it.

 
fxsaber:

I didn't understand a thing.

Services need additional event functions, or preferably one function for custom events.
And these events should not be constants of the terminal, so that the user can define custom events for this function.

 
Roman:

Services needs additional event functions, and preferably one function for custom events.

It is probably best to write scenarios for the use of Services first. For example, what is"building back-office trade support systems".

 
fxsaber:

It is probably best to write scenarios for the use of Services first. For example, what is'building back-office trade support systems'.

The first thing that comes to mind is a recent one.
See, for example, in neighbouring exchange branches they do not understand why the balance changes with an incomprehensible entry.
Because the MT server side does not calculate the net result of the clearing recalculation of dollar instruments.
With the service, you can calculate the net result and keep your own accumulated balance and CS, taking into account the clearing recalculations.
This is the back office, i.e. those actions that should be done either by the broker or the terminal functionality, but for one reason or another it is not done.

 
Roman:

The first thing that came to my mind, the newest one.
Look, for example in neighboring stock branches, they don't understand why balance changes with unclear entry.
Because the MT server side does not calculate the net result of the clearing recalculation of dollar instruments.
With the service, it is possible to calculate the net result and keep your balance of accumulated funds and CS, taking into account the clearing recalculations.
This is the back office, i.e. those actions that should be done either by the broker or the terminal functionality, but for one reason or another it is not done.

It is not clear what this looks like. Let's say the idea is implemented. The user starts it up. What will happen next?

 
Sergey Lebedev:
The main problem of Services is not the Terminal Handle - it's all the marginal use cases.
A more important area - building back-office trading support systems (running calculations of own GOs, risk indicators across the portfolio etc.) requires events like OnTradeTransaction etc - now there are no such account-specific events at all; it's strange and frustrating that they were forgotten to be added.
Adding these events to the Services functionality should be the first priority in the development of this kind of MT5 object, sincethe basic MT5 desktop functionality is essentially front-office, there is no back-end at all, and traders who know about trading strategies have to do the back-end by hand.
With this level of understanding, you can transfer all events to the service from the EA via resources. And now, also through the database.
 
fxsaber:

It is not clear what this looks like. Let's say the idea is implemented. The user starts it up. What happens next?

And then, you keep your own net balance and CS statistics for open positions. Including all the daily recalculations of clearing.
For example, write these statistics to the Sqlite database, and then use it for display or other calculations.
The problem of clearing recalculation in mt5 on the stock market is the first thing that came to mind.
But you can collect any available data from the exchange site, or through dedicated channels, and keep your own statistics and calculations for algo-trading.
Custom events in service would be convenient for receiving this kind of information from outside without blocking the main service cycle.

Here is a picture to understand how it looks in the terminal. (taken from an exchange branch)
The terminal does not calculate the net result of clearing recalculation, accumulated income and CS on open positions.

b

1...1516171819202122232425
New comment