Secuencia de ejecución de Init() y DeInit() - página 24

Nuevo comentario
 
fxsaber:
El ejemplo que has reelaborado no se ajustaba perfectamente al problema planteado. Puede mostrar otro ejemplo que no tendrá solución a través de UninitializeReason.

Eso es todo, doy por terminado este diálogo. ¿Qué sentido tiene discutir las formas de rascarse la oreja? Si no hay otra solución, puede utilizar su código, pero la universalidad no es siempre la solución ideal.

Por ejemplo, a nadie se le ocurriría llamar a un leñador para cortar un arbusto de frambuesas. Así que su código es comparable a una cuadrilla de leñadores para cortar un arbusto de frambuesas.

Saludos Alexei.

 
No entiendo, si el antiguo DeInit y el nuevo OnInit se ejecutan en hilos diferentes, cuál es el problema de que OnInit se limite a esperar a que ocurra el DeInit y termine. Utilizar una variable global como semáforo.
 
Aleksei Radchenko:
No entiendo, si el antiguo DeInit y el nuevo OnInit se ejecutan en hilos diferentes, cuál es el problema de que OnInit se limite a esperar a que ocurra el DeInit y termine. Utilizar una variable global como semáforo.
En un solo gráfico, todos los indicadores sólo se ejecutan en un hilo.
 
Alexey Viktorov:

¿Qué sentido tiene utilizar un ejemplo primitivo de dos bits?

Utiliza un ejemplo de código casi correcto en su lugar.

Alexey, este ejemplo fue creado para que incluso un perdedor pudiera entenderlo. Por eso escribí que es primitivo. Lo siento, no se diseñó para los sobresalientes.

Esta mañana vi a un perrito ladrando a los camiones que pasaban. Le envía su amor.

 
Nikolai Semko:

Alexei, este ejemplo fue creado para que incluso los que no tienen éxito puedan entenderlo. Por eso escribí que era primitivo. Lo siento, no se diseñó para los sobresalientes.

Esta mañana vi a un perro ladrando a los camiones que pasaban. Le envía su amor.

¿Estabas ladrando con ella?

¿Qué se puede entender del ejemplo en el que no se comprueba la existencia del objeto antes de su creación? ¿Reclamos contra los desarrolladores que no han hecho posible escribir de ninguna manera, con errores groseros? Escribiré como quiera y los desarrolladores deben proporcionarme todas las condiciones para ello. Los desarrolladores tienen que prever todos los posibles errores que pueda cometer en el futuro. ¿Es eso? No saques el problema de donde no existe.

 
Alexey Viktorov:

¿Qué se puede entender del ejemplo en el que no se comprueba un objeto antes de su creación? ¿Reclamos contra los desarrolladores que no hicieron posible escribir a su antojo, con errores groseros?


Alexey, parece que estás completamente fuera de onda. Lea las fuentes primarias, por favor.
He aquí una cita:" Si un objeto ha sido creado anteriormente, se intenta cambiar sus coordenadas. "

Entiendo que es una buena forma en las grandes obras de poner controles de varios tipos. Pero en este caso esta comprobación no tiene sentido. Porque si no hay objeto, ObjectCreate lo creará, y si lo hay, simplemente cambiará sus coordenadas. En este ejemplo tan primitivo, el objetivo era mostrar el hecho de borrar un objeto por Deunit de TF antiguo, lo que demuestra perfectamente.
Su "atropello" no es nada. Lo más probable es que sea un intento de llamar la atención.
Y si quieres líneas de código superfluas, sin ningún sentido, para entrenar tus dedos, te recomiendo un excelente recurso "Keyboard Solo".

 
Alexey Viktorov:

¿Estabas saltando con ella?

