Erreurs, bugs, questions - page 148

[Prival]

EQU:

Et encore - le code... le code... Le code c'est bien... mais c'est aussi - des tactiques, des cycles... ;)

Le graphique ne reçoit-il pas un message concernant la création d'une nouvelle barre ? Je n'y crois pas...)))

Cela pose-t-il un problème d'en faire un événement ? Est-ce une variable prédéfinie au moins ?

En général, il est plus facile de traiter des événements que de remplir une montagne de code. Et en plus - avec des erreurs (LES PROGRAMMES SANS ERREUR NE SONT JAMAIS !!!) )))))

Je suis tout à fait d'accord avec vous pour dire que le nouveau bar est un événement et qu'il peut (et doit) être programmé. Il y a une branche à https://www.mql5.com/ru/forum/1031. Lisez-la à votre aise, mais je me bats depuis des années...

Z.I. Je pense qu'après avoir lu ceci, vous verrez que la nouvelle barre n'apparaîtra peut-être JAMAIS... un trou...

[Валерий]

EQU:

Encore une fois, code... code... Le code c'est bien... mais aussi les tactiques, les boucles... ;)

Le graphique ne reçoit-il pas un message concernant la création d'une nouvelle barre? Je n'y crois pas...)))

Cela pose-t-il un problème d'en faire un événement, et au moins une variable prédéfinie ?

En général, il est plus facile de traiter des événements que de remplir une montagne de code. Et en plus - avec des erreurs (LES PROGRAMMES SANS ERREUR NE SONT JAMAIS !!!) )))))

D'une manière générale, comment le voyez-vous ? 20 périodes x nombre de symboles dans la "Market Watch" et l'événement OnNewBar est généré pour chacune d'entre elles ? Et vous devez traiter chacune d'entre elles pour déterminer à quel symbole et à quelle période elle se réfère ? Vous avez maintenant le choix : écrire votre propre fonction NewBar et y définir ce que vous voulez recevoir des nouvelles barres : toutes les périodes pour un symbole, tous les symboles pour la période actuelle ou un cas spécial. Il en résulte une fonction spécifique et non compliquée. C'est mieux que la fonction universelle OnNewBar qui comporte de nombreuses vérifications.

[Konstantin Chernov]

Lors du test, une erreur est générée

CTrade::PositionClose::OrderCheck : Demande de stop(s) invalide(s)
Dans mon conseiller expert, il y a les lignes suivantes

description des variables (dans la procédure)

CTrade m_trade ;

..................

position rapprochée

m_trade.PositionClose(_Symbol, eSlippage) ;

Pourquoi le système affiche-t-il une erreur ? CTrade::PositionClose::OrderCheck : Demande de stop(s) invalide(s)

SL et/ou TP erronés
TRADE_RETCODE_INVALID_STOPS

Qu'est-ce que les stops ont à voir avec la fermeture des positions ? Ou est-ce que je rate quelque chose ?

[[Supprimé]]

Prival:

Je suis absolument d'accord avec vous pour dire qu'un nouveau bar est un événement et qu'il peut (et doit) être programmé. Il y a un fil de discussionsur https://www.mql5.com/ru/forum/1031 que vous pouvez lire à loisir, mais je me bats depuis des années....

Z.U. Je pense qu'après avoir lu ceci, il sera clair pour vous que la nouvelle barre n'apparaîtra peut-être JAMAIS... un trou...

J'ai pris le risque de regarder le lien... Je suppose que ça vaut vraiment la peine de le lire... à votre guise... ;)

C'est la raison pour laquelle je souhaite un tel événement... Pas de bar, pas d'événement.

[[Supprimé]]

Valmars:
En fait, comment l'imaginez-vous ? 20 périodes x nombre de symboles dans 'Market Watch' et pour chacun d'entre eux l'événement OnNewBar est généré ? et vous devez traiter chacun d'entre eux pour déterminer à quel symbole et à quelle période il se réfère ? Vous avez maintenant le choix : écrire votre propre fonction NewBar et y définir ce que vous voulez recevoir des nouvelles barres : toutes les périodes pour un symbole, tous les symboles pour la période actuelle ou un cas spécial. Il s'agit d'une fonction simple. C'est mieux que la fonction universelle OnNewBar qui comporte de nombreuses vérifications.

