Erreurs, bugs, questions - page 570

[Rashid Umarov]

Voir les propriétés du programme (#property):

tester_indicator	string	Имя пользовательского индикатора в формате "имя_индикатора.ex5". Необходимые для тестирования индикаторы определяются автоматически из вызова функций iCustom(), если соответствующий параметр задан константной строкой. Для остальных случаев (использование функции IndicatorCreate() или использование неконстантной строки в параметре, задающем имя индикатора) необходимо данное свойство
tester_file	string	Имя файла для тестера с указанием расширения, заключенное в двойные кавычки (как константная строка). Указанный файл будет передан тестеру в работу. Входные файлы для тестирования, если необходимы, должны указываться всегда
tester_library	string	Имя библиотеки с расширением, заключенное в двойные кавычки. Библиотека может быть как с расширением dll, так и с расширением ex5. Необходимые для тестирования библиотеки определяются автоматически. Однако, если какая-либо библиотека используется пользовательским индикатором, то необходимо использовать данное свойство

[Konstantin Chernov]

Rosh:

Voir les propriétés du programme (#property):

Merci.

[gumgum]

Sur le graphique en ticks (dans l'aperçu du marché) sur le compte de démonstration XAUUSD, il y a une réinitialisation constante.

Aussi :

Ouvrez "détails" et passez la souris sur l'espace vide.

[Alexey Da]

gumgum:

Sur le graphique en ticks (dans l'aperçu du marché) sur le compte de démonstration XAUUSD, il y a une réinitialisation constante.

Aussi :

Ouvrez "détails" et passez la souris sur l'espace vide.

Je ne suis pas sûr de ce que signifie la réinitialisation permanente.

Quel OS, quel OS et quelle capacité du terminal ?

[x572intraday]

Rosh:

Apprenez, car il est dit dans la rédaction de la documentation - Indicateurs techniques:

Cela signifie qu'au premier démarrage de l'indicateur (lors du passage à un nouveau cadre temporel pour la première fois), les valeurs de l'indicateur n'ont pas encore été calculées, donc prev_calculated=0. Lorsque vous revenez à ce cadre temporel, l'indicateur n'est pas créé à nouveau, puisque son handle est toujours vivant. Par conséquent, prev_calculated!=0

J'étais sur le point de vous prendre au mot, mais j'ai changé d'avis. Les résultats que j'ai obtenus extérieurement disent presque que tout n'est pas toujours aussi lisse, il y a quelques exceptions... mais je ne comprends toujours pas si elles, ces exceptions, sont liées aux poignées ou s'il s'agit d'un autre problème ?

" Note : si la fonction OnCalculate renvoie une valeur nulle, les valeurs des indicateurs ne sont pas affichées dans la DataWindow du terminal client. "Je m'empresse de vous rassurer : c'est bien pire, si j'ai réussi à relier correctement les résultats dans ma tête à la documentation et à interpréter moi-même l'effet qui en résulte. Non seulement les valeurs de l'indicateur ne sont pas affichées, mais l'indicateur entier cesse de fonctionner, la file d'attente des commandes se fige et vous ne pouvez pas attendre que les prochaines commandes soient traitées. C'est d'ailleurs ce que j'ai réussi à entrevoir dans certains de mes précédents billets.

Comme déjà mentionné, le code a beaucoup de copies... ...qui n'implique pas un handle, (c'est à dire tout sauf CopyBuffer). Si le résultat de la copie <= 0, on obtient le return(0), après quoi"l'indicateur a cessé de fonctionner" et l'indicateur est complètement paralysé.

Je tiens à vous rappeler que le non-dessin initial, avec la paralysie qui l'accompagne, se produit dans le mode sans fenêtre du terminal (c'est-à-dire en fin de semaine ou hors ligne). Ne le considérez pas comme sans importance, car personne n'a envie de déboguer ses indicateurs le week-end, de faire des gestes inutiles, de passer en revue les délais et de déclencher artificiellement - manuellement - le premier tirage. Et il ne s'agit pas seulement de déboguer.

Honnêtement, je n'avais pas assez d'esprit pour relier les liens gentiment fournis aux exemples de la documentation, où il est dit d'augmenter le compteur de référence à la poignée déjà existante (ainsi qu'avec d'autres réponses données) au problème existant. Je ne pense pas du tout que ça se développe à partir de là.

Essayez de reproduire le code ci-joint dans les conditions suivantes : l'horizon temporel prédéfini dans le code est D1, l'horizon temporel actuel dans le terminal est D1, le terminal est en mode hors ligne. Lorsque l'indicateur est attaché au graphique avec l'horizon temporel actuel spécifié, les résultats de l'enregistrement apparaîtront instantanément dans l'onglet Experts.

Maintenant, déchargez complètement le terminal, redémarrez-le et passez à un horizon temporel autre que D1 . Mettez l'indicateur - il ne changera pas jusqu'à ce que vous passiez à un autre cadre temporel (pas nécessairement D1).

En raison de cette caractéristique désagréable, une bonne idée disparaît en même temps que l'indicateur souscrit.

Les développeurs, j'en suis sûr, peuvent trouver des explications pour ce comportement de l'indicateur, mais c'est injuste, quand les données de TF master-défini dans sa poignée sont parfaitement affichées, quand un utilisateur est à ce cadre temporel, mais s'il est à un autre, il doit faire des mouvements inutiles. Je suis pour l'égalité des délais lors de l'utilisation des poignées d'indicateurs externes, les autres TF ne sont coupables de rien.

P.S. : Alors... Attendez. J'ai vérifié une nouvelle fois - il s'avère que CopyHigh n'influence même pas cette paralysie. Maintenant, je ne comprends plus rien du tout. Tous mes soupçons se sont soudainement portés sur une poignée dans OnInit...

P.P.S. : ajout d'un deuxième exemple de code - même s'il ne répond pas.

[x572intraday]

La limite du problème a été trouvée.

Commentez-le :

   SetIndexBuffer(0,FractalUpBuffer,INDICATOR_DATA);
   PlotIndexSetInteger(0,PLOT_ARROW,217);
   PlotIndexSetInteger(0,PLOT_ARROW_SHIFT,ArrowShift);

- et le problème disparaît, mais c'est alors une indication claire d'une liaison de tampon occasionnelle incorrecte via SetIndexBuffer . Et cela indique déjà la nécessité d'abandonner l'utilisation deSetIndexBuffer et de recourir à la manipulation manuelle de la taille du tampon surveillé.

En outre, l'exemple ci-joint démontre clairement l'incapacité de BarsCalculated(handle ) àcalculer dans le temps les valeurs de l'indicateur appelé sur n'importe quel TF actuel, à moins qu'il ne coïncide avec un TF prédéfini, ou le refus en principe de calculer quoi que ce soit à la première fois (très probablement cette variante). Dans ce cas, la valeur sera <=0, return(0) et stop comme résultat.

[gumgum]

alexvd:

La signification de la réinitialisation permanente n'est pas tout à fait claire.

Quel OS, quel OS et quel bit de terminal ?

W7 et MT5 64 bits.

exemple :

XAUUSD se remet toujours au début (XAGUSD est une comparaison).

[Rashid Umarov]

x100intraday:

Trouvez la limite du problème.

Commentez-le :

- et le problème disparaîtra, mais il s'agira alors d'une indication claire d'une liaison de tampon occasionnelle incorrecte via SetIndexBuffer . Et cela indique déjà la nécessité d'abandonner l'utilisation deSetIndexBuffer et de recourir à la manipulation manuelle de la taille du tampon surveillé.

En outre, l'exemple ci-joint démontre clairement l'incapacité de BarsCalculated(handle) à calculer en temps voulu la valeur de l'indicateur appelé sur n'importe quel TF actuel, à moins qu'il ne coïncide avec un TF prédéfini. Dans ce cas, la valeur sera <=0, return(0) et stop comme résultat.

Pour le premier exemple (je n'ai pas regardé le second), l'indicateur de paralich a une fonction

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
bool FillArraysFromBuffers(double &up_arrows[],datetime &up_times[],int ind_handle,int amount)
  {
   if(CopyBuffer(ind_handle,0,0,amount,up_arrows)<0) return(false);
   else CopyTime(_Symbol,PERIOD_D1,0,amount,up_times);

   return(true);
  }

Donc, imaginez que votre indicateur est sur D1 et que vous essayez de copier les données de l'échelle temporelle H1 vers son tampon d'indicateur. Le nombre d'éléments ne correspond pas. Je pense que c'est là que réside votre problème - il n'y a pas de contrôle avant la copie des données.

Des exemples d'indicateurs qui prennent des données d'autres périodes sont disponibles dans l'aide de chaque indicateur technique. Par exemple https://www.mql5.com/ru/docs/indicators/iama :

//--- узнаем количество рассчитанных значений в индикаторе
   int calculated=BarsCalculated(handle);
   if(calculated<=0)
     {
      PrintFormat("BarsCalculated() вернул %d, код ошибки %d",calculated,GetLastError());
      return(0);
     }
//--- если это первый запуск вычислений нашего индикатора или изменилось количество значений в индикаторе iAMA
//--- или если необходимо рассчитать индикатор для двух или более баров (значит что-то изменилось в истории)
   if(prev_calculated==0 || calculated!=bars_calculated || rates_total>prev_calculated+1)
     {
      //--- если массив iAMABuffer больше, чем значений в индикаторе iAMA на паре symbol/period, то копируем не все 
      //--- в противном случае копировать будем меньше, чем размер индикаторных буферов
      if(calculated>rates_total) values_to_copy=rates_total;
      else                       values_to_copy=calculated;
     }
   else
     {
      //--- значит наш индикатор рассчитывается не в первый раз и с момента последнего вызова OnCalculate())
      //--- для расчета добавилось не более одного бара
      values_to_copy=(rates_total-prev_calculated)+1;
     }

[Rashid Umarov]

x100intraday:

Essayez de reproduire le code ci-joint dans les conditions suivantes : l'horizon temporel prédéfini dans le code est D1, l'horizon temporel actuel dans le terminal est D1, le terminal est en mode hors ligne. Lorsqu'un indicateur est attaché à un graphique avec l'horizon temporel actuel spécifié, les résultats de l'enregistrement apparaîtront instantanément dans l'onglet Experts.

Et en général, avez-vous essayé d'utiliser le débogage au lieu de la journalisation, afin de ne pas recevoir des tonnes de messages ? Aide dans le MetaEditor → Développement du programme → Débogage

[x572intraday]

Rosh:

Imaginez donc que votre indicateur est sur D1 et que vous essayez de copier les données de la trame H1 dans son tampon d'indicateur. Le nombre d'éléments ne correspond pas. Je pense que c'est là que réside votre problème - il n'y a pas de contrôle avant la copie des données.

Tout d'abord, je vais clarifier : les cas de débordement de tableau lors de la copie de valeurs via les fonctions Copy... ne provoquent-ils pas une erreur de débordement"Array out of range" dans les Experts du terminal client ? Je me souviens que de tels messages sont parfois générés après une compilation réussie, alors que l'indicateur fonctionne, mais je ne peux pas dire exactement. Je pense que ce n'est pas sur la fonction Copy...-function, mais sur une référence à un index inexistant ou quelque chose comme ça.

Deuxièmement, je m'empresse de vous assurer que votre hypothèse sur l'absence de contrôle n'est pas tout à fait correcte. Il peut parler uniquement du filtre if-else généré de manière incorrecte, mais pas de son absence totale. J'ai trébuché dessus plus d'une douzaine de fois. Récemment, j'ai posé ici ou dans "Dummies" une question sur l'analogie des taux_total pour les horizons temporels, différents de l'actuel, mais je n'ai reçu de réponse de personne. Le problème est que rates_total est l'un des paramètres de la période actuelle, et il est absolument inutile pour moi, parce que je travaille avec beaucoup d'autres périodes, et si j'utilise l'une des périodes prédéfinies, j'utilise toujours universal calculated=BarsCalculated(handle) pour les calculs au lieu de rates_total. Je fais peut-être une grosse erreur, mais je ne vois pas l'utilité de rates_total pour cette tâche.

Troisièmement, je suis depuis longtemps en mesure de réaliser que, étant dans un TF élevé, je peux copier et redistribuer avec succès les valeurs des TF inférieurs, et vice versa. Les exemples que j'ai donnés il y a quelques jours sont minimes mais exhaustifs, tout est là. L'écart entre les quantités de deux TF différentes peut être de deux types : pénurie et excédent. Le premier cas n'est pas terrible, mais je vais vérifier que le second ne déborde pas et essayer de le limiter, si quelque chose ne va pas. Mais il se bloque également si les barres copiées d'une autre période sont plus petites que le nombre de barres de la période actuelle.

Quatrièmement, l'indicateur a été testé et vérifié pendant environ une semaine déjà, il n'a pas montré d'erreurs évidentes (ni à la compilation ni pendant le fonctionnement), il y a seulement quelques problèmes implicites, l'un d'entre eux étant le non tracé initial des barres dans certains TFs et la forte augmentation du temps de calcul sur M1 quand on y repasse (pendant la première fois, tout est calculé en 2-3 secondes). L'indicateur semble s'étouffer dans les calculs (fuite mémoire avalanche ?) J'ai limité le nombre d'éléments copiés à l'aide de CopyBuffer - à 200 au lieu de l'historique entier, mais cela n'a pas changé la situation. J'ai remarqué que, hors ligne sur M1 et partout ailleurs, le calcul est toujours rapide, alors que pour la première fois, en ligne, la situation change radicalement (probablement, le problème est dans ce même filtre, qui saute quelque chose à chaque tick, bien qu'il ne devrait pas l'être, parce que la fréquence de redessin dépend du redessin d'une nouvelle barre zéro et ne peut pas être antérieure à la plus jeune TF prédéfinie dans l'une des poignées). Petits problèmes mais désagréables : la moindre tentative de faire défiler le graphique avec la molette de la souris dématérialise toutes les fractales et il faut attendre qu'elles soient recalculées et dessinées (bien qu'aucune nouvelle barre ne soit arrivée, il semble n'y avoir rien à recalculer).