Veuillez expliquer ce qui pourrait clocher dans cette fonction. - page 4

 
Alexey Viktorov:

Vladimir, le problème ne se produit pas dans le testeur... Comment se fait-il qu'il y ait un tel problème ? Ou parce qu'il n'y a qu'un seul conseiller expert dans le testeur ?

J'ai également suggéré dans le SD que le seul changement était de mettre le second EA sur une paire différente...

L'ensemble de l'environnement commercial du testeur est préparé à l'avance. Tout est dans une assiette. Pas d'inquiétude. L'environnement de négociation réel est différent, en cas de comportement non standard (travailler sur l'horizon temporel et/ou le symbole de quelqu'un d'autre), nous devons nous inquiéter de la pertinence de l'environnement de négociation.
 
Karputov Vladimir:
Dans un terminal (sur l'échelle de temps M15, il y avait des EA), cela n'a pas fonctionné sur un symbole - je suis sûr à 99% que le problème est que lorsque vous utilisez l'échelle de temps de quelqu'un d'autre , vous devez "secouer" l'historique tout le temps. Je pense qu'il est préférable de le faire via CopyTime().
Et CopyRates() bouscule l'histoire. Il y a du temps dans la structure...
 
Karputov Vladimir:

Ce n'est pas une erreur. Vous travaillez sur le calendrier de quelqu'un d'autre. Dans ce cas, vous devez vous-même vous occuper des données sur le calendrier de quelqu'un d'autre pour vous assurer qu'elles sont à jour.

Personnellement, je ne vois pas d'autres solutions.

Ce n'est pas un fait que nous ne savons pas comment fonctionneSERIES_LASTBAR_DATE. Il se peut qu'il ne soit pas nécessaire de mettre à jour quoi que ce soit car l'heure de la dernière barre peut être calculée en utilisant TimeCurrent() du symbole spécifié. Nous devons demander aux développeurs.

Mais jusqu'à présent, un fait clair et indiscutable est que si deux variables sont définies comme vraies, alors ensemble (en vérifiant &&) ces variables donneront également vrai.

 

Le problème de l'abandon du cache des autres outils/TF existe bel et bien.

Et vérifier les erreurs et attendre que la boucle se charge n'aide pas toujours. Nous avons discuté avec le Service Desk, mais MQ n'a fait aucun progrès, seulement une allusion :

Support Team 2016.02.29 11:45

La suspicion est que les données historiques sont déchargées par le timeout.

Il y a deux solutions :

1. accéder aux données plus souvent qu'une fois toutes les 3 minutes

2. mettre un indicateur très simple sur les données. Le volume, par exemple. Il n'y a pas de calcul, un seul tampon est occupé. La disponibilité de l'indicateur permet de conserver le cache historique en mémoire, quelle que soit la fréquence d'accès.

Le deuxième conseil ne fonctionne pas, les indicateurs sont appelés tout le temps, mais à un moment donné, le cache échoue et il devient impossible d'obtenir des données.

Andrey Khatimlianskii2016.03.18 13:41

J'ai résolu le problème avec cette béquille - j'appelle ce code toutes les 150 secondes pour tous les instruments/FTs concernés :

bool CheckTimeSeries( string symbol, ENUM_TIMEFRAMES period )
{
   double array[];
   if ( CopyClose( symbol, period, 1, 1, array ) <= 0 )
   {
                int err = GetLastError();
                Print( " * Can't refresh timeseries (", symbol, ", ", period, ")! ERROR #", err, "!!!" );
                return(false);
   }
   return(true);
}

Fonctionne assez rapidement, l'erreur 4806 semble avoir disparu après cette mise à jour.

 

Veuillez commenter un autre malentendu.

Bars

Renvoie le nombre de barres dans l'historique par le symbole de période correspondant. Il existe 2 variantes de cette fonction.


Seule la deuxième option présente un intérêt.

Demander le nombre de barres sur un intervalle donné
int  Bars(
   string           symbol_name,     // имя символа
   ENUM_TIMEFRAMES  timeframe,       // период
   datetime         start_time,      // с какой даты
   datetime         stop_time        // по какую дату
   );

Texte du conseiller expert

/*******************Expert initialization function*******************/
int OnInit()
{
   return(INIT_SUCCEEDED);
}/*******************************************************************/

/************************Expert tick function************************/
void OnTick()
{
  datetime dtarr[], date = D'2016.06.22';
  ArraySetAsSeries(dtarr, true);
  CopyTime(_Symbol, PERIOD_D1, 0, 5, dtarr);
  Print(dtarr[0]);
  Print(" ", Bars(_Symbol, PERIOD_D1, date, dtarr[0]));
  Print(" ", Bars(_Symbol, PERIOD_D1, date+1, dtarr[0]));
   
}/*******************************************************************/

/******************Expert deinitialization function******************/
void OnDeinit(const int reason)
{
}/*******************************************************************/

Je comprends que le temps 00:00:00 appartient au jour, tout comme le temps 00:00:01

Mais... les imprimés proposés ne sont pas d'accord avec cela.

2016.06.24 22:18:56.450 TestTime (EURUSD,M15)    2
2016.06.24 22:18:56.450 TestTime (EURUSD,M15)    3
2016.06.24 22:18:56.450 TestTime (EURUSD,M15)   2016.06.24 00:00:00

Il s'avère qu'entre le 22.06.2016 00:00:00 et le 24.06.2016 00:00:00 il y a trois barres quotidiennes et qu'entre le 22.06.2016 00:01 et le 24.06.2016 00:00:00 il n'y a que deux...

Ou est-ce que je comprends mal quelque chose ???

Dossiers :
TestTime.mq5  2 kb
 

Et si vous ajoutez une seconde à l'heure de la barre actuelle...

  Print(" ", Bars(_Symbol, PERIOD_D1, date, dtarr[0]+1));
  Print(" ", Bars(_Symbol, PERIOD_D1, date+1, dtarr[0]+1));

vous obtenez ce qui suit

2016.06.24 22:26:48.602 TestTime (EURUSD,M15)    3
2016.06.24 22:26:48.602 TestTime (EURUSD,M15)    4
2016.06.24 22:26:48.602 TestTime (EURUSD,M15)   2016.06.24 00:00:00

L'heure 2016.06.24 00:00:01 semble appartenir à la barre suivante ou quoi ?

 
La limite supérieure de temps n'est pas incluse dans l'intervalle dans lequel le nombre de barres est déterminé.
 
Dmitry Fedoseev:
La limite supérieure de temps n'est pas incluse dans l'intervalle dans lequel le nombre de barres est déterminé.

Dimitri, n'est-ce pas étrange ? Une nouvelle barre est apparue, mais nous ne la compterons pas encore.

Ecoutez, n'est-ce pas la raison d'un tel comportement de la SeriesInfoInteger(_Symbol, PERIOD_D1, SERIES_LASTBAR_DATE) ; ? Une nouvelle barre est apparue, le code disponible en tick est exécuté, mais le temps n'est pas encore pris en compte ???

 

Eh bien, le batteur s'est dégonflé... Et il est passé complètement inaperçu... ?

Vladimir, pouvez-vous au moins répondre à cette question ???

Alexey Viktorov:
Est-ce que CopyRates() tire l'histoire ? Il y a du temps dans la structure... ?
 
Alexey Viktorov:

Eh bien, le croquemitaine s'est dégonflé... Et il a été totalement ignoré...

Vladimir, pouvez-vous au moins répondre à cette question ???

Vous feriez mieux de nous dire ce qu'on vous a conseillé de faire au Service Desk - n'avez-vous pas continué à leur parler là-bas ?