20 timeframes... ce n'est pas la limite pour un paramètre ulong... remplir une variable entière une fois par minute est juste, pas difficile...

Pourquoi, OnTick regarde "x nombre de caractères dans le 'Market Watch' et génère un événement pour chacun..." ? ????

Et la vérification des bits est, croyez-moi, une chose assez rapide...

Et même avec un événement

- personne ne m'obligera à le traiter - pas besoin...

- Et même si vous avez un événement, rien ne vous empêche d'ajouter ou de substituer "écrivez votre propre fonction NewBar et définissez si vous voulez obtenir de nouvelles barres" - si nécessaire...

[Vladimir Kustikov]

Interesting:

Même maintenant, c'est facile à faire, si vous savez comment le faire. Les développeurs ont promis de réécrire OnTrade() et d'y ajouter les paramètres nécessaires.

Rien n'empêche de traiter ces situations localement, dans OnTick() ou OnTime() - à l'endroit de l'opération commerciale; ou dans OnTrade(), si vous devez attraper les actions de l'utilisateur ou les opérations commerciales non contrôlées directement par le code.

La légèreté est un concept relatif. Pour l'un, elle se mesure en grammes, pour l'autre en tonnes. Dans mon Expert Advisor, j'ai dû le faire EASY (si l'on peut appeler mon code ainsi) parce qu'il n'y a pas de variantes de PROSTO dans mon langage actuellement, alors qu'elles pourraient très bien exister, imho. Et je n'étais pas particulièrement heureux de voir le code s'allonger d'une centaine de lignes, ce qui le faisait paraître plus compliqué.

Voici le problème en général :

Un tick arrive, l'indicateur montre la nécessité de fermer, je ferme.

Au prochain tick, l'indicateur montre qu'il faut fermer, et je ne sais pas quoi faire - la position est déjà positionnée et il est possible de savoir ce qui se passe en ce moment, bien sûr, mais je ne sais pas.

Je ne comprends pas pourquoi cette complexité est encore présente ici ? Je ne comprends pas pourquoi nous devons écrire une tonne de code dans l'événement onTrade() pour comprendre ce qui s'est passé ?

Je suis pour la simplicité, et quand elle n'est pas là, cela me rend triste.

[Дмитрий]

Vladix:

La légèreté est un concept relatif, et pour l'un elle se mesure en grammes, pour l'autre en tonnes. J'ai dû le faire en EA (si l'on peut appeler mon code ainsi), car il n'y a pas de variantes de PROSTO dans le langage actuellement, alors qu'elles pourraient très bien exister, imho. Et je n'étais pas particulièrement heureux de voir le code s'allonger d'une centaine de lignes, ce qui le faisait paraître plus compliqué.

Voici le problème en général :

Un tick arrive, l'indicateur montre la nécessité de fermer, je ferme.

Au prochain tick, l'indicateur indique qu'il faut fermer, et je ne sais pas quoi faire - la position est déjà suspendue, et bien sûr je peux trouver ce qui se passe en ce moment, mais je ne sais pas.

Je ne comprends pas pourquoi cette complexité est encore présente ici ? Je ne comprends pas pourquoi dans l'événement onTrade() on nous suggère d'écrire une tonne de code pour comprendre ce qui s'est passé ?

Je suis pour la simplicité, et quand elle n'est pas là, cela me rend triste.

Je l'ai fait, le code est de moins d'une centaine de lignes ... :) La solution est fiable et immédiate pour les multidevises.

