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
Voilà, la solution est simple : nous introduisons une autre vérification pour changer l'historique, de cette façon rien ne sera perdu et cela fonctionnera à 100%.
Cela peut même être utilisé comme un OnTrade() incomplet.
Je suppose que je ne suis pas assez intelligent.)
Comment puis-je l'appliquer ?
Il n'y a qu'un seul problème et il est extrêmement rare. Je l'ai trouvé aujourd'hui pour la première fois en deux ans, peut-être avant, mais je ne l'ai pas remarqué.
Je parlais du calcul de la somme de hachage - comment ajouter un nom de caractère à la valeur de la somme de hachage - calculer les valeurs des codes de lettres qui composent le nom de caractère.
C'est ça, la solution est simple : introduire un autre contrôle de changement d'historique, comme ça rien ne sera perdu et ça marchera à 100%.
Voici un extrait de mon article n°3 :
-------
Concentrons-nous davantage sur le montant du dièse en tant que partie de la structure.
Prenons l'exemple d'un billet. L'ajout/la suppression d'un ordre en attente modifiera le nombre total de ticks sur le compte, le déclenchement d'un ordre en attente ne modifiera pas le nombre total de ticks sur le compte.Il ne suffit pas de connaître le nombre d'ordres et de positions pour pouvoir déterminer avec précision ce qui a changé sur le compte - un ordre en attente peut être supprimé, et dans ce cas, le nombre total d'ordres et de positions sur le compte changera. Mais... Un ordre en attente peut se déclencher et devenir une position. Dans ce cas, le montant total des ordres et des positions ne changerait pas (pour les comptes de couverture et MQL4) - le nombre de positions a augmenté, mais le nombre d'ordres a diminué, donc le montant total reste le même. Cela ne fonctionne pas pour nous.
Regardons le volume total. Vous avez placé ou supprimé un ordre en attente - ; nous l'avons ouvert ou fermé, ou modifié la position - ; le montant total du compte a changé. Cela semble convenir mais, une fois encore, l'activation d'un ordre en attente ne modifiera pas le volume total.
Voyons donc une autre propriété de la position - le temps de son changement en millisecondes : l'ouverture d'une nouvelle position changera le temps total de changement de position, la fermeture partielle changera le temps de changement de position, l'ajout de volume à un compte de compensation changera le temps total de changement de position.Laquelle de ces méthodes convient pour déterminer l'emplacement précis des changements sur le compte ? Ticket + heure du changement de position. Vérifions :
Ici, cependant, je n'ai pas ajouté de symbole à la somme de hachage - il n'y avait pas de précédent pour cela. Mais je l'ai fait fonctionner en conjonction avec l'historique des vérifications. Par conséquent - devrait fonctionner sans erreurs. Cependant, je le vérifierai un jour.
La solution est simple : introduire un autre contrôle de changement d'historique, de cette façon rien ne sera perdu et cela fonctionnera à 100%.
Et oui, il le fera. Si le nombre d'ordres ouverts ne change pas, alors le nombre dans l'historique changera. (Je ne me soucie pas des commandes en cours - je ne les utilise pas). Et nous n'aurons pas à passer en revue toute la journée pour ne retenir qu'un seul événement.
Et si l'utilisateur a reçu un SMS et a décidé d'afficher l'historique dans le terminal au lieu de tout afficher uniquement pour le dernier mois, ce sera un contrôle supplémentaire avec l'essai de toutes les commandes, ce qui n'est pas fatal.
Cela semble être une bonne solution. Et sans référence à quoi que ce soit d'autre que ce que nous avons, à savoir un compte commercial et un terminal.
Voici un extrait de mon article n°3 :
-------
Développons le montant du dièse en tant que partie de la structure.
Envisagez un billet. L'ajout/la suppression d'une commande en attente modifiera le nombre total de tickets sur le compte, le déclenchement d'une commande en attente ne modifiera pas le nombre total de tickets sur le compte.Il ne suffit pas de connaître le montant des ordres et des positions qui ont changé sur le compte pour pouvoir déterminer précisément ce changement - un ordre en attente peut être supprimé et dans ce cas, le montant total des ordres et des positions sur le compte changera. Mais... Un ordre en attente peut se déclencher et devenir une position. Dans ce cas, le montant total des ordres et des positions ne changerait pas (pour les comptes de couverture et MQL4) - le nombre de positions a augmenté, mais le nombre d'ordres a diminué, donc le montant total reste le même. Cela ne fonctionne pas pour nous.
Considérez le volume total. Vous avez placé ou supprimé un ordre en attente - le volume total du compte a changé, ouvert, fermé ou changé de position - le volume total du compte a changé. Cela semble convenir mais, une fois encore, l'activation d'un ordre en attente ne modifiera pas le volume total.
Voyons donc une autre propriété de la position - le temps de son changement en millisecondes : l'ouverture d'une nouvelle position changera le temps total de changement de position, la fermeture partielle changera le temps de changement de position, l'ajout de volume à un compte de compensation changera le temps total de changement de position.Laquelle de ces méthodes convient pour déterminer l'emplacement précis des changements sur le compte ? Ticket + heure du changement de position. Vérifions :
Ici, cependant, je n'ai pas ajouté de symbole à la somme de hachage - il n'y avait pas de précédent pour cela. Mais je l'ai fait fonctionner en conjonction avec l'historique des vérifications. Par conséquent - devrait fonctionner sans erreurs. Cependant, je le vérifierai un jour.
Grosse solution, pas encore besoin d'une telle variante.
Merci !
Grosse décision, pas encore besoin de cette option.
Merci !
"Audacieux" parce qu'il n'a pas été conçu comme une solution locale, mais comme une partie d'un remplacement à part entière de OnTradeXXXX. Il y a plus de travail avec de l'histoire.
Et c'est un grand avantage - nous avons des données prêtes pour la recherche et le tri de tous les ordres et positions dans le programme (nous n'avons pas besoin de rechercher à nouveau les ordres et positions pour répondre aux besoins du programme - tout est déjà dans les listes). Un autre avantage est que le programme sait quel ordre est à l'origine de la position dans MQL4, ce qui ne peut être fait dans les versions mentionnées ci-dessus.
Je le répète, la bibliothèque est faite pour faciliter les choses à ceux qui ont trop de temps et d'argent pour tout faire eux-mêmes. Je n'insiste sur rien, bien sûr :)
Et c'est ainsi. Si le nombre d'ordres ouverts ne change pas, le nombre dans l'historique changera.(Je ne me soucie pas des ordres en attente - je ne les utilise pas). Et vous n'avez pas besoin d'ennuyer votre grand-mère en passant en revue les ordres toute la journée pour ne retenir qu'un seul événement.
Et si l'utilisateur a reçu un SMS et a décidé d'afficher l'historique dans le terminal au lieu de tout afficher seulement pour le dernier mois, ce sera un contrôle supplémentaire avec l'essai de toutes les commandes, ce qui n'est pas fatal.
Cela semble être une bonne solution. Si vous disposez d'un compte de trading et d'un terminal, vous pouvez utiliser uniquement ce que vous avez sans être lié à quoi que ce soit.
Afin de ne pas passer toute la journée, vous pouvez vérifier seulement lorsque les conditions qui peuvent conduire à un changement, l'ouverture, la fermeture d'une position, c'est-à-dire se concentrer sur la réalisation des prix que le conseiller expert utilise pour ouvrir, TP, SL. Eh bien, cela dépend de la logique du conseiller expert, vous savez ce qui est le moins cher.
Pour éviter de passer par toute la journée, vous pouvez vérifier uniquement lorsque les conditions qui peuvent conduire à un changement, à l'ouverture, à la fermeture d'une position ont été remplies, c'est-à-dire se concentrer sur la réalisation des prix que le Conseiller Expert utilise pour ouvrir, TP, SL. Eh bien, oui, cela dépend de la logique du conseiller expert, vous savez ce qui est moins cher.
Un seul EA (sur un seul ordinateur, sur un seul continent) effectue des transactions. L'autre (sur un autre ordinateur, sur un autre continent) s'occupe de ses fonctions. Une solution a déjà été trouvée.
Je vous serais reconnaissant si vous pouviez fournir un exemple reproductible (sans interroger l'historique des transactions).
Voici ce que j'ai trouvé (bien que ce soit hors sujet ici, mais la question a été posée ici).
Coupez en direct. Pas de compatibilité avec MT4 (bien sûr), pas de gestion des erreurs, etc.
Le trading est primitif, il s'ouvre à l'achat et se ferme sur le SL/TP. Le seul but est de démontrer la différence entre OnTradeTransaction() et "polling the server".
Pour moi, il m'a fallu 2,34s contre 3,06s pour passer dans le temps imparti. La différence est faible en raison de la faible charge des fonctions du serveur (une seule position, pas de vérification de la magie et du symbole). Dans l'EA réelle, la différence sera beaucoup plus grande. La différence sera légèrement lissée par le calcul des signaux et l'ajout de stops suiveurs, mais il n'est pas nécessaire de les faire à chaque tick. Mon ATR est calculé sur M1, mais pour 6 heures (c'est-à-dire qu'il y a de la place pour agrandir le TF). Et le seuil de rentabilité est calculé sur H3. Tout dépend de la stratégie.
Vous êtes désespérément en retard sur votre temps !
Ces événements sont garantis depuis longtemps !
Supposons qu'un événement se produise dans OnTradeTransaction() après lequel une action doit être effectuée, mais qu'une erreur se produise lors de la première tentative d'exécution de cette action. Que faire ? Évidemment, elle doit être répétée, et pour cela il est nécessaire d'enregistrer quelque part des données sur la nécessité de répéter cette action - le plus souvent, ces données sont enregistrées dans les variables globales habituelles du Conseiller Expert ou dans des fonctions statiques. Et soudain, j'ai dû redémarrer le terminal... les données ont disparu.
Et quand on analyse la situation actuelle et l'histoire - rien ne va nulle part.