Errores, fallos, preguntas - página 570

[Rashid Umarov]

Vea las propiedades del programa (#propiedad):

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

[Konstantin Chernov]

Rosh:

Vea las propiedades del programa (#propiedad):

Gracias.

[gumgum]

En el gráfico de ticks (en la visión general del mercado) en la cuenta demo XAUUSD hay un reajuste constante.

También:

Abre "detalles" y pasa el ratón por encima del espacio vacío

[Alexey Da]

gumgum:

En el gráfico de ticks (en la visión general del mercado) en la cuenta demo XAUUSD hay un reajuste constante.

También:

Abrir "detalles" y pasar el ratón sobre el espacio vacío

No estoy muy seguro de lo que significa un reinicio permanente.

¿Qué sistema operativo, qué sistema operativo y qué capacidad del terminal?

[x572intraday]

Rosh:

Aprenda, ya que dice en la redacción de la documentación - Indicadores técnicos:

Significa que en el primer inicio del indicador (cuando se cambia a un nuevo marco temporal por primera vez), los valores del indicador no se han calculado todavía, por lo que prev_calculated=0. Cuando se vuelve a este marco temporal, el indicador no se crea de nuevo, ya que su asa sigue viva. Por lo tanto, ¡previo_calculado!=0

Estaba a punto de tomarle la palabra, pero he cambiado de opinión. Los resultados que obtuve exteriormente casi dicen que no siempre todo es tan suave, hay algunas excepciones... pero sigo sin entender si ellas, estas excepciones, están relacionadas con las asas o es algún otro inconveniente?

" Nota: si la función OnCalculate devuelve un valor nulo, los valores del indicador no se muestran en la DataWindow del terminal cliente. "Me apresuro a asegurar que es mucho peor, si he conseguido relacionar correctamente los resultados en mi cabeza con la documentación e interpretar yo mismo el efecto resultante. No sólo no se muestran los valores del indicador, sino que todo el indicador deja de funcionar, la cola de comandos se congela y no se puede esperar a que se procesen los siguientes comandos. De hecho, esto es lo que he conseguido vislumbrar en algunos de mis posts anteriores.

Como ya se ha mencionado, el código tiene un montón de copias... que no utiliza ningún handle (es decir, todos excepto CopyBuffer). Si el resultado de la copia <= 0, obtenemos el return(0), tras lo cual"el indicador dejó de funcionar" y el indicador se paraliza por completo.

Quiero recordar que el no-dibujo inicial, con la parálisis que conlleva, se produce en el modo sin ventana del terminal (es decir, en fin de semana o sin conexión). No lo consideres poco importante, porque nadie quiere depurar sus indicadores los fines de semana, haciendo gestos innecesarios, recorriendo los plazos y iniciando artificialmente -de forma manual- el primer dibujo. Y no se trata sólo de depurar.

Honestamente, no tenía suficiente mente para vincular los enlaces amablemente proporcionados a los ejemplos de la documentación, donde dice sobre el aumento de contador de referencia a la manija ya existente (así como con otras respuestas dadas) al problema existente. No creo que crezca desde ahí en absoluto.

Intente reproducir el código adjunto en las siguientes condiciones: el plazo preestablecido en el código es D1, el plazo actual en el terminal es D1, el terminal está en modo offline. Cuando el indicador se adjunta al gráfico con el marco temporal actual especificado, los resultados del registro aparecerán instantáneamente en la pestaña Expertos.

Ahora descargue completamente el terminal, reinícielo y cambie a un marco temporal distinto de D1 . Ponga el indicador - no cambiará hasta que cambie a cualquier otro marco temporal (no necesariamente D1).

Debido a esta desagradable característica, una buena idea desaparece junto con el indicador suscrito.

Los desarrolladores, estoy seguro, pueden encontrar explicaciones para este comportamiento del indicador, pero es injusto, cuando los datos de TF definidos en su mango se muestran perfectamente, cuando un usuario está en ese marco de tiempo, pero si está en otro, tiene que hacer movimientos innecesarios. Estoy a favor de la igualdad de plazos cuando se utilizan asas de indicadores externos, los otros TFs no son culpables de nada.

P.D.: Así que... Espera. Lo he comprobado una vez más - resulta que CopyHigh ni siquiera influye en esta parálisis. Ahora no entiendo nada de nada. Todas mis sospechas cayeron de repente sobre un asa en OnInit...

P.P.S.: añadido el segundo ejemplo de código - incluso no responde.

[x572intraday]

Se ha encontrado el límite del problema.

Coméntalo:

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

- y el problema desaparece, pero entonces es un claro indicio de que ocasionalmente la unión del buffer es incorrecta a través de SetIndexBuffer . Y eso ya apunta a la necesidad de abandonar el uso deSetIndexBuffer y recurrir a la manipulación manual del tamaño del buffer que se está monitorizando.

Además, el ejemplo adjunto demuestra obviamente la incapacidad de BarsCalculated(handle )para calcular en el tiempo los valores del indicador llamado en cualquier TF actual, a no ser que coincida con uno preestablecido, o la falta de voluntad en principio para calcular nada a la primera (muy probablemente esta variante). En este caso el valor será <=0, return(0) y stop como resultado.

[gumgum]

alexvd:

No está muy claro qué significa el reinicio permanente.

¿Qué sistema operativo, qué sistema operativo y qué bit de terminal?

W7 y MT5 64 bit.

ejemplo:

XAUUSD siempre se reinicia al principio (XAGUSD es una comparación)

[Rashid Umarov]

x100intraday:

Encuentra el límite del problema.

Coméntalo:

- y el problema desaparecerá, pero entonces será un claro indicio de que la vinculación del búfer a través de SetIndexBuffer es ocasionalmente incorrecta. Y eso ya apunta a la necesidad de abandonar el uso de SetIndexBuffer y recurrir a la manipulación manual del tamaño del buffer que se está monitorizando.

Además, el ejemplo adjunto demuestra obviamente la incapacidad de BarsCalculated(handle) para calcular en el tiempo el valor del indicador llamado en cualquier TF actual, a menos que coincida con uno preestablecido. En este caso el valor será <=0, return(0) y stop como resultado.

Para el primer ejemplo (no miré el segundo), el indicador paralich tiene una función

//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
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);
  }

Así que, imagina que tu indicador está en D1 y tratas de copiar los datos del marco de tiempo H1 a su buffer de indicador. El número de elementos no coincidirá. Creo que aquí es donde radica tu problema: no hay ninguna comprobación antes de copiar los datos.

En la ayuda de cada indicador técnico hay ejemplos de indicadores que toman datos de otros plazos. Por ejemplo, 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:

Intente reproducir el código adjunto en las siguientes condiciones: el plazo preestablecido en el código es D1, el plazo actual en el terminal es D1, el terminal está en modo off-line. Cuando se adjunta un indicador a un gráfico con el marco temporal actual especificado, los resultados del registro aparecerán instantáneamente en la pestaña Expertos.

Y en general, ¿has probado a utilizar la depuración en lugar del registro, para no recibir toneladas de mensajes? Ayuda en el MetaEditor → Desarrollo de programas → Depuración

[x572intraday]

Rosh:

Así que imagina que tu indicador está en D1 y estás tratando de copiar los datos del marco de tiempo H1 en su búfer de indicador. El número de elementos no coincidirá. Creo que aquí es donde radica tu problema: no hay ninguna comprobación antes de copiar los datos.

En primer lugar voy a aclarar: ¿los casos de desbordamiento de arrays al copiar valores a través de las funciones Copy... no provocan un error de desbordamiento"Array out of range" en Experts del terminal cliente? Recuerdo que estos mensajes se generan a veces después de una compilación exitosa, mientras el indicador está funcionando, pero no puedo decirlo con exactitud. Creo que no es en la función Copy...-, sino en una referencia a un índice inexistente o algo así.

En segundo lugar, me apresuro a asegurarle que su hipótesis sobre la ausencia de control no es del todo correcta. Puede hablar sólo de un filtro if-else generado incorrectamente, pero no de su completa ausencia. He tropezado con él más de una docena de veces. Recientemente he preguntado aquí o en "Dummies" una pregunta sobre el análogo de rates_total para los plazos, diferentes del actual, pero no he recibido respuesta de nadie. El asunto es que rates_total es uno de los parámetros para el timeframe actual, y es absolutamente inútil para mí, porque trabajo con muchos otros timeframes, y si paso a usar uno de los preestablecidos, sigo usando universal calculated=BarsCalculated(handle) para los cálculos en lugar de rates_total. Tal vez esté cometiendo un gran error, pero no veo la utilidad de rates_total para esta tarea.

En tercer lugar, hace tiempo que he conseguido que, estando en una TF alta, pueda copiar y redistribuir con éxito valores de TFs inferiores, y viceversa. Los ejemplos que puse hace unos días son mínimos pero exhaustivos, está todo ahí. La discrepancia entre las cantidades de dos TF diferentes puede ser de dos tipos: escasez y exceso. El primer caso no es terrible, pero comprobaré el segundo para ver si hay desbordamiento e intentaré limitarlo, si es que algo va mal. Pero también se bloquea si las barras copiadas de otro marco temporal son menores que el número de barras del actual.

En cuarto lugar, el indicador ha sido horneado y verificado durante una semana ya, no ha mostrado ningún error obvio (ni en la compilación ni durante la operación), sólo hay algunos problemas implícitos, uno de los cuales es la no-dibujo inicial de las barras en ciertos TFs y el fuerte aumento del tiempo de cálculo en M1 cuando se vuelve a cambiar a ella (durante la primera vez todo se calcula dentro de 2-3 segundos). El indicador parece atascarse en los cálculos (¿fuga de memoria en avalancha?) He limitado el número de elementos copiados usando CopyBuffer - a 200 en lugar de todo el historial, pero no ha cambiado la situación. He notado, que fuera de línea en M1 y en todos los demás lugares el cálculo es siempre rápido, como por primera vez, en línea la situación cambia dramáticamente (probablemente, el problema está en ese mismo filtro, que se salta algo en cada tick, aunque no debería ser, porque la frecuencia de redibujado depende de redibujar una nueva barra cero y no puede ser anterior al TF más joven preestablecido en uno de los mangos). Pequeños pero desagradables problemas: al menor intento de desplazar el gráfico con la rueda del ratón se desmaterializan todos los fractales y hay que esperar a que se recalculen y dibujen (aunque no han llegado nuevas barras, parece que no hay nada que recalcular).