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
à la sortie de la fonction de démarrage
Jusqu'à 100000 sans amélioration visible
Remplacé par
à l'adresse
Même poivre.
Erreur 146.
c'est-à-dire que nous attendons nous-mêmes que notre propre contexte de transaction soit libéré
et en général, c'est une situation extrêmement étrange. après avoir effectué une opération de transaction, le contexte est libéré instantanément. sinon, il serait impossible de fermer des positions en boucle.
Encore une fois.
Le code ci-dessus fera en sorte que le conseiller expert se bloque, si le drapeau de transaction a été désactivé.
Cela entraînera l'arrêt complet du commerce, car personne ne signalera le sémaphore. Cette situation est au moins quelque peu contrôlable, car le drapeau ne peut être retiré que manuellement.
Le cas du sémaphore est encore pire. GlobalVariableSet peut tomber sur un autre EA, lorsque ce dernier ferme le sémaphore. Par conséquent, plusieurs EA tenteront de négocier en même temps.
Comme nous le voyons, les développeurs ne comprennent pas ce que sont les processus asynchrones qui se déroulent dans le terminal. Et ce malentendu s'exporte dans le forum.
Il n'est pas étonnant que des erreurs fatales, comme celle dont il est question ici, apparaissent et que ces erreurs ne puissent être corrigées.
Pourquoi donner des conseils préjudiciables?
L'hypothèse est que si le conseiller a atteint ce point, alors le drapeau de négociation est maintenu !
l'hypothèse est que si l'EA a atteint ce point, alors le drapeau de trading est levé !
Sur quoi repose cette hypothèse ? Lorsque les hypothèses ne correspondent pas à la réalité, des erreurs inattendues se produisent.
Le drapeau n'est rien.
Synchronisation, mutex, ressources partagées - le problème est réel. Il est absurde de suggérer de résoudre ce problème avec des variables globales au niveau de l'utilisateur. D'autant plus que l'exemple est irréalisable.
Hélas. "Depuis minuit le soir" n'est pas une statistique. Pour des raisons inconnues, les problèmes arrivent par vagues, puis aucun, puis plusieurs à la fois...
J'ai pensé - qui s'en soucie (ton de violoniste de Kindzadz) :)))
En ce qui concerne la réalité de la fermeture/ouverture - j'ai des contrôles dans toutes les fonctions f et des erreurs apparaissent, mais ce sont des erreurs FALSE. J'ai vérifié les journaux et l'historique des ordres, toutes les positions étaient fermées. L'ordre n'a tout simplement pas eu le temps de se déplacer dans l'histoire. J'ai fait un délai d'une seconde avant de vérifier - mais ce n'est pas suffisant... Quand j'ai demandé, ils ne m'ont pas donné de réponse.
Bon point. Mais j'ai eu des cas où, même une heure plus tard, la commande n'a pas avancé, c'est-à-dire que parfois, elle n'est pas fausse.
J'ai aussi un délai de 10 secondes.
Toutes mes erreurs, comme il s'est avéré, étaient dans le code =) c'est-à-dire que j'ai fait la mauvaise vérification après la fermeture de l'ordre.
Après l'avoir corrigé - il n'y en a pas. C'est vrai que peu de temps s'est écoulé, nous devons attendre...
Après l'avoir corrigé - il n'y en a pas. C'est vrai qu'il ne s'est pas passé beaucoup de temps, il faudra attendre...
Comment se présente le code corrigé ?
pour l'ordreclaus :
pour ordersand - juste une 5x tentative de sélectionner un ordre avec une seconde pause,
pour modifiersand - comparer les anciennes valeurs avec les valeurs actuelles