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
Il convient de le clarifier :
TRADE_RETCODE_PLACED pour OrderSend est la réponse du serveur.
TRADE_RETCODE_PLACED pour OrderSendAsync est une réponse terminale.
Bien que les codes soient identiques, ils ont une signification bien différente. Les développeurs vont très probablement corriger cette ambiguïté.
C'est pourquoi vous devez le comprendre :
doit être comprise dans le contexte approprié.
OrderSend peut recevoir une réponse à la fois du serveur et du terminal (en cas d'échec des filtres du terminal).
OrderSendAsync reçoit toujours une réponse du terminal uniquement. Pour recevoir la réponse du serveur, vous devez attraper les événements appropriés dans onTrade.
OrderSend peut recevoir une réponse à la fois du serveur et du terminal (en cas d'échec des filtres du terminal).
Est-ce que je comprends bien l'idée suivante :
Le terminal a vérifié la demande de OrderSend et l'a envoyée avec succès au serveur, le retcode recevant une valeur intermédiaire de TRADE_RETCODE_PLACED. À ce stade, la connexion est interrompue et tout ce que OrderSend peut renvoyer est le code TRADE_RETCODE_PLACED coincé dans le champ retcode ? S'agit-il de l'exemple où OrderSend renvoie TRADE_RETCODE_PLACED ?
Est-ce que j'ai bien compris l'idée suivante :
Le terminal a vérifié la demande de OrderSend et l'a envoyée avec succès au serveur, le retcode recevant la valeur intermédiaire TRADE_RETCODE_PLACED. À ce stade, la connexion est interrompue et tout ce que OrderSend peut renvoyer est le code TRADE_RETCODE_PLACED coincé dans le champ retcode ? S'agira-t-il de cet exemple où OrderSend renvoie TRADE_RETCODE_PLACED ?
Peut-être, mais j'en doute. Le plus probable serait TRADE_RETCODE_TIMEOUT via TimeOut-time pour une telle rupture de communication.
Honnêtement, je ne comprends pas à quoi sert ce nerfing dans le cas d'OrderSend. Peut-être les développeurs en diront-ils plus dans l'aide.
P.S. Je n'ai pas écrit une seule ligne dans MQL5. Par conséquent, toutes mes réflexions sur le sujet peuvent être ignorées.
...Quand même, c'est un non-sens. Le Guide de l'utilisateur du terminal client (janvier 2012) indique que l'une des étapes de la commande est l'étape "set(placed) - dealer accepted order".
C'est-à-dire que, selon le manuel, l'ordre signale le stade de vie d'une demande de transaction, alors qu'il a déjà atteint avec succès le serveur. Et la description de la fonction OrderSendAsync() dit exactement le contraire : le code TRADE_RETCODE_PLACED ne dépend pas de l'arrivée au serveur.
Honnêtement, je ne vois pas pourquoi cette ringardise est nécessaire dans le cas d'OrderSend.
En général, n'importe qui peut écrire un MyOrderSend en série via OrderSendAsync :
Avec cette implémentation, MyOrderSend sera totalement identique à l'OrderSend normal (qui peut être simplement éliminé de l'API en l'implémentant via OrderSendAsync dans la bibliothèque normale).
Avec cette implémentation, MyOrderSend sera complètement identique à l'OrderSend normal (qui peut être simplement éliminé de l'API en implémentant OrderSendAsync dans la bibliothèque normale).
En général, l'entrée OrderSendAsync est un événement historique pour Metatrader. Depuis que l'API de négociation existe (à partir de Metatrader3 (je n'ai pas vu les versions antérieures)). Metatrader, bien que mis en œuvre via son propre langage, il est resté pratiquement inchangé dans son essence. OrderSendAsync est la première modification substantielle apportée à l'API de négociation par Metaquotes.
Je félicite sincèrement les développeurs pour cet événement et souhaite apporter le modèle asynchrone à la fonctionnalité adéquate !
Message technique. Rassembler des déclarations intéressantes dans un seul fil.
Notez qu'il existe et existera des limites au nombre d'ordres simultanés dans la file d'attente d' exécution à partir d'un seul compte. Actuellement, il y a 16 demandes, si je ne me trompe pas.
Les opérations asynchrones travailleront soigneusement avec la "fenêtre du nombre d'ordres admissibles", en attendant qu'une partie du lot précédent soit exécutée avant d'envoyer le lot suivant. En outre, il y aura des protections contre les inondations stupides/de tests. Jusqu'à présent, une erreur est reçue lorsque le nombre d'applications autorisées est dépassé.
La nouvelle méthode d'opérations asynchrones par le biais de OrderSendAsync résout le problème principal - elle permet d'effectuer une douzaine d'opérations instantanément. Il s'agit d'un outil très puissant qui doit être utilisé avec précaution et en gardant toujours à l'esprit la possibilité d'une interdiction par le serveur et le courtier.