Fehler, Irrtümer, Fragen - Seite 989
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
Nein, alle Maschinen sind individuell. Sogar die Äxte sind lizenziert, von Grusha bis WS. Ich habe ein Gefühl der Schuldvermutung... Ich werde mir Ausreden einfallen lassen müssen... Mich rechtfertigen... Protokolle, dies und das...
Der Verkauf von mehr Sperrmitteln als Kernen sollte verboten werden, und das war's!
...
Und die Verwendung von mehr Sperrmitteln als Kernen sollte gesetzlich verboten werden, das ist alles!
Guten Tag. Ich habe eine Frage an die Entwickler. Der ideale Zyklus der Transaktionsgenerierung besteht aus den folgenden Schritten:
1. das Senden einer Anfrage über OrderSend(), gefolgt von der Überprüfung, ob die Methode "true" und den richtigen Retcode zurückgegeben hat.
Als Nächstes müssen Sie den Durchgang der Anfrage auf dem Server über OnTradeTransaction() verfolgen. Dieser Handler ist sehr praktisch und bietet volle Kontrolle über den Prozess.
Aber wir leben in der realen Welt, und zum Beispiel wegen eines Verbindungsfehlers oder weil eine Transaktion "bei der Zustellung verloren ging", können wir nicht auf eine Transaktion wie TRADE_TRANSACTION_REQUEST warten. Dadurch wird der Wartezyklus endlos, und es ist unmöglich festzustellen, ob die Transaktion auf Anforderung abgeschlossen wurde oder nicht.
Gibt es ein HINTERGRUND-Verfahren für den Umgang mit solchen Notfällen, das eindeutig einen logisch korrekten Prozessabschluss für jede höhere Gewalt ermöglicht? Wenn wir zum Beispiel nicht innerhalb von 20 (oder 30 oder 40) Sekunden auf TRADE_TRANSACTION_REQUEST warten, wechseln wir zu einem langsameren, aber korrekten Algorithmus, nämlich: Wir vergleichen das aktuelle Symbolvolumen mit dem Volumen vor OrderSend(), durchsuchen die Auftragshistorie und berechnen ihren Status und entscheiden, ob wir eine weitere Anfrage zur Eröffnung stellen oder das Signal überspringen. Bei der Methode OrderSendAsync() wird die Aufgabe noch komplizierter: Wir müssen ein genaues Kriterium dafür haben, wann ein bestimmter Auftrag nicht ausgelöst wurde, und wissen, wann wir dieses Kriterium anwenden müssen. Wenn ich etwas falsch verstanden habe, korrigieren Sie mich bitte.
Bei der Methode OrderSendAsync() ist die Aufgabe noch komplizierter - Sie müssen ein genaues Kriterium dafür haben, dass ein bestimmter Auftrag nicht ausgelöst wird, und wissen, wann dieses Kriterium anzuwenden ist. Wenn ich etwas falsch verstanden habe, korrigieren Sie mich bitte.
HistorySelectByPosition - theoretisch sollte es helfen, die ID wird beim Senden der Bestellung angegeben.
VanHelsing:
32x Win7-Systeme haben Probleme mit Operationen mit reellen Zahlen, unter XP funktioniert es nicht, wenn Werte an die"wininet.dll"-Bibliothek übergeben werden.
1. Machen Sie es zu einer Regel, Handelsaufträge zum aktuellen Tick zu senden und ihre Ausführung beim nächsten Tick zu überprüfen. Dann werden Sie keine Endlosschleifen haben.
2. Bei der Überprüfung der Ausführung von Aufträgen, die während des vorangegangenen Ticks erteilt wurden, brauchen Sie sich nicht mit OnTrade()/ OnTradeTransaction() zu befassen. Prüfen Sie, ob sich der Status Ihres Kontos geändert hat, d. h. arbeiten Sie mit der Quelle. Schließlich zielt jede Handelsvereinbarung darauf ab, einen Zustand Ihres Handelskontos zu verändern. Überprüfen Sie also die Veränderung des Zustands.
3. Je nach den Ergebnissen der Tests und machen weitere Logik Ihres Roboters.
Bevor Sie Funktionen wie OnTrade()/OnTradeTransaction() verwenden, sollten Sie entscheiden, was für Sie wichtiger ist:
a). die Eröffnung/Schließung/Änderung einer Position zu bestimmten Marktbedingungen zu erreichen;
b) Sie verschwenden Ihre Zeit mit der Suche nach dem Grund, warum Ihr Handelsauftrag nicht ausgeführt wurde, und suchen nach einem Schuldigen.
Dennoch habe ich ein gewisses Unverständnis festgestellt. Wenn die Ergebnisse der Überprüfung beim nächsten Tick KEINE Änderungen der Position zeigen, was ist dann zu tun? Die Gründe für das Ausbleiben von Veränderungen können ganz unterschiedlich sein. Als Alternative:
ein Auftrag auf Anfrage wurde auf dem Server erstellt, aber aus irgendeinem Grund abgelehnt,
der Server ist überlastet - die Ausführung wird verzögert,
die Verbindung wird für einige Zeit unterbrochen.
Wir möchten ein genaues Kriterium dafür haben, warum der Auftrag nicht ausgeführt wird. Die Bindung an die Zeit in einem asynchronen System scheint mir nicht sehr genau zu sein und lässt daher Unsicherheit zu. Vielleicht ist es sinnvoll, den Auftrag aus der Historie auszuwählen und seinen Status zu prüfen, oder, wie von sion vorgeschlagen, HistorySelectByPosition zu verwenden. Ich gehe davon aus, dass, wenn die Entwickler dieses System so konzipiert haben, es auch "korrekte" Methoden zur Handhabung solcher Schlüsseloperationen geben sollte.
Wir wollen ein genaues Kriterium dafür haben, dass der Auftrag nicht ausgeführt wird
Es ist Ihnen bereits erklärt worden, dass
bemühen Sie sich nicht um OnTrade()/ OnTradeTransaction().
Arbeiten Sie mit dem Quellcode.
Hallo zusammen!
Wie kann ich erreichen, dass der gesamte Inhalt der Registerkarte "Experten" beim Starten des Skripts überschrieben wird? (wie der Befehl cls), da es schwierig sein kann, zu unterscheiden, wo die Druckausgabe vom vorherigen Start des Skripts und der aktuellen endet.
Danke!!!
Hallo zusammen!
Wie kann ich erreichen, dass der gesamte Inhalt der Registerkarte "Experten" beim Starten des Skripts überschrieben wird? (wie der Befehl cls), da es schwierig sein kann, zu unterscheiden, wo die Druckausgabe vom vorherigen Start des Skripts und der aktuellen endet.
Ich danke Ihnen!!!
Fügen Sie dem Skript deinit die folgende Zeile hinzu
Print("===================== Das Ende ===================")