Erreurs, bugs, questions - page 989
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
...
Et mettre plus d'agents de verrouillage que de noyaux devrait être interdit par la loi, c'est tout !
Bon après-midi. J'ai une question pour les développeurs. Le cycle idéal de génération de transactions comprend les étapes suivantes :
Envoi d'une demande via OrderSend(), suivi de la vérification que la méthode a renvoyé un vrai code de retour correct.
Ensuite, il faut suivre le passage de la requête sur le serveur via OnTradeTransaction(). Ce gestionnaire est très pratique et permet un contrôle total du processus.
Mais nous vivons dans le monde réel et, par exemple, en raison d'un échec de connexion ou simplement parce que la transaction a été "perdue à la livraison", nous ne pouvons pas attendre une transaction comme TRADE_TRANSACTION_REQUEST. Ainsi, le cycle d'attente deviendra sans fin et il sera impossible de déterminer si la transaction s'est achevée sur demande ou non.
Existe-t-il une procédure de base pour gérer de telles urgences et obtenir sans ambiguïté un achèvement du processus logiquement correct pour toute force majeure ? Par exemple, si nous n'attendons pas TRADE_TRANSACTION_REQUEST dans les 20 (ou 30 ou 40) secondes, nous passons à un algorithme plus lent mais correct, à savoir : nous comparons le volume actuel du symbole avec le volume avant OrderSend(), nous recherchons l'historique de l'ordre et calculons son statut et nous décidons s'il faut faire une demande d'ouverture supplémentaire ou ignorer le signal. La tâche se complique encore pour la méthode OrderSendAsync() : nous devons disposer d'un critère précis pour savoir quand une certaine commande n'a pas été déclenchée et savoir quand commencer à appliquer ce critère. Si je comprends mal quelque chose, veuillez me corriger.
Pour la méthode OrderSendAsync(), la tâche est encore plus compliquée - nous devons avoir un critère exact pour qu'une commande spécifique ne se déclenche pas et savoir quand commencer à appliquer ce critère. Si je comprends mal quelque chose, veuillez me corriger.
HistorySelectByPosition - en théorie, cela devrait aider, l'id est donné lorsque l'ordre est envoyé.
VanHelsing:
Les systèmes 32x Win7 ont des problèmes avec les opérations avec des nombres réels, sur XP il refuse de fonctionner en passant des valeurs à la bibliothèque"wininet.dll".
1. Faites-vous une règle d'envoyer des ordres de transaction sur le tick actuel et de vérifier leur exécution sur le tick suivant. Ainsi, vous n'aurez pas de boucles sans fin.
2. Pour vérifier l'exécution des ordres donnés au cours du tick précédent, ne vous embêtez pas avec OnTrade()/ OnTradeTransaction(). Vérifiez les changements dans l'état de votre compte, c'est-à-dire travaillez avec la source. Après tout, tout arrangement commercial vise à modifier un état de votre compte de trading. Vérifiez donc le changement d'état.
3. En fonction des résultats des tests et de la logique de votre robot.
Avant d'utiliser des fonctions comme OnTrade()/OnTradeTransaction(), décidez de ce qui est le plus important pour vous :
a). pour réaliser l'ouverture/la fermeture/la modification d'une position à des conditions de marché données ;
b) Perdre votre temps à essayer de trouver la raison pour laquelle votre ordre de transaction n'a pas été exécuté, et à chercher un coupable.
Pourtant, je reste avec une certaine incompréhension. Si les résultats de la vérification au tick suivant ne montrent PAS de changements dans la position, que devons-nous faire dans ce cas ? Les raisons de l'absence de changements peuvent être très différentes. Comme alternative :
un ordre sur demande a été formé sur le serveur, mais a été rejeté pour une raison quelconque,
le serveur est surchargé - l'exécution est retardée,
la connexion est perdue pendant un certain temps.
Nous aimerions avoir un critère exact pour la non-exécution de l'ordre. La liaison au temps dans un système asynchrone ne me semble pas très précise et permet donc l'incertitude. Il serait peut-être judicieux de sélectionner l'ordre dans l'historique et de vérifier son statut, ou, comme le suggère Sion, d'utiliser HistorySelectByPosition. Je suppose que si les développeurs ont conçu ce système de cette manière, il devrait y avoir des méthodes "correctes" pour traiter ces opérations clés.
Nous voulons avoir un critère exact pour que l'ordre ne soit pas exécuté.
On vous a déjà expliqué que
ne vous embêtez pas avec OnTrade()/ OnTradeTransaction().
Travaillez avec le code source.
Bonjour à tous !
Comment faire pour que tout le contenu de l'onglet "Experts" soit écrasé au démarrage du script ? (comme une commande cls), car il peut être difficile de distinguer où la sortie d'impression du début précédent du script et celle du début actuel ont abouti.
Merci ! !!
Bonjour à tous !
Comment faire pour que tout le contenu de l'onglet "Experts" soit écrasé au démarrage du script ? (comme une commande cls), car il peut être difficile de distinguer où la sortie d'impression du début précédent du script et celle du début actuel ont abouti.
Merci ! !!
Ajoutez la ligne suivante au script deinit
Print("===================== La fin ===================")
et vous ajoutez une ligne au script deinit
Print("===================== La fin ===================")
Merci, ça aide !
Ai-je bien compris qu'il n'y a pas d'analogue de la commande "Effacer" du clic droit dans le script ? :)