Benutzerdefinierte Symbole. Fehler, Bugs, Fragen, Vorschläge. - Seite 26
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
Danke, jetzt weiß ich, woran das liegt.
Hinzugefügt.Der Systemzeitschritt ist immer noch ein Vielfaches von 15,625
Aber ich habe die System-Timer-Periode der Wein-Api-Funktion timeBeginPeriod(1) geändert
d.h. der Systemtimer wird nun auf 1 Millisekunde erhöht.
Und der Systemtimerschritt sollte 1 Millisekunde betragen, richtig?
Warum friert der Zähler im Kommentar immer noch ein?
Aber die Belastung des Prozessors steigt bei acht Threads auf bis zu 40 %.
Im Allgemeinen, schloss das Thema, off topic ))
Und auf Linux unter Wine läuft der Zähler im Kommentar ohne Schluckauf, sogar mit EventSetMillisecondTimer(1);
Aber die CPU-Last steigt auf bis zu 40%, mit acht CPU-Threads.
Das ist es, wovon ich spreche...
Warum 64 Mal pro Sekunde?
Ich denke, damit man alle möglichen Informationen auf dem Bildschirm anzeigen kann. Das ist genug Frequenz. Es macht keinen Sinn, sie öfter auszustellen, und es wäre zu teuer.
Ich frage mich, obOnChartEvent, OnCalculate und OnTick auch 64 Mal pro Sekunde ausgelöst werden. - Ich glaube, ja.
Das ist es, wovon ich spreche...
Warum 64 Mal pro Sekunde?
Ich denke, damit man alle möglichen Informationen auf dem Bildschirm anzeigen kann. Das ist genug Frequenz. Es macht keinen Sinn, sie öfter auszustellen, und es wäre zu teuer.
Ich frage mich, ob OnChartEvent, OnCalculate und OnTick auch 64 Mal pro Sekunde erzeugt werden.
Der Punkt lag hier nicht in der Last, sondern in den Möglichkeiten des OnTimer()-Handlers
. Es stellte sich heraus, dass Windows diese Möglichkeiten einschränkt, während Linux dies nicht tut.
Frage, OnChartEvent, OnCalculate und OnTick werden auch nicht mehr als 64 Mal pro Sekunde erzeugt?
Wahrscheinlich ist es besser, auf eine Antwort des Entwicklers zu warten.
Zu der Frage, ob OnChartEvent, OnCalculate und OnTick auch nicht mehr als 64 Mal pro Sekunde generiert werden?
Wahrscheinlich ist es besser, auf eine Antwort des Entwicklers zu warten.
OnChartEvent mit der Mausgeprüft.
Ich habe die maximale Frequenz von 124 Hertz. Nicht mehr. Ich frage mich, warum es nicht 128 sind.
Das OnChartEvent mit der Maus überprüft.
Die maximale Frequenz beträgt 124 Hertz. Nicht mehr als das. Es ist seltsam, dass es nicht 128 sind.
Ich habe den Algorithmus ein wenig geändert. Ich habe nicht bedacht, dass ein Kommentar viel Zeit kostet. Ich habe 127 Hz.
Das ist schon logisch. Der Fehler von 1 Hz kann bereits durch das Programm selbst erklärt werden, es ist also ein bisschen von 128.
Die maximale Frequenz von OnChartEvent beträgt also 128 Hz.
Bei Programmen von Drittanbietern unterscheiden sich die benutzerdefinierten Symbole nur minimal von den Originalsymbolen. Es sollte also keine Hindernisse geben.
In der Schnittstelle des benutzerdefinierten Symbols müssen Sie negative Preise zulassen.
Wenn Sie diese Einstellung nicht angeben, wird die Historie für das erstellte Symbol nicht berechnet und das Diagramm wird nur ab dem aktuellen Zeitpunkt angezeigt.
Lange Zeit konnte ich nicht verstehen, warum der Verlauf nicht berechnet wird, da das Journal nicht die Warnung anzeigt, dass negative Preise aktiviert werden sollten.
Es wäre schön, wenn eine solche Warnung im Protokoll erscheinen würde.
Das Hinzufügen von eins-zu-eins-Ticks (insbesondere von EURUSD auf MQ Demo) zu einem leeren neuen benutzerdefinierten Symbol führt zu Fehler 5310 (nicht sofort, sondern in einer Schleife ab einem beliebigen Datum).
Was ist los? Woher weiß ich, welche Zecken genau gescholten werden? Ausgabe von Arrays in das Protokoll - keine Verletzung der Chronologie.