Symboles personnalisés. Erreurs, bogues, questions, suggestions. - page 27

 
Stanislav Korotky:

L'ajout de ticks un à un (en particulier de EURUSD sur MQ Demo) à un nouveau symbole personnalisé vide donne l'erreur 5310 (pas immédiatement, mais dans une boucle à partir d'une date arbitraire).

Qu'est-ce qu'il y a ? Comment puis-je savoir quelles tiques spécifiques sont grondées ? Mettre les tableaux dans le journal - pas de violation chronologique ici.

Essayez d'insérer la copie de contrôle des tics.
J'ai un indicateur sur les données en temps réel en traitement tick, lors de la copie de CopyClose, parfois il déclenche une erreur de copie.
Je ne comprends pas ce qui peut être la raison. Dans votre cas, il y a peut-être une erreur de copie.

De même, dans CopyTicks, vous copiez un grand nombre de ticks Limit, puis dans la boucle while, c'est-à-dire à chaque itération, vous copiez un grand tableau de ticks.
Et dans CustomTicksAdd vous passez le même grand nombre de ticks au tableau.
Essayez de copier un tick et de passer un tick.
Vous êtes en train de tourner en boucle.

input int Limit = 10000;
input datetime Start = D'2020.06.01';

int fillArray(ulong &_start)
{
  MqlTick array[];
  int size = CopyTicks(_Symbol, array, COPY_TICKS_ALL, _start, Limit);

  if(size <= 0) 
  {
     Print("Ошибка копирования ценовых данных "+_Symbol+" "+(string)size+" ",GetLastError());
     return(size);
  }

  if(size > 0)
  {
    _start = array[size - 1].time_msc + 1;
    if(CustomTicksAdd(symbolName, array) == -1)
    {
      Print("Error:", GetLastError());
      return(-1);
    }
  }
  return(size);
}

...
{
  ulong startMsc = (ulong)Start * 1000;
  while(fillArray(startMsc) > 0);
}
Ajouté. Non lié aux symboles personnalisés.
Je viens d'attraper dans l'indicateur, dans le tick temps réel la cause de l'erreur de copie avec la période M5 par la fonction CopyClose.
La connexion Internet a été coupée pendant quelques secondes et après la connexion est apparue l'erreur de copie 4401L'historique demandé n'a pas été trouvé
C'est étrange, la période M5 n'a pas encore changé à une nouvelle barre, mais l'erreur est apparue.
 
Roman:

Essayez d'insérer le contrôle de la copie des tics.
Dans mon indicateur sur les données en temps réel en traitement tick, lors de la copie de CopyClose, une erreur de copie se produit parfois.
Je ne comprends pas ce qui peut être la raison. Dans votre cas, il y a peut-être une erreur de copie.

De même, dans CopyTicks, vous copiez un grand nombre de ticks Limit, puis dans la boucle while, c'est-à-dire à chaque itération, vous copiez un grand tableau de ticks.
Et dans CustomTicksAdd vous passez le même grand nombre de ticks au tableau.
Essayez de copier un tic, et de passer un tic.

Il n'y a pas d'erreur de copie, le code obtient une valeur normale du nombre de ticks copiés (taille), le tableau est rempli de données normales tout le temps. La limite peut être modifiée, mais une erreur se produit à toute valeur significative de un à plusieurs milliers. Copier tous les ticks en une seule fois (comme dans certains codes) est évidemment une erreur car cela peut provoquer une erreur d'allocation de mémoire et bloquer le thread pendant un long moment sans pouvoir montrer la progression à l'utilisateur. Et le fait de copier des ticks par petits lots de 10 (sans parler de 1) ralentit l'ensemble du processus - c'est inacceptable.

La variante proposée est optimale. Et même si c'est discutable pour quelqu'un, formellement le code est correct (ou citez où je me trompe) et le comportement actuel est une erreur, c'est-à-dire que les ticks doivent être ajoutés sans le code 5310.

En outre, il existe toujours un problème de longue date concernant l'effacement de la base de données des tics. Call CustomTicksDelete(symbolName, 0, LONG_MAX) ; ne veut pas supprimer tous les ticks et en laisse quelques-uns (on l'observe non pas constamment, mais environ une fois de temps en temps). Si vous redémarrez le conseiller expert, le symbole personnalisé est complètement effacé. Comme dans le cas de CopyTicks - aucune erreur.

 
Si vous souhaitez écrire des ticks sans générer davantage d'événements OnTick, il peut être préférable d'utiliser une autre fonction.
 
Stanislav Korotky:

Peut-être y a-t-il des tics avec le même ms à la jonction des packs et cela compte comme une erreur ?

Juste une supposition

 
Andrey Khatimlianskii:

Peut-être y a-t-il des tics avec le même ms à la jonction des packs et cela compte comme une erreur ?

Juste une supposition.

Vous pouvez voir dans le code qu'il y a des ticks en double. Dans ce cas, les drapeaux des ticks peuvent ne pas correspondre les uns aux autres.

 
fxsaber:
Si vous devez écrire des ticks sans générer davantage d'événements OnTick, il est préférable d'utiliser une autre fonction.

