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
Die Lösung ist einfach: Wir führen eine weitere Prüfung ein, um die Historie zu ändern, so dass nichts verloren geht und es zu 100% funktioniert.
Dies kann sogar als unvollständiges OnTrade() verwendet werden
Ich bin wohl nicht schlau genug.)
Wie wende ich das an?
Es gibt nur ein Problem, und das ist extrem selten. Ich habe es heute zum ersten Mal seit ein paar Jahren gefunden, vielleicht war es schon vorher da, ich habe es nur nicht bemerkt.
Ich habe über die Berechnung der Hash-Summe gesprochen - wie man einen Zeichennamen zum Hash-Summenwert hinzufügen kann - und wie man die Werte der Buchstabencodes berechnet, aus denen der Zeichenname besteht.
Das ist es, die Lösung ist einfach: Führen Sie eine weitere Änderungsprüfung der Historie ein, dann geht nichts verloren und es funktioniert zu 100%.
Hier ist ein Auszug aus meinem Artikel #3:
-------
Konzentrieren wir uns mehr auf den Hash-Betrag als Teil der Struktur.
Nehmen wir ein Ticket. Das Hinzufügen/Entfernen eines schwebenden Auftrags ändert die Gesamtmenge der Ticks auf dem Konto, das Auslösen eines schwebenden Auftrags ändert die Gesamtmenge der Ticks auf dem Konto nicht.Es reicht nicht aus, die Anzahl der Aufträge und Positionen zu kennen, um genau feststellen zu können, was sich auf dem Konto geändert hat - kann ein ausstehender Auftrag gelöscht werden, und in diesem Fall ändert sich die Gesamtzahl der Aufträge und Positionen auf dem Konto. Aber... Ein schwebender Auftrag kann ausgelöst und zu einer Position werden. In diesem Fall würde sich der Gesamtbetrag der Aufträge und Positionen nicht ändern (für Hedge-Konten und MQL4) - die Anzahl der Positionen hat sich erhöht, aber die Anzahl der Aufträge hat sich verringert, so dass der Gesamtbetrag immer noch der gleiche ist. Das funktioniert bei uns nicht.
Betrachten wir das Gesamtvolumen. Sie haben einen schwebenden Auftrag erteilt oder gelöscht - Gesamtbetrag auf dem Konto hat sich geändert; wir haben ihn eröffnet oder geschlossen oder die Position geändert - Gesamtbetrag auf dem Konto hat sich geändert. Es scheint geeignet zu sein, aber auch hier gilt, dass die Aktivierung eines schwebenden Auftrags das Gesamtvolumen nicht verändert.
Betrachten wir also eine weitere Positionseigenschaft - Zeit ihrer Veränderung in Millisekunden: Das Eröffnen einer neuen Position verändert die gesamte Positionsveränderungszeit, das teilweise Schließen verändert die Positionsveränderungszeit, das Hinzufügen von Volumen zu einem Netting-Konto verändert die gesamte Positionsveränderungszeit.Welche dieser Methoden ist geeignet, um den genauen Ort der Änderungen auf dem Konto zu bestimmen? Ticket + Zeitpunkt der Positionsänderung. Schauen wir nach:
In diesem Fall habe ich jedoch kein Symbol zur Hash-Summe hinzugefügt - dafür gab es keine Präzedenzfälle. Aber ich habe es funktioniert in Verbindung mit der Überprüfung Geschichte. Daher sollte es ohne Fehler funktionieren. Ich werde es aber bei Gelegenheit überprüfen.
Die Lösung ist einfach: Führen Sie eine weitere Prüfung der Verlaufsänderungen ein, dann geht nichts verloren und es funktioniert zu 100 %.
Und ja, das wird sie. Wenn sich die Anzahl der offenen Aufträge nicht ändert, ändert sich auch die Anzahl in der Historie. (Ich kümmere mich nicht um ausstehende Bestellungen - ich benutze sie nicht) Und wir müssen nicht den ganzen Tag durchgehen, um nur ein Ereignis zu erfassen.
Und wenn der Benutzer eine Textnachricht erhalten hat und sich dafür entschieden hat, nur die Historie des letzten Monats im Terminal anzuzeigen, wird eine zusätzliche Prüfung durchgeführt, bei der alle Bestellungen ausprobiert werden, was nicht fatal ist.
Das scheint eine gute Lösung zu sein. Und zwar ohne Bezug auf etwas anderes als das, was wir haben, nämlich ein Handelskonto und ein Terminal.
Hier ist ein Auszug aus meinem Artikel #3:
-------
Gehen wir näher auf den Hash-Betrag als Teil der Struktur ein.
Ziehen Sie ein Ticket in Betracht. Das Hinzufügen/Entfernen eines schwebenden Auftrags ändert die Gesamtzahl der Tickets im Konto, das Auslösen eines schwebenden Auftrags ändert nicht die Gesamtzahl der Tickets im Konto.Es reicht nicht aus, die Anzahl der Aufträge und Positionen zu kennen, die sich auf dem Konto geändert haben, um diese Änderung genau bestimmen zu können - kann ein ausstehender Auftrag gelöscht werden, und in diesem Fall ändert sich die Gesamtanzahl der Aufträge und Positionen auf dem Konto. Aber... Ein schwebender Auftrag kann ausgelöst und zu einer Position werden. In diesem Fall ändert sich der Gesamtbetrag der Aufträge und Positionen nicht (für Hedge-Konten und MQL4) - die Anzahl der Positionen hat sich erhöht, aber die Anzahl der Aufträge hat sich verringert, so dass der Gesamtbetrag immer noch der gleiche ist. Das funktioniert bei uns nicht.
Betrachten Sie das Gesamtvolumen. Sie haben einen schwebenden Auftrag erteilt oder gelöscht - Gesamtvolumen des Kontos geändert, eröffnet, geschlossen oder Position geändert - Gesamtvolumen des Kontos geändert. Es scheint geeignet zu sein, aber auch hier gilt, dass die Aktivierung eines schwebenden Auftrags das Gesamtvolumen nicht verändert.
Schauen wir uns also eine weitere Positionseigenschaft an - Zeit ihrer Änderung in Millisekunden: Das Eröffnen einer neuen Position ändert die gesamte Positionsänderungszeit, das teilweise Schließen ändert die Positionsänderungszeit, das Hinzufügen von Volumen zu einem Netting-Konto ändert die gesamte Positionsänderungszeit.Welche dieser Methoden ist geeignet, um den genauen Ort der Änderungen auf dem Konto zu bestimmen? Ticket + Zeitpunkt der Positionsänderung. Schauen wir nach:
In diesem Fall habe ich jedoch kein Symbol zur Hash-Summe hinzugefügt - dafür gab es keine Präzedenzfälle. Aber ich habe es funktioniert in Verbindung mit der Überprüfung Geschichte. Daher sollte es ohne Fehler funktionieren. Ich werde es aber bei Gelegenheit überprüfen.
Fette Lösung, noch kein Bedarf für eine solche Variante.
Ich danke Ihnen!
Fette Entscheidung, noch kein Bedarf für diese Option.
Ich danke Ihnen!
"Kühn" deshalb, weil es nicht für eine lokale Lösung gedacht war, sondern als Teil eines vollwertigen Ersatzes für OnTradeXXXX. Es gibt noch mehr Arbeiten, die Geschichte beinhalten.
Und das ist ein großer Vorteil - wir haben fertige Daten für die Suche und Sortierung beliebiger Aufträge und Positionen im Programm (wir brauchen nicht erneut nach Aufträgen und Positionen zu suchen, um die Anforderungen des Programms zu erfüllen - alles ist bereits in den Listen enthalten). Ein weiteres Plus ist, dass das Programm weiß, welcher Auftrag die Position in MQL4 verursacht hat, was in den oben genannten Versionen nicht möglich ist.
Ich möchte wiederholen, dass die Bibliothek dazu da ist, denjenigen die Arbeit zu erleichtern, die zu viel Zeit und Geld haben, um alles selbst zu machen. Ich bestehe natürlich nicht auf irgendetwas :)
Und so ist es auch. Wenn sich die Anzahl der offenen Aufträge nicht ändert, ändert sich die Anzahl in der Historie.(Ich kümmere mich nicht um ausstehende Aufträge - ich benutze sie nicht) Und Sie müssen Ihre Großmutter nicht den ganzen Tag damit belästigen, die Aufträge durchzugehen, um nur ein Ereignis zu erfassen.
Und wenn der Benutzer eine Textnachricht erhalten hat und sich entschlossen hat, die Historie im Terminal anzuzeigen, anstatt alles nur für den letzten Monat, wird es eine zusätzliche Prüfung mit dem Ausprobieren aller Aufträge sein, was nicht fatal ist.
Das scheint eine gute Lösung zu sein. Wenn Sie ein Handelskonto und ein Terminal haben, können Sie nur das nutzen, was Sie haben, ohne an etwas gebunden zu sein.
Um nicht durch den ganzen Tag zu gehen, können Sie nur überprüfen, wenn die Bedingungen, die zu einer Änderung führen kann, Öffnen, Schließen einer Position, dh auf die Erreichung der Preise, die der Expert Advisor verwendet, um offene, TP, SL konzentrieren. Nun, das hängt von der Logik des Expert Advisors ab, Sie wissen, was billiger ist.
Um nicht den ganzen Tag durchzugehen, können Sie nur prüfen, wann die Bedingungen, die zu einer Änderung, Eröffnung oder Schließung einer Position führen können, erfüllt sind, d.h. sich auf das Erreichen der Preise konzentrieren, die der Expert Advisor für Eröffnung, TP, SL verwendet. Nun, ja, es hängt von der Logik des Expert Advisors ab, Sie wissen, was billiger ist.
Ein EA (auf einem Computer, auf einem Kontinent) handelt. Der andere (auf einem anderen Computer, auf einem anderen Kontinent) befasst sich mit seinen Funktionen. Es wurde bereits eine Lösung gefunden.
Ich wäre Ihnen dankbar, wenn Sie mir ein reproduzierbares Beispiel geben könnten (ohne den Handelsverlauf abzufragen).
Hier ist das, was herauskam (obwohl es hier nicht zum Thema gehört, aber es wurde hier angefragt).
Schnitt zum Leben. Keine MT4-Kompatibilität (natürlich), keine Fehlerbehandlung usw.
Der Handel ist primitiv, öffnet BUY, schließt auf SL/TP. Der einzige Punkt ist die Demonstration von OnTradeTransaction() im Vergleich zur "Abfrage des Servers".
Ich brauchte 2,34s gegenüber 3,06s, um die Prüfung in der vorgegebenen Zeit zu bestehen. Der Unterschied ist aufgrund der geringen Belastung der Serverfunktionen (nur eine Position, keine Prüfung auf Magie und Symbol) gering. In der realen EA wird der Unterschied viel größer sein. Die Differenz wird durch die Berechnung von Signalen und das Hinzufügen von Trailing-Stops etwas geglättet, aber sie müssen nicht bei jedem Tick durchgeführt werden. Meine ATR wird auf M1 berechnet, aber für 6 Stunden (d.h. es ist Platz, um TF zu vergrößern). Und Trailing und Breakeven werden auf H3 berechnet. Es hängt alles von der Strategie ab.
Sie sind hoffnungslos unzeitgemäß!
Diese Ereignisse sind schon seit langem garantiert!
Angenommen, in OnTradeTransaction() tritt ein Ereignis ein, nach dem eine Aktion ausgeführt werden muss, aber beim ersten Versuch, diese Aktion auszuführen, tritt ein Fehler auf. Was ist zu tun? Offensichtlich muss sie wiederholt werden, und dafür ist es notwendig, irgendwo Daten über die Notwendigkeit der Wiederholung dieser Aktion zu speichern - am ehesten werden diese Daten in den üblichen globalen Variablen von Expert Advisor oder in statischen Funktionen gespeichert. Und plötzlich musste ich das Terminal neu starten... die Daten sind weg.
Und wenn man die gegenwärtige Situation und die Geschichte analysiert, geht nichts mehr.