Erreurs, bugs, questions - page 3128

Nouveau commentaire
 
Vladimir Pastushak #:
Finance : Une question non financière

Ouvert,Démarré: 2021.09.02 10:45,#3182963

Bonjour, j'ai activé le ticket car le bouton "Nouvelle demande" ne fonctionne pas.

Motif de la demande : La description des 4 dernières langues, coréen, italien, français, turc n'est pas sauvegardée dans les signaux.

Le soulever car il ne fonctionne pas.

 
J'ai besoin d'un script qui exécute le script/service sur tous les terminaux MT4/5 en fonctionnement. Pouvez-vous suggérer des paramètres de PostMessage.
 
fxsaber #:
J'ai besoin d'un script qui exécute le script/service sur tous les terminaux MT4/5 en fonctionnement. Pouvez-vous suggérer les paramètres de PostMessage.

Je ferais un service qui attend que le fichier de commande apparaisse dans le dossier commun. Eh bien, et un script pour créer une telle commande.

 
Andrey Khatimlianskii #:

Je ferais un service qui attend que le fichier de commande apparaisse dans le dossier commun. Eh bien, et un script pour créer une telle commande.

Très béquille, et MT4 est toujours d'actualité.

 

Je n'ose pas dire que c'est un bug. Je vais donc dire que j'ai remarqué une particularité de l'instruction if. Je soupçonne que cela peut être vrai pour d'autres langues également.

if(a && Array[over_index]>val) {...}

Si a s'avère être vrai, la vérification saute à Array[over_index] et ici le terminal commence à se planter dans la partie'array out of range', ce qui est tout à fait juste. Mais si a s'avère être faux, le terminal ne vérifiera pas la condition Array[over_index] et donc la redondance d'index, et si sautera plus loin et le codeur ne saura pas qu'il y a un tableau avec un index inexistant dans son programme.... ou plutôt une existante mais redondante.

Peut-être devrait-il y avoir un correctif pour que la vérification de 'array out of range' soit effectuée à la toute fin de la boucle if et que le même message soit affiché ? Ou bien cela réduira-t-il considérablement la vitesse de l'opérateur ?


 
x572intraday #:

Je n'ose pas dire que c'est un bug. Je vais donc dire que j'ai remarqué une particularité de l'instruction if. Je pense que cela peut s'appliquer à d'autres langues également.

Si a s'avère être vrai, la vérification passe à Array[over_index] et ici le compilateur commence à planter la partie'array out of range', ce qui est tout à fait vrai. Mais si a s'avère être faux, le terminal ne vérifiera pas la condition Array[over_index] et donc la redondance d'index, et si sautera plus loin et le codeur ne saura pas qu'il y a un tableau avec un index inexistant dans son programme.... ou plutôt une existante mais redondante.

Peut-être devrait-il y avoir un correctif pour que la vérification de 'array out of range' soit effectuée à la toute fin de la boucle if et que le même message soit affiché ? Ou bien cela réduira-t-il considérablement la vitesse de l'opérateur ?


Ce n'est pas le cas dans votre cas, car les deux conditions doivent être remplies. Mais si vous mettez

if(a || Array[over_index]>val) {...}
alors, oui. Si la condition "a" est remplie, la deuxième condition ne sera pas vérifiée. On s'est battu pour cela pendant des années, et maintenant vous suggérez que nous retournions au siècle dernier...
 
x572intraday #:

Je n'ose pas dire que c'est un bug. Je vais donc dire que j'ai remarqué une particularité de l'instruction if. Je pense que cela peut s'appliquer à d'autres langues également.

Si a s'avère être vrai, la vérification saute à Array[over_index] et ici le terminal commence à s'écraser sur la partie'array out of range', qui est tout à fait vraie. Mais si a s'avère être faux, le terminal ne vérifiera pas la condition Array[over_index] et donc la redondance d'index, et si sautera plus loin et le codeur ne saura pas qu'il y a un tableau avec un index inexistant dans son programme.... ou plutôt une existante mais redondante.

