My approach. The core is the engine. - page 77
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
This function can be used to automatically adjust the size of text elements.
At constructor level (the GUI generator that analyses the markup code), this is how it works. It calculates everything correctly. If any font is set in the language, the text position will be set correctly.
In the markup code, the default font was set to"Microsoft JhengHei Light" and the positions of the texts in the elements were calculated. A digital kernel was then generated and loaded into the engine as coordinates correct for the installed font.
If the user's computer does not have the font for which the calculations were made, and a different font is installed, then the text coordinate values calculated in the kernel are not correct. Because they were made for a different font.
Therefore, the text is not positioned correctly. You need to set the correct font and it will be fine.
Vasily, why write nonsense?
Is it just trolling?
There is already a space in the file name.
Fill means to prescribe calls of your functions on checkbox event.
You need to put the EA on the chart, and then the engine.
The files must be saved exactly in the folder inluded.
You do not have to put anything anywhere. This is not a trick.
Vasily has written it correctly.
Everything was correctly written by Vassily.
The misunderstanding has already been cleared up.
At constructor level (the GUI generator that analyses the markup code), this is how it works. It calculates everything correctly. If any font is set in the language, the text position is set correctly.
In the markup code, the default font was set to"Microsoft JhengHei Light" and the positions of the texts in the elements were calculated. A digital kernel was then generated and loaded into the engine as coordinates correct for the installed font.
If the user's computer does not have the font for which the calculations were made, and a different font is installed, then the text coordinate values calculated in the kernel are not correct. Because they were made for a different font.
Therefore, the text is not positioned correctly. You need to set the correct font and it will be fine.
I see.
Maybe... But it would have been different.
Maybe... But there would be others.
Perhaps, the main (maybe the only) advantage of using a separate indicator engine for implementing the EA's interface, is that the indicator runs in a different thread from the EA, and, since the interface is quite a resource-intensive task, generally, the interface implemented in this way, will not slow down the work of the EA itself, which is good.
But I don't have enough knowledge and full understanding of mechanism, how processor and co-processor resources are allocated between threads, and the concept of thread itself is not quite clear to me.
Can anyone in the know clarify these points?
-Is it reasonable to use Peter's approach for more efficient operation of the Expert Advisor due to reduced load on the EA's thread?
-Organization of the exchange between the EA's thread and the indicator-interface thread through the system of custom interruptions, how does it affect the load of the EA's thread?
Retag, get rid of files with naming problems as soon as possible, it's not a comical thing to do, especially publicly distributed ones. Spaces are a hassle in shell scripts.
Perhaps the main (maybe the only) advantage of using a separate indicator engine for implementing the EA's interface is that the indicator runs in a different thread from the EA, and since the interface is quite a resource-intensive task, the interface implemented in this way will not slow down the work of the EA itself, which is good.
But I don't have enough knowledge and full understanding of mechanism, how processor and co-processor resources are allocated between threads, and the concept of thread itself is not quite clear to me.
Can anyone in the know clarify these points?
-Is it reasonable to use Peter's approach for more efficient operation of the Expert Advisor due to the reduced load on the EA's thread?
-Organization of the exchange between the EA's thread and the indicator-interface thread through the system of custom interruptions, how does it affect the load of the EA's thread?
I do not know this question myself (surely others know better), but the indicator does not run in a separate thread from the EA. Or at least it doesn't help with the performance issue.
The scrolling in the indicator is slow. When I have connected the engine code to the EA, the scrolling is not very slow. But in the indicator it sticks.
In short, the advantage of a separate thread can be taken advantage of. But in this case we need to put it on a separate chart.
It creates a complex of tasks that can be profitable from the viewpoint of convenience (the gui can be moved between charts) and from the viewpoint of speed (a separate thread).
Retag, get rid of files with naming problems as soon as possible, it's not comical, especially publicly distributed ones. Spaces are a pain in the shel scripts.
Well, I put a dash in the name. What do you suggest?
I don't know much about it myself (others probably know better), but the indicator doesn't run in a separate thread from the EA. Or at least it doesn't help with the performance issue.
The scrolling in the indicator is slow. When I have connected the engine code to the EA, the scrolling is not very slow. But in the indicator it sticks.
In short, we have to make the engine in the Expert Advisor to take advantage of its separate thread. And for this, we need to put it on a separate chart.
This creates a set of tasks that can be profitable from the viewpoint of convenience (gui can be moved between charts) and from the viewpoint of speed (separate thread).