MetaEditor Build 1490 - Seite 6
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
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
Seit einiger Zeit wird bei der Umkehrung einer Position die Positions-ID geändert. Dies wird in der Hilfe angezeigt. Daraus ergeben sich die Ungereimtheiten.
Das ist nicht das Problem.
Der Servicedesk hat gesagt, dass sie das Problem beheben werden und dass ein Fix in der heutigen Build verfügbar sein wird.
Service Desk hat geantwortet, dass ein Fix in der heutigen Build verfügbar sein wird.
1491 - wurde nicht behoben.
Leider nein.
Im Übrigen ist überhaupt nicht klar, wie das derzeitige System der Bestandsbuchhaltung den Teil des Bestands, der den vorherigen Bestand geschlossen hat, und den verbleibenden Teil des neuen Bestands trennt (diese Trennung gibt es derzeit nicht). Es scheint, dass das Problem tiefer liegt, als es auf den ersten Blick erscheinen mag.
Leider nein.
Im Übrigen ist überhaupt nicht klar, wie das derzeitige System der Bestandsbuchhaltung den Teil des Bestands, der den vorherigen Bestand geschlossen hat, und den verbleibenden Teil des neuen Bestands trennt (diese Trennung gibt es derzeit nicht). Es scheint, dass das Problem tiefer liegt, als es auf den ersten Blick erscheinen mag.
Forum zum Thema Handel, automatisierte Handelssysteme und Strategietests
MetaEditor Build 1490
fxsaber, 2016.12.05 11:32
Ja, auch wennDEAL_ENTRY_INOUT in der Anzahl der Trades der Position enthalten ist, wird es nichts nützen, wenn Sie ENUM_DEAL_PROPERTY_* nicht erweitern.Ungefähr das gleiche
Meines Erachtens sollte die Aufzählung nicht erweitert, sondern gekürzt werden.DEAL_ENTRY_INOUT ist alsoeine unnötige Entität, die nichts bewirkt.
Hier ist ein Beispiel dafür, wie es jetzt aussieht
IN; +1.0; ID 0
IN; +0,2; ID 0
IN/OUT; -2.0; ID 1 // eine neue Position mit einer neuen ID wurde erstellt, aber es gibt keine Abschlüsse in ihr; alle Abschlüsse beziehen sich auf die vorherige Position; daher sind die Provisionen und Swaps 0.0
IN; +0.2; ID 1 // das erste Geschäft erschien in der Liste und es ist das einzige
dadurch ist ein Teil des Volumens nicht in eine neue Position verschoben worden und wird nirgends angezeigt, daher werden Swaps und Provisionen für diesen Teil des Volumens in der Positions-ID 1 nicht berücksichtigt (blaue und grüne entsprechende Listen von Geschäften)
So sehe ich das, und so sollte es logischerweise und historisch gesehen sein (welche Entscheidung MQ treffen wird, ist ungewiss):
IN; +1.0; ID 0
IN; +0,2; ID 0
OUT; -1.2; ID 0 // der Teil des Geschäftsvolumens, der auf die zu schließende Position entfällt
IN; -0.8; ID 1 // eine neue Position ist mit der neuen ID erschienen, das Geschäft ist als Rest vorhanden, das Geschäft ist in der Liste, und es ist das erste
IN; +0.2; ID 1 // das zweite Geschäft in der Liste
Daher ist die Art der Transaktion IN/Out überhaupt nicht erforderlich. Auf diese Weise wird alles korrekt berücksichtigt und die Listen der Geschäfte in den Positionen sind vollständig, wir können die Werte der Provisionen und Swaps für die entsprechenden Geschäfte adäquat ermitteln. Und wenn es notwendig sein wird, zu bestimmen, welche Geschäfte (ein Teil ging zur Schließung und der andere zur Eröffnung einer neuen Position) Teil eines Auftrages sind, wird es sehr einfach sein, dies zu tun - OUT und IN Geschäfte, die die gleiche Zeit haben (fett markiert).
Meines Erachtens sollte die Aufzählung nicht erweitert, sondern gekürzt werden.DEAL_ENTRY_INOUT ist alsoeine überflüssige Entität, die nichts bewirkt.
Eine Transaktion ist eine Ausführungseinheit, die nicht von der Plattform abhängig ist. Und ENTRY-Flaggen sind ein MQ-Unfug.
Wenn ein Geschäft auf dem Markt war, kann man es nicht als zwei Geschäfte darstellen, auch wenn es bequem wäre.
MQ hat sich bemüht, Virtualisierung hinzuzufügen - Hedge-Modus. Selbst eine einfache Virtualisierung für eine Börse ist eine schlechte Entscheidung.
Die Ausweitung der Transaktionseigenschaften bietet jedoch Bequemlichkeit ohne die potenziellen Krüppel.
Eine Transaktion ist eine Ausführungseinheit, die in keiner Weise plattformabhängig ist. Und ENTRY-Flaggen sind eine MQ-Methode.
Wenn ein Geschäft auf dem Markt war, kann man es nicht als zwei Geschäfte darstellen, auch wenn es bequem wäre.
MQ hat sich bemüht, Virtualisierung hinzuzufügen - Hedge-Modus. Selbst eine einfache Virtualisierung für eine Börse ist eine schlechte Entscheidung.
Aber die Ausweitung der Eigenschaften der Transaktion bietet Bequemlichkeit ohne potenzielle Krücken.
Nun, ich habe nur meine Meinung geäußert.
Und welche Art von Verlängerung würde den Tag retten? Sie müssen noch irgendwie bestimmen, welcher Teil der Transaktion sich auf den alten und welcher auf den neuen Bestand bezieht.
Und welche Art von Erweiterung würde die Situation retten? Es ist noch nicht ganz klar, welcher Teil der Vereinbarung auf die alte und welcher auf die neue Stelle entfällt.
1491 - Alpari-MT5-Demo. Die Screenshots zeigen denselben Ort
Terminal
Echter Tick-Tester
Die Kerzenständer stimmen nicht überein - im Tester sind sie unscharf. Außerdem unterscheiden sich die historischen Zeiten des Testers und des Terminals um eine Stunde.
CopyTicks im Terminal liefert die gleichen Daten wie im Testgerät - mit einer Stunde Unterschied. Daher stimmen die Zecken nicht vollständig mit den Balken überein.
Wie kann man also MT5, dem Tester, vertrauen, wenn er sich selbst völlig diskreditiert hat? Warum haben die Entwickler keine Benchmark-EAs, die sie im Tester laufen lassen können, um sicher zu sein, dass sie einwandfrei funktionieren? Es ist ein völliges Durcheinander.