Mein Ansatz. Der Kern ist der Motor. - Seite 77
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Mit dieser Funktion lässt sich die Größe von Textelementen automatisch anpassen.
Auf der Ebene des Konstruktors (der GUI-Generator, der den Markup-Code analysiert) funktioniert es folgendermaßen. Es berechnet alles korrekt. Wenn eine Schriftart in der Sprache eingestellt ist, wird die Textposition korrekt eingestellt.
Im Auszeichnungscode wurde die Standardschriftart auf"Microsoft JhengHei Light" gesetzt und die Positionen der Texte in den Elementen berechnet. Anschließend wurde ein digitaler Kernel generiert und in den Motor geladen, um die Koordinaten für die installierte Schriftart zu korrigieren.
Wenn der Computer des Benutzers nicht über die Schriftart verfügt, für die die Berechnungen durchgeführt wurden, und eine andere Schriftart installiert ist, sind die im Kernel berechneten Textkoordinatenwerte nicht korrekt. Weil sie für eine andere Schriftart gemacht wurden.
Daher ist der Text nicht richtig positioniert. Sie müssen nur die richtige Schriftart einstellen, dann klappt es schon.
Wassili, warum schreibst du Unsinn?
Ist das nur Trolling?
Es gibt bereits ein Leerzeichen im Dateinamen.
Fill bedeutet, dass Sie die Aufrufe Ihrer Funktionen bei einem Checkbox-Ereignis vorschreiben.
Sie müssen den EA auf die Karte setzen, und dann den Motor.
Die Dateien müssen genau in dem Ordner Incloud gespeichert werden.
Sie müssen nirgendwo etwas ablegen. Dies ist kein Trick.
Vasily hat es richtig geschrieben.
Alles wurde von Vassily richtig geschrieben.
Das Missverständnis wurde bereits ausgeräumt.
Auf der Ebene des Konstruktors (der GUI-Generator, der den Markup-Code analysiert) funktioniert es folgendermaßen. Es berechnet alles korrekt. Wenn eine Schriftart in der Sprache eingestellt ist, wird die Textposition korrekt eingestellt.
Im Auszeichnungscode wurde die Standardschriftart auf"Microsoft JhengHei Light" gesetzt und die Positionen der Texte in den Elementen berechnet. Anschließend wurde ein digitaler Kernel generiert und in die Engine geladen, um die Koordinaten für die installierte Schriftart zu korrigieren.
Wenn der Computer des Benutzers nicht über die Schriftart verfügt, für die die Berechnungen durchgeführt wurden, und eine andere Schriftart installiert ist, sind die im Kernel berechneten Textkoordinatenwerte nicht korrekt. Weil sie für eine andere Schriftart gemacht wurden.
Daher ist der Text nicht richtig positioniert. Sie müssen nur die richtige Schriftart einstellen, dann klappt es schon.
Ich verstehe.
Vielleicht... Aber es wäre anders gewesen.
Vielleicht... Aber es gäbe noch andere.
Der Hauptvorteil (vielleicht der einzige) der Verwendung einer separaten Indikator-Engine für die Implementierung der EA-Schnittstelle ist, dass der Indikator in einem anderen Thread als der EA läuft, und da die Schnittstelle eine ziemlich ressourcenintensive Aufgabe ist, wird die auf diese Weise implementierte Schnittstelle die Arbeit des EA selbst nicht verlangsamen, was gut ist.
Aber ich habe keine ausreichenden Kenntnisse und kein vollständiges Verständnis des Mechanismus, wie Prozessor- und Co-Prozessor-Ressourcen zwischen Threads zugewiesen werden, und das Konzept des Threads selbst ist mir nicht ganz klar.
Kann jemand, der sich auskennt, diese Punkte klären?
-Ist es sinnvoll, den Ansatz von Peter für einen effizienteren Betrieb des Expert Advisors zu verwenden, da der Thread des EA weniger belastet wird?
Organisation des Austauschs zwischen dem EA-Thread und dem Indikator-Schnittstellen-Thread durch das System der benutzerdefinierten Unterbrechungen, wie wirkt es sich auf die Belastung des EA-Threads aus?
Kennzeichnen Sie Dateien mit Namensproblemen so schnell wie möglichneu, das ist nicht lustig, vor allem nicht bei öffentlich zugänglichen Dateien. Leerzeichen sind in Shell-Skripten ein Ärgernis.
Der wichtigste (vielleicht der einzige) Vorteil der Verwendung einer separaten Indikator-Engine für die Implementierung der EA-Schnittstelle ist, dass der Indikator in einem anderen Thread als der EA läuft, und da die Schnittstelle eine ziemlich ressourcenintensive Aufgabe ist, wird die auf diese Weise implementierte Schnittstelle den Betrieb des EA selbst nicht verlangsamen, was gut ist.
Aber ich habe keine ausreichenden Kenntnisse und kein vollständiges Verständnis des Mechanismus, wie Prozessor- und Co-Prozessor-Ressourcen zwischen Threads zugewiesen werden, und das Konzept des Threads selbst ist mir nicht ganz klar.
Kann jemand, der sich auskennt, diese Punkte klären?
Ist es sinnvoll, Peters Ansatz für einen effizienteren Betrieb des Expert Advisors aufgrund der geringeren Belastung des EA-Threads zu verwenden?
Organisation des Austauschs zwischen dem EA-Thread und dem Indikator-Interface-Thread durch das System der benutzerdefinierten Unterbrechungen, wie wirkt sich dies auf die Belastung des EA-Threads aus?
Ich kenne diese Frage selbst nicht (sicher wissen es andere besser), aber der Indikator läuft nicht in einem vom EA getrennten Thread. Zumindest hilft es nicht bei der Leistungsproblematik.
Der Bildlauf im Indikator ist langsam. Wenn ich den Motorcode mit dem EA verbunden habe, ist der Bildlauf nicht sehr langsam. Aber im Indikator bleibt er hängen.
Kurzum, der Vorteil eines separaten Threads kann genutzt werden. Aber in diesem Fall müssen wir sie in ein separates Diagramm einfügen.
Es wird eine Reihe von Aufgaben erstellt, die sowohl unter dem Gesichtspunkt der Bequemlichkeit (die Benutzeroberfläche kann zwischen den Diagrammen verschoben werden) als auch unter dem Gesichtspunkt der Geschwindigkeit (separater Thread) vorteilhaft sein können.
Kennzeichnen Sie Dateien mit Namensproblemenneu und beseitigen Sie sie so schnell wie möglich, das ist nicht lustig, vor allem nicht bei öffentlich zugänglichen Dateien. Leerzeichen sind ein Ärgernis in den Regal-Skripten.
Nun, ich habe einen Bindestrich in den Namen gesetzt. Was schlagen Sie vor?
Ich weiß selbst nicht viel darüber (andere wissen es wahrscheinlich besser), aber der Indikator läuft nicht in einem vom EA getrennten Thread. Zumindest hilft es nicht bei der Leistungsproblematik.
Der Bildlauf im Indikator ist langsam. Wenn ich den Motorcode mit dem EA verbunden habe, ist der Bildlauf nicht sehr langsam. Aber im Indikator bleibt er hängen.
Kurz gesagt, wir müssen die Engine im Expert Advisor so gestalten, dass sie die Vorteile ihres separaten Threads nutzen kann. Und dafür müssen wir sie in ein separates Diagramm eintragen.
Dadurch entsteht eine Reihe von Aufgaben, die sowohl aus Sicht der Bequemlichkeit (die Benutzeroberfläche kann zwischen den Diagrammen verschoben werden) als auch aus Sicht der Geschwindigkeit (separater Thread) vorteilhaft sein können.