FORTS. Fragen der Durchsetzung - Seite 87
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
Jetzt macht es Sinn!
Bei der asynchronen Variante wird nur eine Zeile geschrieben
Diesem entspricht.
Und es gibt KEINE weitere Zeile im Logbuch! Es würde also zu diesem hier passen.
Das Protokoll ist bei asynchroner Verarbeitung natürlich nicht vollständig.
Bei synchroner Verarbeitung gibt es jedoch zwei Zeilen im Protokoll
2017.02.17 16:20:47.323 Trades '1007932': order #54042531 sell limit 1.00 / 1.00 RTS-3.17 at 121520 done in 15.978 ms
Aus diesem Grund wurden der synchrone und der asynchrone Modus in der gleichen Zeit ausgeführt (was logischerweise angenommen wird), und das Terminalprotokoll meldet, dass der asynchrone Modus doppelt so schnell ist. Dies ist eine Lüge/ein Irrtum!
Wir können daraus schließen.
Im asynchronen Modus ist das Protokoll nicht vollständig und führt in die Irre.
Die Schlussfolgerung kann gezogen werden.
Im asynchronen Modus ist das Protokoll nicht vollständig und führt in die Irre.
Ja, aber das löst leider nicht das Latenzproblem....
In SD schrieb vor langer Zeit.
Ich bin auch optimistisch :)
Ich habe vor langer Zeit an die SR geschrieben
Auf meine Bewerbungen wird sehr schnell reagiert. Vielleicht ist die Sprache, die ich verwende, für Entwickler verständlicher als Ihre.
Es fällt mir manchmal schwer zu verstehen, was Sie meinen.
Aber manchmal funktioniert FOK nicht, schreibt Fehler 4756.
Ich benutze SB, insbesondere für den Einkauf:
1.0, // объем позиции
текущий аск, // цена исполнения
NULL, // символ
0.0, // цена Stop Loss
0.0, // цена Take Profit
ORDER_TIME_DAY, // тип истечения
0, // время истечения
"" // комментарий
)
Kolleginnen und Kollegen, bitte beraten Sie sich zu diesem Punkt. Ich habe bei FORTS immer die Richtlinie ORDER_FILLING_RETURN verwendet, und jetzt habe ich die Aufgabe, ORDER_FILLING_FOK zu testen.
Aber manchmal funktioniert FOK nicht, schreibt Fehler 4756.
Ich benutze SB, insbesondere für den Einkauf:
1.0, // объем позиции
текущий аск, // цена исполнения
NULL, // символ
0.0, // цена Stop Loss
0.0, // цена Take Profit
ORDER_TIME_DAY, // тип истечения
0, // время истечения
"" // комментарий
)
4756
Handelsanfrage konnte nicht gesendet werden
Das hat nichts mit der Auftragsabwicklung zu tun.
Verfolgen Sie die SB, vielleicht sehen Sie dann, wo der Fehler auftritt.
4756
Handelsanfrage konnte nicht gesendet werden
Das hat nichts mit der Auftragsabwicklung zu tun.
Traceroute SB, sehen Sie, ob Sie sehen können, wo der Fehler auftritt.
Hier ist ein Auszug aus dem Bestell- und Transaktionsverlauf:
Prüfen Sie, ob der Broker das FOK-Gießen unterstützt
int filling_mode = int(SymbolInfoInteger(a_symbol, SYMBOL_FILLING_MODE));
if((SYMBOL_FILLING_IOC & filling_mode) != SYMBOL_FILLING_IOC)
{
MessageBox("Символ " + a_symbol + " не поддерживает filling IOC режим исполнения ордеров!", "Ошибка", MB_OK | MB_ICONHAND);
return(false);
}
if((SYMBOL_FILLING_FOK & filling_mode) != SYMBOL_FILLING_FOK)
{
MessageBox("Символ " + a_symbol + " не поддерживает filling FOK режим исполнения ордеров!", "Ошибка", MB_OK | MB_ICONHAND);
return(false);
}
Hinzugefügt
Und schauen Sie in SB Funktion bool CTrade::FillingCheck(const string symbol)
Hier ist ein Auszug aus der Bestell- und Transaktionshistorie:
Kann ein Begrenzer FOK sein?
Im Forum wurde eine Funktion zur automatischen Auswahl des Fülltyps vorgestellt.