![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
You're talking about the shared folder C:\Users\User\AppData\Roaming\MetaQuotes\Tester\.
The same principle is needed for terminal in normal mode and not with forced specification of shared folder to history bases by means of links. Now it works fine, but please implement this feature normally by specifying a folder to history bases in the terminal settings.
:-)
I've already made a request, to spread the sandbox with data files and logs over the disk system for speedy performance.
For example there is an SSD drive, one for the system, SSD for logs, SSD for quick data.
Well, it would be good if logs on one SSD , data on the other - the terminal itself where may be too on the SSD
Data access speed will increase, taking into account that each drive has its own controller.
you talk about something else - for access to a common database - to collect data from one dilling for different terminals in one folder - how many people have such a configuration?
I've just bought 12 terabytes of hard drives and forgot the problem - hard drives are so big now that it's not relevant.
No, what Andrew is suggesting is that the developers make public folder access a regular feature. That's exactly what he is suggesting, this is an appeal to you, not to millions of traders.
An explanation has been given:
The current architecture is very good, fast and secure. We wrote the fifth generation of trading platforms for a reason - we know the value of each solution.
Right. As the result, application programmers write those file managers with access blocking and fairy tale brakes because there is no other solution within the framework of MQL. But their souls are warmed by the magic "latency" and other mantras of theoretical performance, which are hard to apply in practice.
Yes - https://www.mql5.com/ru/docs/globals/globalvariablesetoncondition
The function provides atomic access to a global variable, so it can be used to organise mutex when multiple EAs are working simultaneously within the same client terminal.
And if synchronization between terminals is necessary, there are plenty of options. Even on files, but via DLL mutexes etc. That's your job now, since you're out of the security sandbox.
Without our battle for speed you would have a completely different class of software. The good stuff is not visible, it seems free and self-evident.
Yeah. As a result, application programmers write those very file managers with access blocking and huge brakes, because there is no other solution within MQL.
It all makes sense to me. If you want multiterminal capabilities, make them yourself, but it's a bit, er, irrational to do it for two and a half people.
Moreover, in the vast majority of cases, these problems can be solved in one or two.
And if we're talking about two and a half people, more people need the custom story.
Is this a challenge?
Only one gun will be loaded ? :-)
You have been told that you need to create a manager of access to data from different terminals!
And what is the problem with access of different terminals to different data! No problem, but it's convenient if all the files are in one place and there is no need to download data each time when relocating/reinstalling the terminal. But developers don't want to do this either. You don't need access manager for that.
I was talking about 2-3 terminals accessing the same data. There is no problem with this, it is enough that the terminals understand that someone is already writing and do not try to write. And when reading should be no problem at all.
You have no desire to read, understand or argue. I have no desire to throw beads behind it. I know a crutch solution (since developers do not want to make regular features) - I am satisfied with it.
And the file 2016.hcc should theoretically never be updated.
An explanation is given:
The current architecture is very good, fast and secure. We didn't write the fifth generation of trading platforms for nothing - we know the cost of each solution.
I'm well aware of that...
because I've had the privilege of developing operating systems and drivers for them.
I can't understand you at all!
Why are you turning into a fool!
It is a simple task to make files like "2017.hcc" publicly available within one broker
which, as I now understand, are updated once every "five years".
What is the problem here?
Friends, enough of the squabbling. I'm deleting the flood.