Erreurs, bugs, questions - page 249

Nouveau commentaire
 


alexluek:

Il n'y a pas eu de perte de communication, de surcharge de tics, et plus le TF est gros, plus il est rare.

Et la méthode de calcul de la date de début à la date de fin (j'ai découvert qu'il y en a 3) sans

C'est probablement le cas (il recalcule toutes les barres), mais ce n'est pas encore précis et je ne sais pas comment le vérifier.

mais c'est juste une idée - vérifions-la...

Il y a peut-être un autre moyen de s'en débarrasser...


Yedelkin:

Bien sûr, il y a une approche. Si(prev_calculated==0), nous effectuons le calcul initial pour toutes les barres. Ensuite, pour chaque nouveau tick (si 0 < prev_calculated < rates_total) nous effectuons des calculs comme for(int i=prev_calculated-1;i<rates_total;i++) uniquement pour les dernières barres apparues.


Toujours en train de redessiner. Mis en œuvre de cette façon :


int calculated1=BarsCalculated(StdDev1Handle) ;

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

si(CopyBuffer(StdDev1Handle,0,0,to_copy,ExtStdDev1Buffer)<to_copy)return(0) ;

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

int data1=CopyOpen(Symbol1,0,0,rates_total,Open1Buffer) ;

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

for(int i=rates_total-2 ; i>=0 ; i--)
{
if(time[i]>=DateStart)

{


Il redessine puis ne redessine pas, mais peut-être qu'il s'agit de l'exactitude du travail du code.

mais pas dans le terminal (mais au moins il n'est pas si distinctif maintenant...)

Les ticks ou l'absence de ticks peuvent toujours redessiner.

L'impression est qu'il n'y a pas de cohérence (relation de cause à effet).

La seule chose qui me vient à l'esprit est un processeur faible ou un blocage.

La seule chose qui vient à l'esprit est un processeur faible ou le gel du terminal (MT5).

 

alexluek:

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

Il redessine puis il ne redessine pas, mais c'est une question de correction du code.

et non dans le terminal (du moins, ce n'est plus si distinctif maintenant...)

Veuillez envoyer une demande au service d'assistance avec le code source, nous trouverons une solution.
 

Quelqu'un a-t-il travaillé avec la deuxième version de la fonction ChartGetInteger ?

2. Возвращает true или false в зависимости от успешности выполнения функции.
В случае успеха значение свойства помещается в приемную переменную, 
передаваемую по ссылке последним параметром.

bool  ChartGetInteger(
   long    chart_id,        // идентификатор графика
   int     prop_id,         // идентификатор свойства
   int     sub_window,      // номер подокна
   long&   long_var         // сюда примем значение свойства
   );

? Il semble que la valeur de la propriété ne soit pas transmise à la variable réceptrice. Au moins, ce comportement est remarqué lors de l'utilisation de la construction

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))
La fonction renvoie true, mais la variable windows contient la valeur obtenue lors de l'initialisation de cette variable. Dans ce cas, la première version de la fonction produit une valeur correcte. (Et encore une chose triviale : si la variable de récupération est déclarée de type long, le compilateur génère un avertissement).
 
Yedelkin:

Quelqu'un a-t-il travaillé avec la deuxième version de la fonction ChartGetInteger ?

? Il semble que la valeur de la propriété ne soit pas transmise à la variable réceptrice. Au moins, ce comportement est remarqué lors de l'utilisation de la construction

La fonction renvoie true, mais la variable windows contient la valeur obtenue lors de l'initialisation de cette variable. Dans ce cas, la première version de la fonction produit une valeur correcte. (Et encore une chose triviale : si la variable de récupération est déclarée de type long, le compilateur génère un avertissement).
Oui, ça existe. Seulement j'essayais de demander la couleur de fond. Je voulais écrire à Servicedesk, mais j'ai oublié.
 
Lizar:
Oui, ça existe. J'ai seulement essayé de demander la couleur de fond. J'allais écrire à Servicedesk, mais j'ai oublié.
Ok, je le ferai.
 
Yedelkin:

Quelqu'un a-t-il travaillé avec la deuxième version de la fonction ChartGetInteger ?

? Il semble que la valeur de la propriété ne soit pas transmise à la variable réceptrice. Au moins, ce comportement est observé lors de l'utilisation de la construction

La fonction renvoie true, mais la variable windows réceptrice contient la valeur obtenue lors de l'initialisation de cette variable. Dans ce cas, la première version de la fonction produit la valeur correcte. (Et encore une petite chose : si la variable réceptrice est déclarée avec le type long, le compilateur générera un avertissement).

Il semble que vous utilisiez une mauvaise fonction. Il s'agit de la première variante de la fonction (avec trois paramètres). Elle ne renvoie pas true (comme vous le pensez), mais la valeur du paramètre

if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,windows))

