Making a crowdsourced project on Canvas - page 34
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
The application is separate, GUI is separate.
But the processing of data deducted in GUI is performed synchronously anyway.
For example, the application sends 10000 elements to GUI and GUI processes all these elements sequentially.
This is the problem. It is necessary to parallelize processing of incoming elements and their output in GUI. Basis, text, icon.
All the more, there are three cycles per cell.
That's right. But, in the current circumstances, paralleling processing is inconvenient. We need to connect more EAs or services. It will turn out to be a cumbersome and disconnected implementation.
There is a way based on object-charts. I haven't got into it, but it can help me create several threads. It has something to do with templates...
I get the point, the application is separate, the GUI is separate.
But processing of output data in GUI is performed synchronously anyway.
So, for example, the application sends 10000 elements to GUI and GUI processes all these elements sequentially.
This is the problem. It is necessary to parallelize processing of incoming elements and their output in GUI. Basis, text, icon.
The more so, as there are three cycles per one cell.
This is unlikely to work. Even the winda processes the interface in a single thread. Otherwise, the windows and controls will not be prioritized. Only the GUI itself and the processing of the various data can be divided into threads. De facto, even changing data in controls is not allowed from another thread. A dialog must always be coherent so any rendering and reaction of any dialog is strictly in one thread, i.e. everything happens synchronously.
All operations in MT are strictly synchronous and this cannot really be changed unless the developers add threads to the application.
It's quite surprising that developers are trying to expand MT functionality in terms of working with databases, with python, with sharpe... but they offer to do it all in the same thread...
It's just amazing.
I agree with the surprise.
The only way out is to saw a dll with asynchronous functions for your applications.
But such applications cannot even be placed in the kodobase, because the dll is not allowed.
This is unlikely to work. Even the Windows interface is handled in a single thread. Otherwise, the windows and controls will not be prioritised. Only the GUI itself and the processing of the various data can be split into threads. De facto, even changing data in controls is not allowed from a different thread. A dialog must always be coherent, so any rendering and reaction of any dialog is strictly in one thread, i.e. everything happens synchronously.
It seems to me that everything will work out, it is just necessary to think over the priority of asynchronous data processing in advance.
That is, to build a scheme of asynchronous processing, with synchronous processing.
I agree, with surprise.
The only way out is to saw a dll with asynchronous functions to your applications.
But such applications cannot even be placed in a kodobase because the dll is not allowed.
In fact, there is no real need to parallelise GUI event processing yet. If tables of 1000 cells run relatively fast even on MT4, there is more than enough speed for the rest of the events. In my practice there is no slowdown. If you need super-fast animation, you can connect OpenCL. MT5 pulls the regular GUI perfectly. No problems at all. I have just shown that one has to be very attentive with respect to canvas re-drawing.
If the Expert Advisor itself includes heavy calculations, the data output frequency in GUI can be reduced. The redrawing of a large window may reach 100 ms but it is usually much less. So, a delay of 100ms on the GUI can only be noticeable with VERY heavy EA calculations.
I agree, with surprise.
The only way out is to saw a dll with asynchronous functions for your applications.
But such applications cannot even be placed in a kodobase because the dll is forbidden.
A lot of things can be done at the DLL level.
That's all MT isn't designed for and can+must+do there :-)
You can't control the dll, that's why it's not in the marketplace. You can find dlls in kodobase, by the way. Maybe they banned it now for some reason.
PS by the way curious question - DLL can be signed with developer's key. It's possible to allow such DLL in the marketplace and kodobeise as well, but it will be tied to Microsoft infrastructure. Anyone here ready to buy such a license for Visual C?I agree, with surprise.
The only way out is to saw a dll with asynchronous functions for your applications.
But such applications cannot even be placed in kodobase because the dll is prohibited.
Yes, that's the main problem! The same market prohibits the use of dlls, so we have to reinvent the wheel. Ok, if someone thinks that GUI is not needed, but any complex long calculations in any case in one thread will not work, everything will hang! So it has to be done in a dll... which is forbidden in the marketplace...
And so on. For this reason I have to draw and solve everything with mql methods.
In fact, the separation of GUI and logic into threads is, of course, already possible. Here guys have already discussed the parallelism issue https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
As the result, the form itself could be left in the main thread, as it is done in winnda, while any additional computations could be moved to "background" execution. That's how windows and linux and android work.
You can do so many things at the DLL level.
This is what MT is not for and can+must+do :-)
You can't control the dll, that's why it's not in the market. We have dlls in kodobase, by the way. Maybe they banned it now for some reason.
PS by the way curious question - DLL can be signed with developer's key. It is possible to allow such DLLs in the marketplace and kodobeise as well, but it will be tied to Microsoft infrastructure. Anyone here ready to buy such a license for Visual C?Yes, you can't control the dll, but you could allow the same wind libraries...
Don't even go that far: even as part of a standard library there are functions to access winAPI! But what's the point? After all, you can not put it in the marketplace....
Okay, with all this talk we got into another flood.
There are many things you can do at the DLL level.
This is what MT is not intended for and can+must+be done there :-)
You can't control the dll, that's why it's not in the marketplace. And in kodobase, by the way, you can find dlls. Maybe they have banned it for some reason.
PS by the way curious question - DLL can be signed with developer's key. It's possible to allow such DLLs in the Marketplace and Kodobeise as well, but it will be tied to Microsoft infrastructure. Anyone here ready to buy such a license for Visual C?Why should you bind to Microsoft infrastructure?
I think absolutely any key can be used to sign a dll, as long as it is controlled by MQ.
It follows that these keys must be issued by MQ, and control the hash amount of the application.
Why should they bind themselves to Microsoft's infrastructure?
I think that any key can be used to sign a dll, as long as it is controlled by MQ.
It follows that these keys must be issued by MQ, and control the hash sum of the application.
but because microsoft is the boss in this anthill :-)
Why do you think people lose their login details when upgrading and activating products on pirated vin?