Fehler, Irrtümer, Fragen - Seite 2938
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
Ja, ich erinnere mich genau: Ich habe bei OnInit versucht, einen falschen Verlauf vorzuladen. Es funktionierte weder dort noch in OnCalculate, nicht einmal in einer Schleife mit hundert Wiederholungen. Ich weiß nicht, wie es tatsächlich funktioniert, aber äußerlich wurde die versprochene Geschichte nicht geladen (wenn auch mit einer Verzögerung), das Ergebnis blieb bis zum Ende unbefriedigend.
Außerdem gab es andere Fälle, in denen die Antwort wiederholt zurückgegeben wurde:
aber am Ende gab es keine Fortsetzung des Indikators, es herrschte Schweigen in der Antwort.
Es besteht keine Notwendigkeit, Zyklen mit Wiederholungen durchzuführen.
Wenn es sich um einen Indikator handelt, stellen Sie in OnCalculate eine einzige Anfrage für die richtige Symbol-Periode. Wenn es fehlschlägt, dann return(0)
Nehmen Sie die Empfangszeit des Ticks des gewünschten Symbols, normalisieren Sie diese Zeit auf den Beginn der gewünschten Periode, fragen Sie 1 letzten Balken der gewünschten Symbol-Periode ab und überprüfen Sie dessen Zeit. Erkundigen Sie sich dann nach dem Zeitstatus der Geschichte
Je nach Trägheit Ihres Computers und Ressourcenbelastung können mehr als hundert OnCalculate durchlaufen.
Der Code, auf den Sie sich beziehen, ist sehr alt. Aber es ist gut zur Veranschaulichung. Es ist jedoch nicht für Indikatoren geeignet, da die Historienabfragen von Indikatoren ohne Wartezeit durchgeführt werden (was in der Dokumentation klar beschrieben ist) und der Schlaf in Indikatoren nutzlos ist.
Der Server gibt den Verlauf auch an Wochenenden wieder.
Steuern Sie den Aufbau der Balken nach dem Zeitpunkt des letzten Tickens des entsprechenden Symbols
Wenn es sich um einen Indikator handelt, führen Sie eine einmalige Abfrage des erforderlichen Zeichenzeitraums in OnCalculate durch. Wenn fehlgeschlagen, dann return(0)
Nun, return(false) im Falle eines Fehlers ist ein Klassiker. Also tue ich es. Alles wäre in Ordnung, aber das Problem ist, dass meine weiteren Berechnungen an das erfolgreiche Laden der Geschichte gebunden sind (und diese Logik kann nicht geändert werden), und im Falle eines Fehlers und der Rückkehr aus der Berechnungsfunktion, werden sie einfach nicht passieren und weitere grafische Konstruktionen erhalten nicht die benötigten Koordinaten, alles stürzt ab. Wie man dies vermeiden kann - habe noch nicht daran gedacht und erwarte auch nicht, etwas zu ändern. Bisher habe ich folgendes: Entweder wird die gesamte Historie geladen und alle Zeitreihen für alle Zeitrahmen werden erstellt, und der Indikator funktioniert fast sofort, ohne dass Berechnungen aufgrund von return(false) fehlen, oder ein Teil der Historie fehlt, und der Codekehrt zu einer übergeordneten Funktion mitreturn zurück und versucht, die fehlende Historie in einer Endlosschleife anzufordern, was zu nichts führt. Die dritte Variante - ohne Rückgabe - habe ich einfach abgelehnt, und einige Berechnungen scheitern, was das Zeichnen von Grafiken unvollständig macht.
Ich sitze noch ein bisschen im Tank und bin immer noch perplex... Ist es realistisch, die MQL-Logik des Indikators so zu organisieren, dass sie nur mit der lokalen Historie arbeitet , ohne dass die fehlende Historie heruntergeladen werden muss und dadurch Verzögerungen entstehen? Oder irgendwelche Funktionen von Copy... ... zwangsläufig den Server kontaktieren müssen, um auch nur diesen Teil des Verlaufs herunterzuladen, den ich für die Bearbeitung nicht benötige? Einfach gesagt, sind die Standard-Indikatoren sofort auf die bestehende Geschichte auf meinem PC gezeichnet, ohne Herunterladen (ich suchte Indikatoren in den Ordner Beispiele und dort sie nur CopyBuffer() verwenden, und nicht in allen von ihnen) ... Oder ist die Wiederaufnahme vor den Augen verborgen? Was ist der Zweck der Wiederaufnahme?
Ich danke Ihnen. Ich werde über Ihre Empfehlungen nachdenken - wahrscheinlich werden sie für mich nützlich sein.
Ich war ein paar Stunden lang nicht am Computer. Während dieser Zeit trat eine abnormale Situation auf, und der Roboter begann, eine Menge Drucke zu nähen. Infolgedessen ist die Scheibe vollständig verstopft. Dies stört die Arbeit der Terminals, da sie ihren Preisverlauf nicht auf der Festplatte ablegen können.
Wir müssen ein solches Verstopfen der Festplatte verhindern. Eine der Alternativen besteht darin, das Schreiben in den Ordner zu deaktivieren. D.h. immer ohne Logs auf der Festplatte zu leben. Eine andere Möglichkeit besteht darin, Protokolldateien zu löschen, wenn nicht mehr genügend freier Speicherplatz vorhanden ist.
Hat jemand dieses Problem gelöst.
Wenn es sich um einen Indikator handelt, führen Sie eine einmalige Abfrage des erforderlichen Zeichenzeitraums in OnCalculate durch. Wenn es fehlschlägt, dann return(0)
Und wenn Sie am Wochenende einen Blinker setzen wollen?
Nur erzwungener Aufruf von OnCalculate vom Timer aus (mit allen sich daraus ergebenden Krücken in Form von Kopieren von Arrays zur Übergabe per Referenz)?
Ist es realistisch, die MQL-Logik des Indikators so zu organisieren, dass sie nur mit der lokalen Historie arbeitet , ohne dass die fehlende Historie heruntergeladen und die damit verbundenen Verzögerungen in Kauf genommen werden müssen? Oder irgendwelche Funktionen von Copy... ... zwangsläufig auf den Server zugreifen müssen, um auch nur diesen Teil des Verlaufs herunterzuladen, den ich für die Bearbeitung nicht benötige?
Sie können Ihren eigenen Cache erstellen(in Dateien schreiben).
Als mir das vorgeschlagen wurde, habe ich natürlich die Schläfe verdreht, aber es ist wirklich besser, als darauf zu warten, dass MQ seinen Ansatz zur Handhabung von Zeitreihen ändert.
Ich war ein paar Stunden lang nicht am Computer. Während dieser Zeit trat eine abnormale Situation auf, und der Roboter begann, eine Menge Drucke zu nähen. Infolgedessen ist die Scheibe vollständig verstopft. Dies stört die Arbeit der Terminals, da sie ihren Preisverlauf nicht auf der Festplatte ablegen können.
Wir müssen ein solches Verstopfen der Festplatte verhindern. Eine der Alternativen besteht darin, das Schreiben in den Ordner zu verbieten. D.h. immer ohne Logs auf der Festplatte zu leben. Eine andere Möglichkeit besteht darin, Protokolldateien zu löschen, wenn nicht mehr genügend freier Speicherplatz vorhanden ist.
Hat jemand dieses Problem gelöst?
Interessehalber stürzte ich hinüber, um es zu überprüfen, und mir fiel die Kinnlade herunter: 183 GB! Das sind fast 4/5 meiner SSD. Bilder von virtuellen Maschinen brauchen weniger Zeit. Wenigstens werde ich im Alter etwas zu lesen haben...
Nur so zum Spaß bin ich rübergeeilt, um mein Haus zu überprüfen, und mir ist die Kinnlade runtergefallen: 183GB! Das sind fast 4/5 meiner SSD. Bilder von virtuellen Maschinen benötigen weniger Zeit. Wenigstens habe ich auf meine alten Tage etwas zu lesen...
Drucken und Warnen sind potenziell gefährliche Funktionen.
Price=0.7235200000000001Warum sollte sie das tun? Handelt es sich dabei um einen Fehler, oder sollten wir die Ausgabe auf einheitliche Weise anpassen? Nun, sagen wir, ich werde es mit PrintFormat oder fprint kämmen, aber im Prinzip ist es keine falsche Darstellung der Zahl?