Secuencia de ejecución de Init() y DeInit() - página 7
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
Si hay un cambio de marco temporal dentro de un símbolo, el orden de inicialización y desinicialización es en principio predecible. Descargue la última compilación 1580 - hemos corregido algunas cosas allí, ahora los indicadores se eliminan en último lugar, por lo que no debería haber una desiniteración prematura.
Hay indicadores de todas las formas y tamaños. También las frenadas. Y no todas son propias y en código fuente.
Un par de segundos es divertido. La interfaz se siente decenas de milisegundos, la incomodidad aparece inmediatamente.
No lo entiendas mal. No se trata de la interfaz, sino de los transitorios: la conmutación TF. En un gráfico en blanco, ¿el cambio de TF tarda una cantidad de tiempo infinitesimal? No. Entonces los indicadores no tienen nada que ver.
Y lo más importante, no hay respuesta a mi pregunta:
¿En qué situaciones, aparte del trabajo directo con objetos gráficos (sin un nombre TF en el nombre), es importante la secuencia DeInit - Init?
En casi todas las situaciones. A menos, claro, que tratemos con juguetes del tipo MAshek y primitivos similares:
De acuerdo. Los problemas distintos del segundo son solucionables si se conocen. Es decir, ahora debemos meter toda la lógica en OnCalculate, mientras que Init y DeInit no deben utilizarse. ¿Pero para qué los necesitamos entonces?
De todos modos, ahora no estamos hablando de multiplicidad de plataformas. Resulta que MT4 y MT5 tienen diferentes enfoques para Init y DeInit.
Si no se tratara de las finanzas, tal vez no habría tanta discusión.
Y como un asesor de operaciones depende de un indicador u otro, simplemente dejará de funcionar correctamente por un simple cambio de TF. Eso es lo más estresante.
Entonces, ¿cómo puede confiarle sus finanzas?
Puede que estemos en desacuerdo con los desarrolladores de MT en esta cuestión.Hay muchas opciones para resolver este problema. Y casi todas ellas han sido expresadas en este hilo.
1. Si el indicador se escribe usando el Asesor Experto, el Asesor Experto debe ser escrito de tal manera que no se vea afectado por los cambios de período del gráfico. Por lo tanto, el indicador no se reiniciará.
2. Si tiene que eliminar objetos gráficos o cambiar el diseño del gráfico en la desinicialización, compruebe el motivo de la desinicialización.
3. Si el indicador necesita guardar algunos parámetros, entonces, como se ha dicho aquí, no guarde estos datos al desinitar, sino cuando estos datos se preparen o cambien.
4) De dos montones de mierda, elige siempre el que apeste menos. En consecuencia, al elegir entre la velocidad de la que dependen TODOS los indicadores y la complejidad de guardar algunos datos en VARIOS indicadores, elijo la velocidad.
No lo entiendo. Por favor, aclárese. ¿Se garantizará el deinit después del init?
Si el interruptor del marco temporal baja, entonces primero OnInit en el marco temporal inferior (nuevo), y luego OnDeinit en el marco temporal superior (antiguo).
Si el interruptor va hacia arriba, entonces es viceversa. Primero OnDeinit en el marco temporal inferior (antiguo), y luego OnInit en el marco temporal superior (nuevo).
Aquí debemos tener en cuenta que las cachés se procesan de menor a mayor plazo
Descargue la última compilación 1580 - hemos arreglado algunas cosas allí, ahora los indicadores se eliminan en último lugar, por lo que no debería haber ninguna desiniteración prematura.
:(( Oh hombre, eso son "buenas noticias". Ahora puede que tenga que reescribir el código en algunos programas, porque fue diseñado para "al revés" - primero Deunit, luego Unit.
Para ser sinceros, es una lógica extraña. Significa que las copias del indicador antiguo y del nuevo convivirán sin ambigüedades durante algún tiempo, hasta que el primero ejecute la unidad en la copia del indicador nuevo y el segundo, hasta que el último ejecute la unidad en el antiguo. En ese momento no hay posibilidad de informar al nuevo ejemplar sobre alguna información a través de Deunit. Es evidente que esto es un lío. Ya que las unidades suelen ser mucho más engorrosas que las unidades. ¿Por qué una secuencia de ejecución tan extraña? Entonces, este tema se revivirá una y otra vez. Pero si el programador en el indicador podría crear algunas variables que no se reinicien al cambiar el TF, entonces vamos a tratar con esta secuencia de OnInit y OnDeinit. Ya he escrito sobre ello un par de veces(1 y 2). Estoy de acuerdo con la lógica de los desarrolladores, que por razones de seguridad los punteros y referencias no son un lujo para los programadores, pero si se crea un mecanismo de un tipo especial de variables compartidas para todas las copias del indicador, tendremos que crear el mismo mecanismo para todas las copias del indicador. El indicador es el mismo, las propiedades del indicador se almacenan "en algún lugar".
Si el conmutador de plazos baja, primero OnInit en el plazo más bajo (nuevo) y luego OnDeinit en el plazo más alto (antiguo).
Si el interruptor va hacia arriba, entonces es viceversa. Primero OnDeinit en el marco temporal inferior (antiguo), y luego OnInit en el marco temporal superior (nuevo).
Aquí debemos tener en cuenta que las cachés se procesan de menor a mayor
Esto es aún más confuso.
Después de todo, si el indicador no es utilizado por el propio autor, entonces puede cambiar como quiera sin esperar el init y el deinit? ¿Y qué pasará? Y si para una variante de conmutación en deinit es necesario hacer algunas acciones, entonces no hace ninguna diferencia si se escribe para una dirección de conmutación o para ambas direcciones. Pero han añadido frenos para los indicadores "pesados".
Esto es aún más confuso.
Después de todo, si el indicador no es utilizado por el propio autor, entonces puede cambiar como quiera y sin esperar el init y el deinit? ¿Y qué pasará? Y si para una variante del interruptor en deinit es necesario hacer algunas acciones, entonces no hace ninguna diferencia, si se escribe para una dirección del interruptor o para ambas direcciones. Pero han añadido frenos para los indicadores "pesados".
¿Dónde se han añadido los frenos? ¿En comparación con lo que han añadido?
Por favor, apoye sus afirmaciones con código, para que todos puedan reproducirlo.
Una vez más. Dado que se crea otra copia del indicador al cambiarel período del símbolo, el orden de OnInit en el nuevo período del símbolo y OnDeinit en el antiguo período del símbolo es indefinido
¿Dónde se han añadido los frenos? ¿En comparación con lo que ha añadido?
Tenga la amabilidad de respaldar sus afirmaciones con código para que todos puedan reproducirlas
Una vez más. Dado que se crea otra copiadel indicador al cambiar un período de símbolo, el orden de ejecución de OnInit en el nuevo período de símbolo y OnDeinit en el antiguo período de símbolo es indefinido
En este mensaje
Si la conmutación de los marcos temporales se reduce, entonces primero OnInit en el marco temporal más joven (nuevo), y luego OnDeinit en el marco temporal más antiguo (viejo).
Si el interruptor va hacia arriba, entonces es viceversa. Primero OnDeinit en el marco temporal inferior (más antiguo), y luego OnInit en el marco temporal superior (más reciente).
Hay que tener en cuenta que las memorias caché se procesan desde un marco temporal de bajo orden hasta uno de alto orden.
¿Lo has contado tal cual o como lo hiciste al preparar la nueva construcción?
Si es así, entonces me he equivocado y lo retiro.
En este mensaje.
¿Ha dicho como está o como se prepara una nueva construcción?
Si como es, lo entendí mal y lo retiro.
Esto se hace en la compilación 1580.
Antes, la desinicialización en el cambio de marco temporal era casi siempre anterior. Pero sólo si el interruptor horario cae, la desinicialización se hizo con el código 1, no con el 3, como debería ser
Esto se hace en la compilación 1580
Antes, la desinicialización al cambiar de marco temporal era casi siempre antes. Pero sólo si el interruptor horario cae, la desinicialización se hizo con el código 1 y no con el 3 como debería ser
Entonces, ¿cómo procesar estos códigos de desinicialización en Inite del indicador, qué hacen estos códigos? Como no existe la posibilidad de esperar en el indicador, el sueño no funciona.