¿Qué puedes entender del ejemplo en el que no se comprueba un objeto antes de su creación? ¿Reclamos contra los desarrolladores por no haber hecho posible escribir lo que se quiera con burdos errores? Escribiré como quiera y los desarrolladores deben proporcionarme todas las condiciones para ello. Los desarrolladores tienen que prever todos los posibles errores que pueda cometer en el futuro. ¿Es eso? No saques el problema de donde no existe.


¿Qué tiene de terrible intentar crear un objeto existente? ¿Desaparecerá?
 
Dmitry Fedoseev:

¿Qué es lo terrible que ocurriría si intentamos crear un objeto existente? ¿Desaparecerá?

Dimitri me parece que eres un programador educado. ¿No te han enseñado las reglas de etiqueta en la programación?

Para el resto puedes escribir como en el viejo mql4 con la posibilidad de desbordamiento de arrays y otros supuestos. Se obtiene un error en la respuesta... Bueno, vuelve a marcarlo... Sigamos, no tenemos tiempo... Y luego nos encontramos con un problema que no vale nada en un lenguaje más estricto y empezamos a quejarnos a los desarrolladores...

Cristo ha resucitado.

 
Nikolai Semko:


... El propósito de este ejemplo tan primitivo era mostrar el hecho de que Deunit eliminó el objeto de la antigua TF, lo que demuestra perfectamente ...

El hecho del fracaso se muestra en el contraejemplo. No hay que sacar el problema de donde no existe. Poner un check en el motivo de desinicialización y el objeto no se borra, sólo cambia sus coordenadas.
 
Alexey Viktorov:
El hecho del fracaso se muestra en el ejemplo de respuesta. No es necesario sacar el problema de donde no lo hay. Se comprueba el motivo de la desinicialización y el objeto no se borra, sólo cambia sus coordenadas.
//Часть твоего кода:
void OnDeinit(const int reason)
  {
   if(UninitializeReason() != REASON_CHARTCHANGE)      // Что ты здесь сделал? - ЕСЛИ ПРОИСХОДИТ СМЕНА ТФ, ТО НИЧЕГО НЕ ДЕЛАЕМ. Бред! 
                                                       // И зачем здесь использовать функцию UninitializeReason(), когда можно уже существует переменная  reason?
    {
     ObjectDelete(0,"InitDeinit");
     ChartRedraw(0);                                   // Не нужная функция в данном случае, т.к. она обычно применяется после изменении свойств объктов. Объект удалится и так. 
     Print(__FUNCTION__, "  InitDeinit удалён");       // А где ж твоя любимая проверка, вдруг не удален.
    }
  }

Mi ejemplo fue creado para mostrar el problema de una secuencia ambigua de la Unidad de la nueva TF y la Unidad de la antigua TF, no como una solución.

Sólo has evitado el problema, no lo has resuelto.
En mi ejemplo, sólo es importante que en la Unidad del antiguo TF el objeto se borre en cualquier caso, incluso cuando se cambie el TF, y en la Unidad del nuevo objeto se cree de nuevo.

Si la secuencia es primero Deunit de la antigua TF, luego Unit de la nueva TF, como debería ser lógicamente. A continuación, el objeto se borra y se vuelve a crear.

Si la secuencia es primero la Unidad de la nueva TF y luego la Deunidad de la antigua TF, entonces el objeto simplemente se modifica cuando se intenta crear en la Unidad, porque aún no se ha borrado. Y luego es borrado por la Deunit de la antigua TF. Este es el error.

Ese era el objetivo de este ejemplo: mostrar lo que puede encontrar cualquier programador que no haya leído esta rama y no conozca esta "característica".
Este ejemplo no pretende ser una solución. Como variantes de la solución se presentan aquí y aquí. Creo que también añadiré una solución más adelante, pero sin usar variables globales y archivos del terminal y para que esta solución funcione aunque se pongan varios indicadores idénticos en una ventana. ¿Ha intentado resolver este problema? O sólo eres capaz de encontrar errores en el código de los demás, sobre todo cuando no los hay.

¡No seas más estúpido!

1...171819202122232425262728
Nuevo comentario