Toute question des nouveaux arrivants sur MQL4 et MQL5, aide et discussion sur les algorithmes et les codes. - page 520

Nouveau commentaire
 
Vitaly Muzichenko:

Quel est l'intérêt d'une telle construction ?

Ou est-il préférable de faire dedatetime un type long ?

Je ne vois pas de problème jusqu'à présent.
Mais il y a un besoin évident de précision (datetime est plus grand que time_t, pour ne pas dire plus).
et il devrait plutôt être long pour les comparaisons de temps. Si le compilateur optimise quelque chose, il le jette, et il reste un dépôt pour l'avenir :-)
 
Maxim Kuznetsov:
Je ne vois pas de problème jusqu'à présent.
Mais il y a une tendance évidente à être plus précis (datetime est doucement plus grand que time_t)
et il est plus probable que cette longue soit utilisée pour comparer les temps. Si le compilateur optimise quelque chose, il le jettera et laissera un dépôt pour le futur :-)

Donc vous pouvez l'utiliser sans tricher sans conséquences ?

 
Vitaly Muzichenko:

Donc vous pouvez l'utiliser sans tricher sans conséquences ?

Eh bien, comment pourrait-il en être autrement sans conséquences :-)

long x = TimeCurrent(); reçoit déjà une "claque sur le visage" dans une bonne entreprise :-) Non seulement les types sont différents en physique, mais ils sont également différents en dimension et vous convertissez un type plus grand en un plus petit.

Mais oui, toutes les secondes de (datetime)TimeCurrent semblent s'adapter à une longue durée.

 
Maxim Kuznetsov:

il existe une excellente fonction StringFind() - recherche l'occurrence de la chaîne "#" ou immédiatement "de #".

Trouvé
StringFind(OrderComment(),"to #",0)


et qu'en faisons-nous ?

DansStringSubstr, tout est clair, vous obtenez les chiffres immédiatement - ticket, mais ici dansStringFind , nous savons déjà qu'il y a"à #" dans le commentaire

 
PolarSeaman:
Trouvé


et que faire avec ?

DansStringSubstr tout est clair, nous obtenons les chiffres immédiatement - ticket, mais ici dansStringFind quoi, nous savons déjà qu'il ya"à #" dans le commentaire

mais on ne sait pas où.) StringFind nous dira si le "à #" que nous recherchons se trouve à cette position ou pas du tout. Ne vous fiez jamais à quelque chose qui vient du net et que vous ne contrôlez pas personnellement :-) Nous jouons de l'argent ici - c'est sérieux.

 
Maxim Kuznetsov:

mais je ne sais pas où :-) StringFind vous dira que le "à #" que vous recherchez se trouve exactement à cette position, ou qu'il n'existe pas du tout. Ne vous fiez jamais à quelque chose qui vient du net et que vous ne contrôlez pas personnellement :-) Nous jouons de l'argent ici - c'est sérieux.

il faut mettre en évidence le ticket du commentaire et jeter le "à #".

le ticket pour une position ouverte est comparé à celui du commentaire pour une position fermée

pourquoi cherchons-nous le "to #" ?

 

La fonctionStringSubstr renvoie la partie droite du commentaire. Pourquoi cette fonction renvoie-t-elle le bénéfice d'une position ouverte et non le bénéfice d'une position fermée ? Je passe parMODE_HISTORY

double prof_cl_pos(string sy="0", int op=-1, int mn=-1) {
  datetime ta;
  int      i, k=OrdersHistoryTotal();
  double profit_=0;
  string comment="";
  string substr="";

  if (sy=="" || sy=="0") sy=Symbol();
  for (i=0; i<k; i++) {
    if (OrderSelect(i, SELECT_BY_POS, MODE_HISTORY)) {
      if (OrderSymbol()==sy) {
        if (OrderType()==OP_BUY || OrderType()==OP_SELL) {
          if (op<0 || OrderType()==op) {
            if (mn<0 || OrderMagicNumber()==mn) {
              comment=OrderComment();
               substr = StringSubstr(comment, 4, 9);
              if (ticket_op_pos(Symbol(), -1,mn)==substr)
              profit_=OrderProfit();
            }
          }
        }
      }
    }
  }
  return(profit_);
}
 
Vitaly Muzichenko:

Où est le mal dans une telle conception ?

Ou est-il préférable de faire dedatetime un type long ?

datetime est ulong - c'est là que vous devez le mettre.
 
PolarSeaman:

Le ticket doit être mis en évidence dans le commentaire et le"à #" doit être supprimé.

le ticket pour une position ouverte doit être comparé au ticket dans le commentaire pour une position fermée

pourquoi cherchons-nous le"to #" ?

Nous le recherchons afin de savoir "s'il y a même un to# ou un from#" dans le commentaire. Si ce n'est pas le cas, alors cet ordre ne fait pas partie d'une position fermée et nous n'en avons pas besoin.

Si le StringFind(OrderComment(), "#to") est supérieur ou égal à zéro, cela signifie que le commentaire contient la sous-chaîne recherchée, et seulement maintenant nous pouvons calculer la position du numéro de ticket dans cette chaîne.

 
PolarSeaman:

La fonctionStringSubstr renvoie la partie droite du commentaire. Pourquoi cette fonction renvoie-t-elle le bénéfice d'une position ouverte et non le bénéfice d'une position fermée ? Je passe parMODE_HISTORY.

Et voici la réponse à cette question.

Forum sur le trading, les systèmes de trading automatisés et les tests de stratégie

Toutes les questions des débutants sur MQL4, aide et discussion sur les algorithmes et les codes

PolarSeaman, 2018.04.07 00:25

Trouvé
StringFind(OrderComment(),"to #",0)


Et qu'en faire ?

Tout est clair dansStringSubstr, vous obtenez des chiffres - ticket, mais ici dansStringFind quoi, nous savons déjà qu'il y a"à #" dans le commentaire


Mais si vous ne le faites pas, vous obtiendrez quelque chose de complètement différent.

1...513514515516517518519520521522523524525526527...1954
Nouveau commentaire