Entwickler! Testen Sie überhaupt, was Sie schaffen? - Seite 5
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
Bitte beantworten Sie 2 einfache Fragen:
1. Wenn der Handel abgeschlossen ist, sollte ich TRADE_TRANSACTION_DEAL_ADD --> ORDER_STATE_STARTED erhalten oder nicht?
2. Nach der Meldung, dass der Auftrag geändert wurde TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFY
Sollte ich die Meldung TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED erhalten oder nicht?
Die Frage ist zwar nicht an mich gerichtet, aber ich werde versuchen, sie zu beantworten :)
Die Arbeit mit Ereignissen bedeutet, dass erwartete Ereignisse möglicherweise nicht eintreten, z. B. können Sie sich im Transit verirren oder nicht in der Warteschlange warten, und es können nur sehr wenige Dinge passieren (einschließlich eines Fehlers im Terminal). Sie müssen also Ihr Ereignismodell sichern, damit es zuverlässig funktioniert. Ich baue zum Beispiel eine Warteliste für besonders wichtige Ereignisse auf und kontrolliere sie nicht nur durch verwandte Ereignisse, sondern auch durch indirekte Bestätigung, dass das erwartete Ereignis eingetreten ist.
Artem, ich will dich nicht beim Wort nehmen, aber es ist kein
ein bewusster Schritt Ihrerseits. Tatsache ist, dass die derzeitigen Bugs nicht
wird Ihnen nicht erlauben, einen EA nach meinem TOR zu schreiben.
Im Moment arbeitet mein Expert Advisor und bringt einen Gewinn von 1% pro Tag.
Ich wollte es gründlich aktualisieren, aber aufgrund von Fehlern in
MT-5-Fehler funktionieren nicht.
Und zweitens, wie hoch ist die Upfront-Gebühr, wenn wir auf Ihrem Konto mit 5000 Euro Depot testen?
Ich stelle immer meine vorläufigen Bedingungen. Nachdem ich meinen vorläufigen Bedingungen zugestimmt habe, lese ich die TOR, dann sage ich - es wird weniger kosten / wird mehr kosten / nicht realistisch. Nach der Einigung besprechen wir die ToR bis ins kleinste Detail. Und erst nach vollständigem gegenseitigem Verständnis bestätigen wir unsere Bereitschaft zur Zusammenarbeit. Während der Arbeit eng mit dem Kunden zusammenarbeiten. Immer in Kontakt. Wir setzen die Diskussionen und Klärungen zu jedem einzelnen "Rädchen" des Algorithmus fort. Solange das nächste "Rädchen" nicht geschliffen und getestet ist, werden wir nicht zum nächsten übergehen. Bevor ich die endgültige Lösung weitergebe, teste ich den Algorithmus selbst auf Fehler, aber nur im Tester und nur auf die Korrektheit des Algorithmus. Testen auf Rechnung - nur für Bugs und nur durch den Kunden, und nur auf seine Kosten.
Ich verstehe, dass dies ein Gespräch über nichts ist. Bringen wir es hinter uns.
P/S Welche Hochsprache sprechen Sie?
Haben wir bereits einen "Pissing Contest" begonnen?
Die Antwort lautet: Schimpfwörter.
Guten Tag, Juri!
Ja, natürlich haben Sie recht, ein Ereignis kann nicht nur einmal, sondern auch zweimal oder sogar dreimal eintreten.
Aber sie kommen, aber ANDERE!
Können Sie mir bitte sagen, wie Sie kontrollieren können, dass die Bestellung geändert wurde (ohne Antwort des Servers)?
Haben wir bereits einen "Pissing Contest" begonnen?
Ich antworte - mit einem Schimpfwort.
Artyom, du hast ein verdrehtes Verständnis von Fragen!
Ich dachte einfach, dass es möglich ist, Ihnen anzubieten, zu schreiben (anstelle des Beraters)
Ich dachte nur, ich könnte Ihnen anbieten, ein kleines Terminal für Plaza II zu schreiben (anstelle des Beraters), es wird schwierig sein...
Artyom, du hast ein verdrehtes Verständnis von den Fragen!
Ich dachte gerade, dass es möglich ist, Ihnen anzubieten, zu schreiben (anstelle des Beraters)
Ich dachte nur, ich könnte Ihnen anbieten, ein kleines Terminal für Plaza II zu schreiben (anstelle des Beraters), es wäre schwer, es allein zu tun...
Ich bitte um Entschuldigung. Ich habe Sie falsch verstanden. Die Müdigkeit macht mir zu schaffen - ich arbeite an einem komplizierten Auftrag, ich schlafe nicht viel....
Vielen Dank für das Angebot. Meine Pläne sind ein wenig anders. Ich glaube, ich verzichte.
Die Frage ist zwar nicht an mich gerichtet, aber ich werde versuchen, sie zu beantworten :)
Die Arbeit mit Ereignissen bedeutet, dass die erwarteten Ereignisse möglicherweise nicht eintreten, z. B. auf dem Weg verloren gehen, oder die Warteschlange nicht warten kann, und nur sehr wenige Dinge können passieren (einschließlich eines Terminalfehlers). Sie müssen also Ihr Ereignismodell sichern, damit es zuverlässig funktioniert. Ich erstelle zum Beispiel für sehr wichtige Ereignisse eine Warteliste und kontrolliere sie nicht nur durch verwandte Ereignisse, sondern auch durch indirekte Bestätigung, dass das erwartete Ereignis eingetreten ist.
Nein, das funktioniert nicht. Das Ereignismodell muss absolut zuverlässig sein. Wenn das Ereignis nicht ankommt, hat es nicht stattgefunden. Bei FORTS sollten die Ereignisse besonders deutlich ausgeführt werden, da Orderänderungen Dutzende von Abschlüssen erzeugen können.
Ich danke Ihnen auch, aber ich denke, ich werde
"zur Plaza II.
Ich empfehle das nicht. Es ist viel einfacher, diesen Fehler mit MQ zu beheben, als selbst ein neues Terminal für Plaza zu bauen. Sie verzetteln sich in endlosen Fehlerkorrekturen und schreiben die "Standardfunktionalität". Ich spreche aus meiner eigenen Erfahrung. Ich habe teilweise einen solchen selbstgebauten Komplex auf der Grundlage von Stock# entwickelt - das Ergebnis ist ein weiteres "Fahrrad" für bestimmte Aufgaben. Kämpfen Sie lieber mit dem Support-Service, das ist einfacher und billiger.
Guten Tag, Juri!
Ja, natürlich haben Sie recht, ein Ereignis kann nicht nur einmal, sondern auch zweimal oder sogar dreimal eintreten.
Aber sie kommen, aber ANDERE Zeiten!
Doch diese ein, zwei oder drei Male können zu einem äußerst ungünstigen Zeitpunkt kommen, und genau das ist Ihnen passiert. In der Hilfe wird dies übrigens ausführlich behandelt. Die Entwickler empfehlen nicht,Ihren Handelsalgorithmus darauf aufzubauen, dass Sie darauf warten, dass einige Handelstransaktionen nach anderen eintreffen.
Ein Handelsauftrag, der manuell vom Terminal oder über die OrderSend()/OrderSendAsync()-Funktionen gesendet wird, kann mehrere aufeinanderfolgende Transaktionen auf dem Handelsserver erzeugen. Die Reihenfolge, in der diese Transaktionen im Terminal ankommen, ist nicht garantiert, so dass wir unseren Handelsalgorithmus nicht darauf aufbauen können, dass wir auf das Eintreffen einiger Transaktionen nach anderen warten. Außerdem können Transaktionen bei der Übermittlung vom Server zum Terminal verloren gehen.
//---
Könnten Sie mir bitte sagen, wie Sie kontrollieren können, ob eine Bestellung geändert wird (ohne Antwort des Servers)?
Vergleichen Sie zum Beispiel die vorherigen Werte mit den aktuellen Werten.
Nein, das funktioniert nicht. Das Ereignismodell muss absolut zuverlässig sein. Wenn das Ereignis nicht ankommt, dann hat es auch nicht stattgefunden. Bei FORTS müssen die Ereignisse besonders genau ausgeführt werden, da Auftragsänderungen Dutzende von Geschäften auslösen können.
Das ereignisgesteuerte Modell kann per definitionem nicht absolut zuverlässig sein: Wenn das Ereignis nicht eingetroffen ist, heißt das nicht, dass es nicht stattgefunden hat.
tol64!
Ja, es spielt keine Rolle, wie sie kommen (obwohl es nicht logisch ist, dass das Ereignis "Bestellung aufgegeben" zuerst kommt, gefolgt von "Bestellung im Änderungszustand")
Nicht richtig?
Wenn Sie sich mein Bild genau ansehen, werden Sie sehen, dass die Meldung "Auftrag teilweise ausgeführt" kam (es sind zwei in einer Reihe), anstatt "Auftrag erteilt"!
P/S Und es ist nicht nötig, "den Text herauszureißen" und den ganzen Satz, der so beginnt:
Wenn Sie die Art des Handels kennen, können Sie den aktuellen Status der Aufträge, Positionen und Geschäfte auf Ihrem Handelskonto analysieren.