//+----------------------------------------------------------------------------+
// Функция контроля открытия ордера на текущем баре               MQL5         |
//-----------------------------------------------------------------------------+
bool ЕстьОрдернаТекущемБаре(ENUM_ORDER_TYPE тип)
  {
   ulong тикет;
   HistorySelect(SeriesInfoInteger(СИМВОЛ,Period(),SERIES_LASTBAR_DATE),TimeCurrent());
   for(int i=0;i<HistoryDealsTotal();i=i+1)
     {
      тикет=HistoryDealGetTicket(i);
      if(HistoryDealGetString(тикет,DEAL_SYMBOL)!=СИМВОЛ || HistoryDealGetInteger(тикет,DEAL_ENTRY)==DEAL_ENTRY_STATE)// || HistoryDealGetInteger(тикет,DEAL_MAGIC)!=MAGIC
         continue;
      if(HistoryDealGetInteger(тикет,DEAL_TYPE)==тип || HistoryDealGetInteger(тикет,DEAL_TYPE)==DEAL_ENTRY_INOUT)
         return(true);
     }
   return(false);
  }

Vous pouvez spécifier n'importe quelle période souhaitée au lieu de celle sur laquelle l'EA plane. C'est-à-dire que les commandes ne seront pas passées plus d'une fois par période.

Et après toute demande de transaction, nous devrions faire un délai qui interdit la demande de transaction dans les 30 secondes (par exemple). Sinon, l'ordre risque de ne pas apparaître dans l'historique au prochain tick.

[[Supprimé]]

Valmars:
En général, comment l'imaginez-vous ? En général, l'idée est d'avoir 20 horizons temporels x le nombre de symboles dans le 'Market Watch' et pour chacun d'entre eux l'événement OnNewBar est généré... Et vous devez traiter chaque symbole et horizon temporel pour déterminer auquel il se réfère ? Vous avez maintenant le choix : écrire votre propre fonction NewBar et y définir ce que vous voulez recevoir des nouvelles barres : toutes les périodes pour un symbole, tous les symboles pour la période actuelle ou un cas spécial. Il en résulte une fonction spécifique et non compliquée. C'est mieux qu'une fonction OnNewBar universelle avec beaucoup de vérifications.

En termes de solution standard, cela devrait ressembler à quelque chose comme ceci

1. L'événement doit être lié au graphique ouvert, à sa période et à son symbole. L'événement doit se produire lorsqu'une nouvelle barre apparaît (les trous sont ignorés).

Les événements doivent être traités dans un ou plusieurs threads distincts du terminal.

PS

Et ainsi de suite. Bien entendu, il s'agit d'une approximation grossière sans tenir compte de nombreuses spécificités...

[[Supprimé]]

Vladix:

En fait, le problème lui-même est le suivant :

un tick arrive, l'indicateur montre qu'il faut fermer, je fais la fermeture.

Au prochain tick, l'indicateur montre qu'il faut fermer, et je ne sais déjà plus quoi faire - la position est déjà suspendue et, bien sûr, on peut savoir ce qui se passe à ce moment-là, mais au fond de son esprit.

Je ne comprends pas pourquoi cette complexité est encore présente ici ? Je ne comprends pas pourquoi, dans l'événement onTrade(), on nous suggère d'écrire une tonne de code pour comprendre ce qui s'est passé ?

Je suis pour la simplicité, et quand tu ne l'as pas, ça devient triste.

Peut-être, les développeurs ajouteront-ils des paramètres à OnTrade(), en tout cas ils y ont pensé. Pour autant que je sache, il y a même eu des déclarations à ce sujet.

[Vladimir Kustikov]

Dmitriy2:

Fait comme ça, moins de code qu'une centaine de lignes... :) la solution est fiable et immédiatement pour le multidevise

Au lieu de la période pendant laquelle l'EA est dormant, nous pouvons spécifier n'importe quelle période souhaitée. Cela signifie que les commandes ne seront pas passées plus d'une fois par période.

Et après toute demande de transaction, nous devrions créer un délai qui désactiverait la demande de transaction dans les 30 secondes (par exemple). Sinon, l'ordre risque de ne pas apparaître dans l'historique au prochain tick.

Mettre un délai - oui, j'accepte, combien de lignes de code cela prendra-t-il ? Et si l'on parle de multidevises, il faut tenir compte du délai sur chacune d'elles, n'est-ce pas ?

J'ai écrit le code qui résout ce problème. Seulement je ne l'aime pas, tout comme, désolé, je n'aime pas le tien. Et il ne s'agit pas de parti pris, le fait est qu'il n'y a pas d'autres options, simples et élégantes.