You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Custom events in a service would be just the right way to get this kind of information from outside without blocking the main service loop.
An example of a regular service is the formulaic custom symbol. Unfortunately, there is nothing there, except for 10Hz refresh in endless loop. Clearly, it's not right to implement feeds via EAs/indicators. Therefore only Services. And many other tasks are other types of MQL programs. For example, backoffice has to contain GUI. And Services is not supposed to have it. Perhaps we should take a stricter look at the tasks which really need to be solved by Services.
An example of a regular Service is the formulaic custom character. Unfortunately, there's nothing there except a 10Hz update in an infinite loop. Clearly, it's not right to implement feeds via EAs/indicators. Therefore only Services. And many other tasks are other types of MQL programs. For example, backoffice has to contain GUI. And Services is not supposed to have it. Perhaps we should take a stricter look at the tasks which really need to be solved by Services.
That's what Services are for, to work in an endless loop of a single thread.
For example, to receive data from outside for further processing and build analysis or the same GUI in another type of mql programs.
What to implement in the service is a matter of imagination and the necessary tasks.
The main thing is to have the technical capability.
In the announcement of one of the builds, there is information about a new type of program, "module".
It is possible that this type of program would dramatically expand its capabilities, if a separate module was to be run in its own thread, and have all of the handlers as in the Expert Advisor.
But when it will be introduced, and what its functionality will be, is not known yet.
What to implement in the service is a matter of imagination and the necessary tasks.
The main thing is to have the technical capability.
Then why do the back office need to be done through the Service?
You could run the Service, for example, to keep statistics of the registrations. But this is where an endless loop is needed.
Then why do the back office need to be done specifically through the Service?
You could run the Service, for example, to keep statistics of the registrations. But that is where the endless loop is needed.
For convenience, run and forget.
Without using a limited number of charts, to run experts.
services are unknown to the community, nor are they offered as an official tool by the developers
to understand why services are needed, you just need to analyze what they receive as events, ... nothing at all, just the factof launching a terminal, it's a kind of DOS autoexec.bat, which does not know how to run (without using crutch chips) anything
if the services are to be handled by a handler, there should be an event model, at least a timer event and not an endless loop, imho
services are unknown to the community, nor are they offered by developers as an official tool
to understand why services are needed, you just need to analyze what they receive as events, ... nothing at all, just the factof launching a terminal, it's a kind of DOS autoexec.bat, which does not know how to run (without using crutch chips) anything
if the services are to be handled by a handler, there should be an event model, at least a timer event and not an endless loop, imho
Services require everyone to invent ways of using them. That's what makes them interesting.
1. Background news loading
2-3 can be implemented through a script on OBJ_CHART.
2-3 can be implemented via a script on OBJ_CHART.
Expert/Script requires an open chart.
The number of graphs, is limited by the terminal.
Each rendering/updating of the graph, is a system message queue and an unnecessary resource load.