Je suis d'accord. Je vais essayer. Mais je ne vois aucune raison pour que la méthode actuelle ne fonctionne pas.

 
Stanislav Korotky:

Il n'y a pas d'erreur de copie, le code obtient une valeur normale du nombre de ticks copiés (taille), le tableau est rempli de données normales tout le temps. La limite peut être modifiée, mais une erreur se produit à toute valeur significative de un à plusieurs milliers. Copier tous les ticks en une seule fois (comme dans certains codes) est évidemment une erreur car cela peut provoquer une erreur d'allocation de mémoire et bloquer le thread pendant un long moment sans pouvoir montrer la progression à l'utilisateur. Et le fait de copier des tics par petits lots de 10 (sans parler de 1) ralentit l'ensemble du processus.

La variante proposée est optimale. Et même si c'est discutable pour quelqu'un, formellement le code est correct (ou citez où je me trompe) et le comportement actuel est une erreur, c'est-à-dire que les ticks doivent être ajoutés sans le code 5310.

En outre, il existe toujours un problème de longue date concernant l'effacement de la base de données des tics. Call CustomTicksDelete(symbolName, 0, LONG_MAX) ; ne veut pas supprimer tous les ticks et en laisse quelques-uns (on l'observe non pas constamment, mais environ une fois de temps en temps). Si vous redémarrez le conseiller expert, le symbole personnalisé est complètement effacé. Comme dans le cas de CopyTicks - aucune erreur.

ERR_CUSTOM_TICKS_WRONG_ORDER

5310

Tableaude ticksnon ordonnés par le temps


Il est possible que vous n'ayez pas le temps de supprimer les ticks par grands lots, car vous écrasez ceux qui existent déjà lors de l'itération suivante.
C'est-à-dire qu'ils se superposent les uns aux autres comme un tableau, tandis qu'il vole sans délai, de sorte que la mémoire n'a pas le temps de se vider lorsqu'un autre paquet arrive.
C'est pourquoi j'ai suggéré d'ajouter un tick à la fois, j'ai copié un tick à la fois, sans problème.

Quant à l'effacement de la base de données des ticks, je n'aime pas la constante LONG_MAX dans ce cas.
L'aide de la fonction CustomTicksDelete indique que l'heure du dernier tick dans l'historique des prix de la plage spécifiée doit être supprimée. Le temps en millisecondes depuis le 01.01.1970.
Et LONG_MAX est beaucoup plus grand que cette valeur. C'est-à-dire qu'une valeur plus grande est passée, pour laquelle ce paramètre n'est pas conçu.
Essayez d'utiliser le nombre correspondant au chiffre des millisecondes, c'est-à-dire 13 valeurs.

 
fxsaber:

Vous pouvez voir dans le code qu'il y a des ticks en double. Dans ce cas, les drapeaux élémentaires des ticks peuvent ne pas correspondre.

Les ticks dupliqués sont-ils dans le tableau de réception CopyTicks ? Comment est-il clair qu'il s'agit de tiques dupliquées, et non des mêmes tiques (les tiques n'ont pas d'identifiant unique, après tout) ? Même s'il y a des doublons, en théorie, les ticks avec des coupures égales ne cassent pas la séquence. Enfin, une question se pose : comment les doublons sont-ils formés ?

 
Roman:

ERR_CUSTOM_TICKS_WRONG_ORDER

5310

Tableaude ticksnon ordonnés par le temps


Il est possible que les gros paquets de ticks n'aient pas le temps d'être supprimés, puisque vous écrasez ceux que vous avez déjà dans l'itération suivante.
C'est-à-dire qu'ils se superposent les uns aux autres comme un tableau, alors qu'il vole sans délai, apparemment, la mémoire n'a pas le temps de se vider lorsqu'un autre paquet arrive.
C'est pourquoi j'ai suggéré d'ajouter un tick à la fois, j'ai copié un tick à la fois, il n'y a pas eu de problèmes.

Pas un mot sur la suppression, rien n'est écrasé. Les itérations sont chronométrées sans chevauchement. Toujours dans un caractère personnalisé vide - soit un nouveau, soit après une suppression réussie de tous les ticks.

 
Stanislav Korotky:

Des ticks en double dans le tableau de réception CopyTicks ? Comment est-il clair qu'il s'agit de ticks dupliqués et non de ticks identiques (les ticks n'ont pas d'identifiant unique, après tout) ? Même s'il y a des doublons, en théorie, les ticks avec des coupures égales ne cassent pas la séquence. Enfin, une question se pose : comment les doublons sont-ils formés ?

J'ai regardé le code de plus près. Vous manquez de tiques quand vous les recevez par lots. Il peut y avoir une situation où Ticks[Limit - 1].time_msc == Ticks[Limit + k], k >= 0.

Par conséquent, lorsque vous ajoutez avec un skip, les drapeaux peuvent ne pas correspondre.


Assurez-vous que tous les ticks historiques ayant la même heure se trouvent à la fin de la portion. C'est-à-dire que le début du morceau suivant doit avoir une heure différente. Sinon, il y aura des pertes, même en écrivant sur mesure.

Si vous voulez utiliser CopyTicks, le plus simple est d'écarter les ticks les plus extrêmes avec le temps le plus long du paquet reçu. Et rendez _start égal à ce temps.