Peut-être devrait-il y avoir un correctif pour que la vérification de 'array out of range' soit effectuée à la toute fin de la boucle if et que le même message soit affiché ? Ou bien cela réduira-t-il considérablement la vitesse de l'opérateur ?

Si vous modifiez ce comportement, les programmes écrits normalement vont tout simplement "planter", tandis que ceux qui ne le sont pas seront difficiles à écrire.

Lisez la suite, vous y trouverez une description

 
x572intraday #:

Je n'ose pas dire que c'est un bug.

C'est un comportement normal partout. Si vous voulez que l'argument soit calculé tout le temps, calculez-le avant le if-.

 
Alexey Viktorov #:

Dans votre cas, ce n'est pas le cas, car les deux conditions doivent être remplies. Mais si tu mets ça

alors, oui. Si la condition "a" est remplie, la deuxième condition ne sera pas vérifiée. On s'est battu pour cela pendant des années, et maintenant vous suggérez que nous retournions au siècle dernier...

Vérifiez

// +--------
int start()
{
 if(false && Test()) { 
  Print("if Yes"); // Это никогда не напечатает
 }
}

// +--------
bool Test() {
 Print("Test"); // Это тоже, к ней не дошла очередь
 return(true);
}
 
Alexey Viktorov #:

Dans votre cas, ce n'est pas le cas, car les deux conditions doivent être remplies. Mais si tu mets ça

alors, oui. Si la condition "a" est satisfaite, la deuxième condition ne sera pas vérifiée. Ils se sont battus pour cela pendant de nombreuses années et maintenant vous proposez de revenir au siècle précédent...

Curieusement, mais avec a=true non seulement à || mais aussi à && il n'y a pas de vérification du reste. Sinon, comment expliquez-vous cela (ne cherchez pas de signification dans le fonctionnement de l'indicateur, nous parlons ici du code) :

#property indicator_chart_window
#property indicator_buffers 1
#property indicator_plots   1
#property indicator_type1   DRAW_ARROW
#property indicator_color1  Gray
#property indicator_label1  "Fractal Up"
//--- indicator buffers
double ExtUpperBuffer[];
//--- 10 pixels upper from high price
int    ExtArrowShift=-10;

void OnInit()
  {
//--- indicator buffers mapping
   SetIndexBuffer(0,ExtUpperBuffer,INDICATOR_DATA);
   IndicatorSetInteger(INDICATOR_DIGITS,_Digits);
//--- sets first bar from what index will be drawn
   PlotIndexSetInteger(0,PLOT_ARROW,217);
//--- arrow shifts when drawing
   PlotIndexSetInteger(0,PLOT_ARROW_SHIFT,ExtArrowShift);
//--- sets drawing line empty value--
   PlotIndexSetDouble(0,PLOT_EMPTY_VALUE,EMPTY_VALUE);
  }

int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
   if(rates_total<5)
      return(0);

   int start;
//--- clean up arrays
   if(prev_calculated<7)
     {
      start=2;
      ArrayInitialize(ExtUpperBuffer,EMPTY_VALUE);
     }
   else
      start=rates_total-5;

   for(int i=start; i<rates_total-3 && !IsStopped(); i++)
     {
      //--- Upper Fractal
      if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>high[i+3] && high[i]>high[i+4])
         ExtUpperBuffer[i]=high[i];
      else
         ExtUpperBuffer[i]=EMPTY_VALUE;
     }

   return(rates_total);
  }

Le terminal est silencieux. Mais si vous changez

if(high[i]>high[i+1] && high[i]>high[i+2] && high[i]>high[i+3] && high[i]>high[i+4])

à

if(high[i]>high[i+4] && high[i]>high[i+2] && high[i]>high[i+3] && high[i]>high[i+1])

le programmeur le modifie et le fameux message 'array out of range' apparaît car le programmeur tombe immédiatement sur un tableau avec un index excessif contrairement au premier cas.

1...312131223123312431253126312731283129313031313132313331343135...3184
Nouveau commentaire