dll and market. - page 3
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
О. I suppose it's about time and the topic starter had something to say. It's heated.
In short. We need a mechanism, I stress two-way, for exchanging information between owl on agent (local for now, but brace yourselves MQ, later users will ask for remote ones too) and owl on chart.
Horizons are comparable to... The horizons are comparable to... launching cloud and OCL and mql5 combination.
I'll give inquiring minds the opportunity to warm up even more. To the Expert a special hello and kudos to the crab for trying to invent the possibility of using plugins for experts.
Horizons - comparable to... launching the cloud and the combination of OCL and mql5.
Andrei, have you got everything ready? at what stage of implementation?
if the question is only about dll access - may be you could declare your problem in full, so Renat could feel your horizons... ...and maybe the MC will suggest a solution.
If there's only a question about dll access, maybe you could state your problem in full, so Renat could feel your horizons... and maybe MK would suggest a solution.
Come on, that's ridiculous. It will sink in the same way as it did (so far, with the OpenCL problem with services) with OpenCL.
Seems like wow, but in fact nobody needs it except for 3.5 people.
It seems to be wow, but in fact nobody needs it except 3.5 people.
So we are talking about Horizons.
If the prospect comes up (Joo will try to bring the project to the MC in bright colours), they will meet and make the necessary functionality for it.
so it's about Horizons, isn't it?
If the prospect arises (Joo will try to make the MCs aware of the project in bright colours), they will meet them and make the necessary functionality for this.
Horizons is simple there (discussed 100 times), using some kind of communication functionality to slip the clod their GA.
ZZY But the horizons of the linking functionality itself may be wider.
But the horizons of the linkage functionality itself may be wider.
That's what I'm talking about.
You say it all right. I've told about OCL that has settled in due time (and suddenly it has risen after some time) and about what has been discussed 100 times - transferring of information to agents and "narrowness of the field" in the number of optimized parameters.
Ihave been thinking about adding necessary functionality (I stress - by means of MQL5) of МТ5 and thus earning some money (why, no one has credits or mortgages), but no - no way.
This article limits the number of optimized parameters.
2. Monocriterionality of optimization (sorry for coining new words).
Inability to manage sand evaporation process.
This is not a reproach to developers, at all. On the contrary - it is a flight of fancy for MQL5 program developers! If the possibility of two-way transmission appears, the problems are solved. There will be no need to implement all three points - everything will take care of itself.
Andrei, are you all set? at what stage of implementation?
If there is only a question about access to dll - maybe you could tell us about your problem in full, so Renat could feel your horizons... ...and maybe the MC could propose a solution.
It's "ready" .... No, it's not. It always takes me a long time to ferment but hardens quickly.
Yes, it's ready. It's 95% ready.
The challenge (without going into details):
1. We need an established mechanism for two-way information exchange between the "server" on the chart and the "client" on the agent (needed first of all)
2. Need an in-house mechanism allowing to run the in-house tester/optimizer by the "server" on the chart (needed but not critical)
That's basically it.
Horizons:
1. No need to invent MQ scripting optimization control language (users asked for it some time ago)
2. cloud will start to be used for tasks not only related to trade (and this is much bigger audience than now).
3. No need to struggle with in-house GA to limit the number of opt-in parameters.
4...
You can go on without further enumerating.
О! Forgot to add. The market environment created in an in-house tester is expensive. No matter how sophisticated the home-made tester (calculator) is, it will never come close to the staff tester in terms of capabilities and quality of testing. There are many things to consider - the spread, the swap, the... And it is a mere monkey's work to correct the calculator for every task. I want to use the standard tester/optimizer.
so please add MQL server mode to pips. is this allowed? or will security be compromised too?
All dll calls are forbidden in the marketplace.
OK. How about to do the following:
1. The product itself is placed in the market.
2. The part of the code responsible for referring to the dll (win api), put it into a library and put it in codebase. The code may even be in source code.
The main point is that it is necessary to use FileMapping in the product, it is impossible without it.