Je ne vois pas votre code, mais il semble être correct :

long Chart=0,windows;
if(!ChartGetInteger(Chart,CHART_WINDOWS_TOTAL,0,windows))
  {
   //--- всё плохо
  }
 
uncleVic:

Vous semblez utiliser la mauvaise fonction. Il s'agit de la première version de la fonction (avec trois paramètres). Elle ne renvoie pas true (comme vous le pensez), mais la valeur du paramètre

Je ne vois pas votre code, mais il semble être correct :

Hmmm..., oui, j'avais exactement ce bug - j'ai regardé mon ancien code où j'essayais d'utiliser cette fonction.
 
uncleVic:

Vous semblez utiliser la mauvaise fonction. Il s'agit de la première version de la fonction (avec trois paramètres). Elle ne renvoie pas true (comme vous le pensez), mais la valeur du paramètre

OK. Voyons cela.

1. La fonction est utilisée "que", car vous citez une fonction portant le même nom que votre exemple. Il ne peut s'agir que de la version de cette fonction (première ou deuxième) qui est utilisée.

2. En effet, formellement, la première variante de la fonction a trois paramètres, tandis que la seconde en a quatre. Toutefois, dans la description du paramètre sub_window, qui est présent dans les deux variantes de l'appel, il est clairement indiqué que "la plupart des propriétés ne nécessitent pas le numéro de subwindow". Une question se pose : est-il nécessaire ou non d'indiquer le numéro de la fenêtre pour une propriété telle que CHART_WINDOWS_TOTAL (Nombre total de fenêtres du graphique, y compris les sous-fenêtres des indicateurs) ?

3 Il est logique de penser qu'il n'est pas nécessaire de spécifier séparément le nombre de fenêtres/sous-fenêtres du graphique pour obtenir le nombre total de fenêtres/sous-fenêtres. Cette conclusion est étayée par l'exemple tiré directement du manuel lui-même ( section Propriétés des graphiques) :

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);

Une approche similaire est décrite dans la section Chart Operations / ChartWindowOnDropped.

À partir de ces exemples, on peut voir que la position des auteurs du manuel est qu'il n'est pas nécessaire de spécifier un numéro de sous-fenêtre distinct pour obtenir le nombre total de fenêtres/sous-fenêtres dans un graphique. Bien sûr, les exemples utilisent la première variante de la fonction, mais puisque nous parlons de la même propriété (c'est-à-dire CHART_WINDOWS_TOTAL), il serait logique de supposer que la même conclusion s'applique à la deuxième variante de la fonction. Surtout si l'on tient compte du fait que le manuel ne contient aucune réserve sur la nécessité de spécifier un numéro de sous-fenêtre nul pour la deuxième variante de la fonction.

4) Votre exemple suggère que le troisième paramètre(sub_window) doit toujours être spécifié pour la deuxième variante de la fonction, même si la propriété elle-même ne nécessite pas de spécifier un numéro de sous-fenêtre. C'est-à-dire que, contrairement à la première variante de la fonction (qui peut être utilisée aussi bien avec deux qu'avec trois paramètres), la deuxième variante de la fonction requiert toujours les quatre paramètres. N'est-ce pas ?

