My approach. The core is the engine. - page 160

 

And so:

There are 1000 cells in a table. The EA sends the values of a thousand cells to the engine at the same time. The CPU load at maximum speed increases by up to 50%. At the same time, the speed is naturally decreasing with..

However, for 1000 cells, the speed is quite decent.

(Click)

Zy. It slows down a bit when recording. In general, it's faster.
 
So, now there won't be any problems with glass traffic (as some respected people said:)). A glass of 100 - 200 cells will be spinning like mad).
 

Here is the engine and the advisor. Put it on different charts.

Order:

1. Put the engine on one chart.

2. Put the Expert Advisor on the second chart.

3. Return to the chart of the engine and press the big blue button with the picture of mountains at the bottom left.

Files:
EA_DRIVE.ex4  2999 kb
 

The great thing is that the values of 1,000s of parameters change in the kernel, whether the table window is open or not. If you close the table, the parameters are still updated. And when the window is closed, there is no load, although the life of the parameters continues.

The only thing which gives load, is redrawing of big amount of elements.

Try to close the table and see how the load on the processor disappears, although communication and transmission of giant string messages does not stop. While one window is closed, you can open another. In this way, you can regulate the load. Close the windows of large tables with rapidly changing data. Or reduce the rendering speed with a slider.

Although common tables are rarely of this size, and with constantly changing values in the cells. This is designed for extraordinary cases.

 
Реter Konow:

The great thing is that the values of 1,000s of parameters change in the kernel, whether the table window is open or not. If you close the table, the parameters are still updated. And when the window is closed, there is no load, although the life of the parameters continues.

The only thing which gives load, is redrawing of big amount of elements.

Try to close the table and see how the load on the processor disappears, although communication and transmission of giant string messages does not stop. While one window is closed, you can open another. In this way, you can regulate the load. Close the windows of large tables with rapidly changing data. Or reduce the rendering speed with a slider.

Although common tables are rarely of this size, and with constantly changing values in the cells. This is designed for extraordinary cases.

Which window is the table window?

Retug Konow2019.01.29 20:34 RU

Here is the engine and the EA. Put it on different charts.

Order:

1. Throw the engine on one chart.

2. Put the Expert Advisor on the second chart.

3. Return to the chart of the engine and press the big blue button with the picture of mountains at the bottom left.

 

Anyway, I'm publishing my builder and engine in February. With bugs or unfinished, it doesn't matter, it will still be in the MT5 Marketplace for free for everyone. It's time.

This area is unfathomable for one person, and the urge to be completely finished is forcing me to put off releasing it. But the time has come.

About developing the C# direction, - I'm against it. And not because it will hurt me. I'll adapt and maybe even benefit from it. But it may harm many users of MT5. MQ has no DLL control. Under the guise of cool EAs they may start spreading malware to bypass Market. And worst of all, it will be associated with the MT5 brand. That is, it will damage the reputation and sow discontent directed against the platform by those affected. In general, in addition to the plus side, will put a fat minus. After all, if the platform supports something that can do harm, there will be reasons to blame it, even though it is not formally responsible.

I think this is a bad direction, and better not to develop it...

 
Алексей Тарабанов:

Which window is the table window?

On the engine graph, in the taskbar on the left, click on the blue button. The table window will appear.

 
By the way, I believe that on MT5 the table will work 10 times faster, and no C# is needed)).
 
Реter Konow:

As for developing the C# direction, I am against it. And not because it will harm me. I will adapt and maybe even benefit from it. But it may harm many users of MT5. MQ has no DLL control. Under the guise of cool EAs they may start spreading malware to bypass Market. And worst of all, it will be associated with the MT5 brand. That is, it will damage the reputation and sow discontent directed against the platform by those affected. In general, in addition to the plus side, will put a fat minus. After all, if the platform supports something that can do harm, there will be reasons to blame it, even though it is not formally responsible.

I think it's a bad direction, and better not to develop it...

why hasn't this been written about before?

ZS: ))))))

 
Igor Makanu:

Why hasn't this been written about before?

ZS: ))))))

Previously, no one had seriously developed this field. And now all of a sudden they're doing it. And why? Because I created the GUI constructor for people, not for myself. And I want to distribute it freely. Of course, it is worse than C#, but it is safe and good for the Market. And it is constantly being developed. So what is the sense in it? (Do you want to spite me?)).

By the way, I've always said that I will suggest the structural design only for MT5. I have a testing ground on MT4. And it is justified from the development point of view. Makes me improve, look for better solutions...

Reason: