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
Comment utiliser correctement la fonction RefreshRates() ?
Lisez également sur le forum "ERROR : code=138 - requote ".
J'ai "OrderSend error 138" généré dans le testeur plusieurs fois par seconde... est-ce une requote ? Si c'est le cas, comment le combattre) ?
Après avoir lu 20 fils de discussion sur les requêtes... J'ai enfin compris quelle était mon erreur)
J'ai eu une "pseudo" requote. La raison en est la condition d'entrée qui a été déclenchée et donc le prix a été envoyé à . En réalité, le prix réel était inférieur ou supérieur à celui annoncé dans . Chaque fois que OrderSend a essayé d'ouvrir un ordre, il a donné l'erreur 138, bien sûr.
La solution était de vérifier avant l'envoi de l'ordre si le prix réel était égal au prix transmis par le signal).
Ce qui reste à faire, c'est le contrôle des erreurs pour les ordres OrderModify, car cela pourrait entraîner de mauvaises conséquences - pas d'arrêt !
Je pense que nous n'avons pas besoin de vérifier l'OrderSend, laissons-le battre son pouls au prix donné par le signal) Si des requêtes arrivent, cela n'aura pas d'importance - j'aurai le temps d'acheter ou de vendre. L'essentiel est que tout fonctionne comme prévu).
Après avoir lu 20 fils de discussion sur les requêtes... J'ai enfin compris quelle était mon erreur)
J'ai eu une "pseudo" requote. La raison en est la condition d'entrée qui a été déclenchée et donc le prix a été transmis à OrderSend. Et en réalité, le prix réel était inférieur ou supérieur à celui que j'avais saisi dans OrderSend. Chaque fois que OrderSend a essayé d'ouvrir un ordre, il a donné l'erreur 138.
La solution était de vérifier avant l'envoi de l'ordre le prix réel, s'il était égal au prix transmis par le signal).
Il ne reste plus qu'à vérifier l'absence d'erreurs pour les ordres OrderModify, car cela peut entraîner de mauvaises conséquences - pas d'arrêt !
Je pense qu'il n'y a pas besoin de vérifier OrderSend, laissez-le battre son pouls au prix que le signal fixe) Si des requêtes arrivent, cela n'aura pas d'importance - j'aurai le temps d'acheter ou de vendre. L'essentiel est que tout fonctionne comme prévu).
RefreshRates();
Si vous voulez vérifier toutes les valeurs des limites de vente ou d'achat avant le bloc qui calcule le stop take et le prix d'entrée - les ordres en attente à long terme peuvent ne pas être affectés s'ils ne sont pas calculés sur la base du prix actuel.
RefreshRates();
il est utile de le faire avant d'accéder à Ask Bid
Ce n'est pas ce que j'ai fait... avant le Bid.
avant le bloc qui calcule le stop take et le prix d'entrée - les ordres à distance peuvent ne pas être affectés s'ils ne sont pas calculés en utilisant le prix actuel.
N'est-ce pas ce que j'ai fait... avant de me tourner vers Bid.
>>Veuillez expliquer. Donc, dans mon cas, il n'est pas nécessaire ici, car il ne s'agit pas de compter, mais de comparer ? Est-ce que je lis bien ?
Vous avez fait le bon choix :-)
Ce n'est pas un problème là-bas !
C'est juste que votre bloc où vous accédez aux prix devrait de préférence se trouver à un seul endroit.
il est préférable d'avoir cette commande avant d'appliquer
Vous vous adressez au Bid Ask et après avoir calculé tous les stops, vous devez entrer sur le marché sans trop tarder.
---
ajoutez ceci au code
en termes simplifiés
1 - Signal reçu - activer le drapeau pour l'exécution.
2refresh() calculer les arrêts à emporter
3-in
4 serveurs rejetés
5- Erreur de décodage
6-signal est toujours actif- drapeau d'exécution activé ?
7- aller au point 1
et il est nécessaire de briser ce cycle
car il peut devenir assez long
mais nous devons
1-décider de l'erreur
2 - essayer de frapper le concessionnaire moins longtemps que ne le prévoit le cycle.
2.1 par exemple, vous pourriez compter le nombre de fois où vous vous êtes tapé dessus.
2.2 vous pouvez faire un quantum de temps
2.3 Vous DEVEZ vérifier si vous avez un signal avant d'envoyer des commandes d'exécution !
ou vous pourriez vouloir l'annuler !
...c'est juste que vous devriez avoir le bloc où vous accédez aux prix, de préférence à un seul endroit.
et il est préférable d'avoir cette commande avant d'appeler
vous allez au Bid Ask et calculez tous les stops pour entrer sur le marché sans délai...
En un seul endroit... Je ne comprends pas bien... Je travaille sur l'indicateur depuis longtemps mais je n'arrive pas à boucler la boucle).
Je l'ai comme ça :
-Le prix d'entrée est défini par les fonctions UpTrend() et DownTrend() qui vérifient la présence du signal
-vérifier (si) la parité du prix avec le prix du signal
-Le prix à saisir et les prix sont traités par OrderSend
-le prix stop est traité dans la fonction ModifyPos() qui suit OrderSend.
1- Signal reçu - drapeau activé pour l'exécution //la fonction de vérification du signal passe la fonction de mise en ordre.
2-refresh() calculer les décollages // vérifier la cohérence avec le prix - prix du signal (s'il est toujours actif)
3-entrée //le calcul des décollages est statique dans la fonction OrderSend, s'arrête dans la fonction OrderModify
4-serveur rejeté //si l'ordre n'est pas placé et qu'il y a un signal, alors nous ré-entrons au prix du signal (s'il est toujours valide)
5-décodez l'erreur //vous en avez besoin pour vous-même, au cas où il y aurait un nouveau problème.
Le signal 6 est toujours actif - drapeau à exécuter ? //condition de la concordance des prix - prix du signal (s'il est encore valide).
7- Aller à l'étape 1 //à l'étape 3
et nous devons briser ce cycle.
il peut devenir assez long // tant que le prix==le prix du signal, je ne pense pas, mais cela peut être fréquent)
mais nous devons
1-déterminer l'erreur //Je pense que je vais travailler dessus aujourd'hui.
2-essayer de frapper le dealer pas aussi longtemps qu'il devrait l'être //le prix==le prix du signal
2.1 vous pouvez faire un compteur pour le nombre de fois que vous devez aller long // devez y penser, vérifiez votre historique dans le testeur
2.2 vous pouvez le faire en un quantum de temps //peut manquer le prix==le prix du signal (s'il est encore actif)
2.3 Vous DEVEZ vérifier s'il y a un signal avant de donner des ordres pour exécuter chaque série !
il est peut-être temps d'annuler le signal //la fonction de vérification du signal passe la fonction de définition des ordres
Maintenant je ne comprends pas comment implémenter correctement OrderModify ? Sans elle, je ne peux pas définir un arrêt... limite DC à l'ouverture...
- peut obtenir une erreur de 130 si le prix change après l'ouverture et s'il se rapproche de l'ouverture.
-il est possible d'obtenir une erreur de requote 138 et que le prix augmente et que le stop ne soit pas fixé du tout.
-il est possible d'obtenir une requote de 138 et le prix baissera, ce qui n'est pas critique puisque le stop sera fixé plus tard.
Alors...
Les inconvénients de cette variante sont
-Si le prix passe en dessous du prix d'ouverture, le stop ne sera jamais fixé.
Si le prix passe en dessous du prix ouvert, le stop ne sera jamais placé - il tentera toujours de modifier l'ordre. Ou pas ?
ou plus...
Inconvénients de cette variante
-Il y aura beaucoup d'erreurs si le prix bouge contre
Pour l'instant, je considère cette option sur l'arrêt, la mettre jusqu'à ce qu'elle soit mise en place).
Mais il y a des erreurs dans les lignes avec ModifyB; ModifyB;
- ';' - variable déjà définie
- ';' - variable déjà définie
Une autre option, mais aussi avec des erreurs (
Une autre option, mais aussi avec des erreurs (