5. Si c'est correct, nous avons établi deux choses. D'abord, ma version originale du problème s'est avérée être fausse. Deuxièmement, la raison de cette version erronée est que les informations contenues dans le manuel sont incomplètes. C'est pourquoi je propose de préciser dans le manuel que "Il n'y a pas de valeur par défaut pour la deuxième option, le numéro de sous-fenêtre doit donc toujours être spécifié. Pour la plupart des propriétés qui ne nécessitent pas un numéro de sous-fenêtre, il est nécessaire de spécifier 0 (fenêtre principale du graphique)". Ou quelque chose comme ça.

Merci pour l'exemple. C'est court et précis.

 
Yedelkin:
Dans la première variante de la fonction, intsub_window=0 a une valeur par défaut, elle peut donc être omise ; dans la deuxième variante, cette valeur par défaut n'existe pas, elle doit donc être spécifiée.

 
Yedelkin:

OK. Faisons le tri.

1. La fonction utilisée est "que", car vous citez une fonction portant le même nom que votre exemple. Il ne peut s'agir que de la version de cette fonction (première ou deuxième) qui est utilisée.

2. En effet, formellement, la première variante de la fonction a trois paramètres, tandis que la seconde en a quatre. Toutefois, dans la description du paramètre sub_window, qui est présent dans les deux variantes de l'appel, il est clairement indiqué que "la plupart des propriétés ne nécessitent pas le numéro de subwindow". Une question se pose : est-il nécessaire ou non d'indiquer le numéro de la fenêtre pour une propriété telle que CHART_WINDOWS_TOTAL (Nombre total de fenêtres du graphique, y compris les sous-fenêtres des indicateurs) ?

3 Il est logique de penser qu'il n'est pas nécessaire de spécifier séparément le nombre de fenêtres/sous-fenêtres du graphique pour obtenir le nombre total de fenêtres/sous-fenêtres. Cette conclusion est étayée par l'exemple tiré directement du manuel de référence lui-même (section Propriétés du graphique) :


1. Compte tenu du fait que la fonction est en fait surchargée, nous pouvons affirmer qu'elle ne l'est pas (bien que, comme vous pouvez l'imaginer, cela soit discutable) ;

2. C'est le but. Si je comprends correctement la logique de la surcharge de fonctions dans MQL5, la première option peut être utilisée avec 2 ou 3 paramètres, tandis que la seconde ne peut être utilisée qu'avec 4 paramètres.

C'est-à-dire que si une fonction reçoit deux ou trois paramètres, MQL5 utilisera la première option, alors qu'il utilisera toujours la seconde si elle en reçoit 4.

Le fait est que le compilateur s'embrouille dans ses appels si nous utilisons la deuxième variante avec un numéro de paramètre non égal à 4.

3. Il y a une petite inexactitude dans la référence (ou plutôt une formulation légèrement erronée). Le sens général est le suivant : la plupart des propriétés ne nécessitent pas de numéro de fenêtre, et dans la première option pour ces propriétés, le numéro de fenêtre peut être omis(dans la deuxième option, il doit être spécifié, mais il sera ignoré).

4. il résulte de ce qui précède que pour cet exemple, le compilateur choisira la première variante de la fonction.

   int windows=ChartGetInteger(0,CHART_WINDOWS_TOTAL);
   Print("CHART_WINDOWS_TOTAL = ",windows);
Le compilateur fera une telle conclusion sur la base du fait que le troisième paramètre dans la première variante peut être omis, alors que dans la deuxième variante, il doit nécessairement être présent ! !!
1...242243244245246247248249250251252253254255256...3184
Nouveau commentaire
Raison: