Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Esto parece una tontería. Los temporizadores de copia de indicadores no tienen nada que ver entre sí.
Hace 500 años, la afirmación de que la Tierra es esférica también sonaba como una tontería para la mayoría de la gente.
Bien, ahora voy a rehacer este ejemplo para un temporizador.
Ok, ahora voy a rehacer este ejemplo para el temporizador.
Donde no hay ambigüedad.
Prueba este ejemplo primitivo. Comprenderá la "singularidad" al cambiar el TF.
En este ejemplo, en OnInit se crea un objeto con las coordenadas de la hora y el precio actuales. En OnCalculate este objeto se mueve junto con el precio.
En OnDeinit simplemente se borra (lógicamente).
Al cambiar el TF, resulta que el objeto aparece y luego desaparece.
¿Por qué ocurre esto?
Porque a veces el OnDeinit del antiguo TF borra lo que ya se ha creado en el OnInit del nuevo TF. No es un error. ¿Qué debe pensar el programador que creó este ejemplo y no leyó esta rama?
¿Quieres mostrar que el EvenKillTimer en el estado antiguo deinit afectará al EventSetTimer en el nuevo init?
Me equivoqué. Mis disculpas. Error mío.
Efectivamente, el temporizador del nuevo TF resultó ser elEventKillTimer del antiguo TF, que no se puede matar. :)
En tu ejemplo, el objeto gráfico está presente en todos los TFs, sólo tienes que hacer zoom para verlo.
No, no lo es. A veces se elimina por la Deunit de la antigua TF.
De hecho, el temporizador del nuevo TF resultó ser resistente, no matable por el EventKillTimer del antiguo TF. :)
No, no lo es. A veces es borrado por el Deinit de la antigua TF.
Para forzar la actualización de los objetos gráficos, utilice el comando ChartRedraw() para redibujar el gráfico.
Añade esto a Init y Deinit:
ChartRedraw();
Añadir esto a Init y Deinit:ChartRedraw();
Lo he probado. Esto no cambia la situación, y no puede cambiar, si el objeto ya ha sido eliminado,ChartRedraw() no lo resucitará.
No excluyo, Sergey, que esta "peculiaridad" de la ambigüedad de la secuencia de ejecución de OnInit del nuevo TF y OnDeinit del antiguo TF pueda depender de la plancha. Ya que diferentes hilos, diferentes procesadores con diferente arquitectura de coprocesador - es todo complicado y no soy bueno en ello. Pero el hecho de que esta "característica" aparezca en mi ordenador y en el de otros, a juzgar por este hilo, es cierto.
Entonces, ¿quieres decir que has probado este ejemplo en tu ordenador y cuando cambias de TF siempre ves el objeto?
Por cierto, me he dado cuenta de que si aumentas los candelabros al máximo tamaño, es decir, la pantalla tiene un número mínimo de barras, es muy difícil hacer desaparecer el objeto. Tuve que cambiar el TF 30 veces para eliminar el objeto (es decir, DeUnit se activó más tarde que Unit). Al parecer, esta "peculiaridad" se ve afectada por el rendimiento de los hilos. Esto es como una hipótesis o un pensamiento en voz alta.
Me alegro mucho de que mi delirio haya resultado ser un delirio.
:) No era un delirio, sólo una hipótesis.
Gracias por la hipótesis. Gracias a él y afxsaber tuve una nueva ronda de concienciación de lo que es un indicador de copia. El temporizador simplemente pertenece a esa copia y muere junto con ella, incluso cuando el TF cambia. Pero los objetos viven por sí mismos, aunque sean creados por una copia del indicador, sólo pertenecen a la ventana. Ahora entiendo que no tiene sentido escribirEventKillTimer en la Deunit, de todos modos, el temporizador morirá si la Deunit ya ha sido llamada.
Es decir, todo el problema es añadir UNA línea al principio de cualquier indicador.
Código de la biblioteca