FORTS. Questions relatives à l'application de la loi - page 87
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Maintenant, ça a du sens !
Avec l'asynchrone, une seule ligne est écrite
correspondant à cela.
Et il n'y a PAS d'autre ligne dans le journal de bord ! Donc ça correspondrait à celui-là.
Le journal n'est évidemment pas complet avec le traitement asynchrone.
Mais avec le traitement synchrone il y a deux lignes dans le journal
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
C'est pourquoi les modes synchrone et asynchrone ont été exécutés dans un temps égal (ce qui est logiquement supposé) et le journal du terminal rapporte que le mode asynchrone est deux fois plus rapide. C'est un mensonge/erreur !
Nous pouvons conclure.
En mode asynchrone, le journal n'est pas complet et est trompeur.
On peut en tirer la conclusion.
En mode asynchrone, le journal n'est pas complet et est trompeur.
Oui, mais cela ne résout malheureusement pas le problème de latence.....
Dans SD a écrit il y a longtemps.
Je suis aussi optimiste :)
J'ai écrit au SR il y a longtemps
Mes demandes sont traitées très rapidement. Peut-être que le langage que j'utilise est plus compréhensible pour les développeurs que le vôtre.
Je trouve parfois difficile de comprendre ce que vous voulez dire.
Mais parfois FOK ne fonctionne pas, écrit l'erreur 4756.
J'utilise SB, notamment pour les achats :
1.0, // объем позиции
текущий аск, // цена исполнения
NULL, // символ
0.0, // цена Stop Loss
0.0, // цена Take Profit
ORDER_TIME_DAY, // тип истечения
0, // время истечения
"" // комментарий
)
Chers collègues, veuillez nous conseiller sur ce point. J'ai toujours utilisé la politique ORDER_FILLING_RETURN sur les FORTS et maintenant j'ai la tâche de tester ORDER_FILLING_FOK.
Mais parfois FOK ne fonctionne pas, écrit l'erreur 4756.
J'utilise SB, notamment pour les achats :
1.0, // объем позиции
текущий аск, // цена исполнения
NULL, // символ
0.0, // цена Stop Loss
0.0, // цена Take Profit
ORDER_TIME_DAY, // тип истечения
0, // время истечения
"" // комментарий
)
4756
Échec de l'envoi de la demande d'échange
Cela n'a rien à voir avec le remplissage des commandes.
Tracez le SB, vous verrez peut-être où l'erreur se produit.
4756
Échec de l'envoi de la demande d'échange
Cela n'a rien à voir avec le remplissage des commandes.
Traceroute SB, voyez si vous pouvez voir où l'erreur se produit.
Voici un extrait de l'historique des commandes et des transactions :
Vérifiez si le courtier prend en charge les versements FOK
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);
}
Ajouté
Et regardez dans la fonction SB bool CTrade::FillingCheck(const string symbol)
Voici un extrait de l'historique des commandes et des transactions :
Un limiteur peut-il être FOK ?
Sur le forum, ils ont affiché une fonction de sélection automatique du type de remplissage.