Développeurs ! Est-ce que vous testez au moins ce que vous créez ? - page 5
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
Veuillez répondre à deux questions simples :
1. Si la transaction est effectuée, dois-je obtenir TRADE_TRANSACTION_DEAL_ADD --> ORDER_STATE_STARTED ou non ?
2. Après le message indiquant que l'ordre a été modifié TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_REQUEST_MODIFY
Dois-je recevoir le message TRADE_TRANSACTION_ORDER_UPDATE --> ORDER_STATE_PLACED ou non ?
Bien que la question ne soit pas pour moi, je vais essayer d'y répondre :)
Travailler avec des événements signifie que les événements attendus peuvent ne pas se produire, par exemple, vous pouvez vous perdre en cours de route, ou vous pouvez ne pas attendre dans la file d'attente, et très peu de choses peuvent se produire (y compris le bug du terminal). Vous devez donc sauvegarder votre modèle d'événement pour qu'il fonctionne de manière fiable. Par exemple, je construis une liste d'attente pour les événements particulièrement importants et je la contrôle non seulement par des événements connexes, mais aussi par la confirmation indirecte que l'événement attendu s'est produit.
Artem, je ne veux pas te croire sur parole, mais ce n'est pas une
un geste délibéré de votre part. Le fait est que les bugs actuels ne vont pas
ne vous permettra pas d'écrire un EA selon mes TOR.
En ce moment, mon conseiller expert fonctionne et apporte un bénéfice de 1% par jour.
Je voulais le mettre à jour en profondeur, mais à cause de bogues dans
Les erreurs MT-5 ne fonctionnent pas.
Et deuxièmement, quels sont les frais initiaux si nous effectuons un test sur votre compte avec un dépôt de 5000 euros ?
Je mets toujours mes conditions préliminaires. Après avoir accepté mes conditions préliminaires, je lis les TdR, puis je dis - ça coûtera moins cher / ça coûtera plus cher / ce n'est pas réaliste. Après l'accord, nous discutons du cahier des charges dans les moindres détails. Et ce n'est qu'après une compréhension mutuelle complète que nous confirmons notre volonté de travailler. Pendant le travail, nous collaborons étroitement avec le client. Toujours en contact. Nous poursuivons les discussions et les clarifications sur chacun des "rouages" de l'algorithme. Tant que le prochain "rouage" n'est pas affiné et testé, nous ne passerons pas au suivant. Avant de transmettre la solution finale, je teste moi-même l'algorithme pour détecter les erreurs, mais seulement dans le testeur, et uniquement pour l'exactitude de l'algorithme. Test sur le compte - uniquement pour les bogues et uniquement par le client, et uniquement à ses frais.
Je comprends que c'est une conversation à propos de rien. Finissons-en avec ça.
P/S Quel langage de haut niveau parlez-vous ?
Avons-nous déjà commencé un "concours de pisse" ?
Je vais te dire, c'est un gros mot.
Bonjour, Yuri !
Oui, bien sûr, vous avez raison, un événement peut ne pas arriver une fois, mais deux ou même trois fois.
Mais ils viennent, mais AUTREMENT !
Pouvez-vous me dire comment contrôler que la commande a été modifiée (sans réponse du serveur) ?
Avons-nous déjà commencé un "concours de pisse" ?
Je réponds - avec un gros mot.
Artyom, vous avez une compréhension tordue des questions !
J'ai simplement pensé qu'il est possible de vous proposer d'écrire (au lieu du conseiller)
Je viens de penser que je pourrais vous proposer d'écrire (à la place du conseiller) un petit terminal pour Plaza II, ce sera difficile...
Artyom, vous avez une compréhension tordue des questions !
Je viens de penser qu'il est possible de vous proposer d'écrire (à la place du conseiller)
Je me suis dit que je pourrais vous proposer d'écrire (au lieu de conseiller) un petit terminal pour Plaza II, ce serait difficile de le faire seul...
Je m'excuse. Je vous ai mal compris. La fatigue m'affecte - je travaille sur une commande compliquée, je ne dors pas beaucoup.....
Merci pour l'offre. Mes plans sont un peu différents. Je pense que je vais passer mon tour.
Bien que la question ne s'adresse pas à moi, je vais essayer d'y répondre :)
Travailler avec des événements signifie que les événements attendus peuvent ne pas se produire, par exemple, se perdre en chemin, ou la file d'attente peut ne pas attendre, et très peu de choses peuvent se produire (y compris un bug du terminal). Vous devez donc sauvegarder votre modèle d'événement pour qu'il fonctionne de manière fiable. Par exemple, je crée pour les événements très importants une liste d'attente et je la contrôle non seulement par des événements connexes, mais aussi par la confirmation indirecte que l'événement attendu s'est produit.
Non, ça ne marche pas. Le modèle d'événement doit être absolument fiable. Si l'événement n'a pas eu lieu, il n'a pas eu lieu. Sur FORTS, les événements doivent être exécutés de manière particulièrement claire car les changements d'ordre peuvent générer des dizaines de transactions.
Merci à vous aussi, mais je pense que je vais
"au Plaza II.
Je ne le recommande pas. Il est beaucoup plus facile de corriger ce bogue avec MQ que de construire soi-même un nouveau terminal pour Plaza. S'enliser dans la correction sans fin des bogues et l'écriture de la "fonctionnalité standard". Je parle de ma propre expérience. J'ai partiellement développé l'un de ces complexes autodidactes basés sur Stock# - le résultat est un autre "vélo" pour des tâches spécifiques. Vous feriez mieux de vous battre avec le service d'assistance, ce sera plus facile et moins cher.
Bonjour, Yuri !
Oui, bien sûr, vous avez raison, un événement peut ne pas arriver une fois, mais bien deux ou même trois fois.
Mais ils viennent, mais d'AUTRES fois !
Néanmoins, ces une, deux ou trois fois peuvent arriver au moment le plus inopportun, ce qui est exactement ce qui vous est arrivé. L'Aide, d'ailleurs, couvre ce point en détail. Les développeurs ne recommandent pasde construire votre algorithme de trading en attendant que certaines transactions arrivent après d'autres.
Une demande de transaction envoyée manuellement depuis le terminal ou via les fonctions OrderSend()/OrderSendAsync() peut générer plusieurs transactions consécutives sur le serveur de transactions. L'ordre d'arrivée de ces transactions dans le terminal n'est pas garanti. Nous ne pouvons donc pas construire notre algorithme de négociation en attendant l'arrivée de certaines transactions commerciales après d'autres. En outre, les transactions peuvent être perdues lors de leur transfert du serveur au terminal.
//---
Pourriez-vous me dire comment contrôler si un ordre est modifié (sans réponse du serveur) ?
Par exemple, comparez les valeurs précédentes avec les valeurs actuelles.
Non, ça ne marche pas. Le modèle d'événement doit être absolument fiable. Si l'événement n'a pas eu lieu, alors il n'a pas eu lieu. Sur FORTS, les événements doivent être exécutés de manière particulièrement précise car les changements d'ordre peuvent générer des dizaines de transactions.
Par définition,le modèle piloté par les événements ne peut être absolument fiable. Si l'événement n'est pas arrivé, cela ne signifie pas qu'il ne s'est pas produit.
tol64 !
Oui, la façon dont ils arrivent n'a pas d'importance (bien qu'il ne soit pas logique que l'événement "commande passée" arrive en premier, suivi de "commande en cours de modification").
Pas bien ?
Si vous regardez attentivement ma photo, vous verrez que le message "commande partiellement exécutée" est arrivé (il y en a deux à la suite), au lieu de "commande passée" !
P/S Et pas besoin de "déchirer le texte" et toute la phrase qui commence comme ça :
En connaissant le type de transaction, vous pouvez décider d'analyser l'état actuel des ordres, des positions et des transactions dans votre compte de trading.