Errores, fallos, preguntas - página 1702

Nuevo comentario
 
Ya veo. Gracias.
 
Dmytro Zelenskyy:

OK, cómo convertir correctamente double a int con el signo intacto (el número no importa, si está fuera del límite entonces limítalo a int)

Convertir a largo.
 
fxsaber:
Responde y ciérralo inmediatamente.

Necesitaba poder borrarme a mí mismo (el indicador) en caso de que hubiera una copia en marcha, aunque con diferentes parámetros de entrada. Para ello, necesitaba descubrir el asa de mi mismo. Lamentablemente, en ese momento no sabía que es imposible en MQL en el 100% de los casos. Por lo tanto, decidí probar un truco no muy inteligente.

He revisado todas las asas. Si coincide con el azar que escribí en mi indicador antes de comprobarlo, significa automáticamente que el mango me pertenece y puedo borrarme, si es necesario.

A partir de estas consideraciones se escribió un código tan inofensivo, que provocó una reacción tan ambigua, pero obviamente negativa, por parte de los desarrolladores. Verás, no puedes hacer eso. ¿Qué has hecho? Bien, leo el valor de mi buffer a través del CopyBuffer. ¿Es ilegal?

No hay nada parecido a "no puedes hacer eso" en la respuesta de los desarrolladores. En ninguna parte dice que sea "ilegal".

Si cree que necesita absolutamente este "código inofensivo", utilícelo. Sólo hay que añadir IndicatorRelease(handle)) a OnCalculate() después de leer el buffer. No hace falta que compruebe en cada tic que es "su" indicador, ¿verdad?

Así es como el indicador resuelve su problema y deja de ser "invisible":

#property indicator_separate_window
#property indicator_buffers 1
#property indicator_plots   1

double Buffer[];

int handle=INVALID_HANDLE;
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnInit()
  {
   ::SetIndexBuffer(0,Buffer,INDICATOR_DATA);
   handle=ChartIndicatorGet(0,1,ChartIndicatorName(0,1,0));
  }

#define  TOSTRING(A) #A + " = " + (string)A + "\n"
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
int OnCalculate(const int rates_total,
                const int prev_calculated,
                const datetime &time[],
                const double &open[],
                const double &high[],
                const double &low[],
                const double &close[],
                const long &tick_volume[],
                const long &volume[],
                const int &spread[])
  {
   if(handle!=INVALID_HANDLE)
     {
      Buffer[rates_total-1]=MathRand();

      double BufferCopy[];

      if(CopyBuffer(handle,0,0,1,BufferCopy)>0)
         Print(TOSTRING(BufferCopy[0])+TOSTRING(Buffer[rates_total-1]));
         
      if(IndicatorRelease(handle)) 
         handle=INVALID_HANDLE;
     }

   return(rates_total);
  }
//+------------------------------------------------------------------+
//|                                                                  |
//+------------------------------------------------------------------+
void OnDeinit(const int Reason)
  {
   if(handle!=INVALID_HANDLE)
      IndicatorRelease(handle);
   return;
  }


Que la comunidad sea consciente de que es posible crear de esta manera una ejecución incontrolada en segundo plano de cualquier código incluso en el terminal sin gráficos. Aquí hay una pequeña puntilla. Considerarlo o no como un error es probablemente una cuestión de terminología. Según tengo entendido, los promotores no pueden cambiar nada de la arquitectura aquí. Por eso hay tanta rabia. No puedo explicar esta reacción de otra manera.

No hay "ira" en la respuesta de los servicedesk. Hay un malentendido sobre su motivación para exagerar regularmente los problemas que encuentra.

Los desarrolladores son capaces de cambiar las cosas. Pero suelen ser muy cuidadosos con las sugerencias de "quitar y prohibir" incluso comportamientos no documentados si no son inequívocamente perjudiciales. Este "hack" es bastante específico, pero quizás alguien lo esté utilizando.

Tal vez todavía se edite el terminal sobre esto, pero ciertamente no es un gran problema y la prioridad de este asunto es mínima.

De todos modos, nadie hablará. Dicho rastrillo quedaría bien reflejado en la Ayuda.

Resulta que sabes muy bien que este "grave fallo" del terminal sólo te interesa a ti.

Cerremos el asunto en este punto. Los detalles técnicos ya se han discutido, mientras que las emociones son innecesarias en este hilo.

 
Anton:

No hay nada como "no está permitido" en la respuesta de los desarrolladores. En ninguna parte dice que sea "ilegal".

Si cree que este "código inofensivo" es absolutamente necesario para usted, utilícelo. Sólo hay que añadir IndicatorRelease(handle)) a OnCalculate() después de leer el buffer. No hace falta que compruebe en cada tic que es "su" indicador, ¿verdad?

No, por supuesto, no es necesario.

Así es como el indicador resuelve su problema y deja de ser "invisible":

Sobre este tema he recibido recientemente una respuesta de su colega

Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias

Errores, fallos, preguntas

Slawa, 2016.09.07 17:17

fxsaber:

¿IndicatorRelease después de iCustom debe hacerse?

¿Para qué?

No lo hagas. Tampoco lo haga después de IndicatorCreate

No tengo respuesta.

Foro sobre trading, sistemas de trading automatizados y pruebas de estrategias de trading

Bichos, errores, preguntas

fxsaber, 2016.09.07 17:27

Después no significa inmediatamente. Pero si no tiene que hacerlo, ¿cuándo debería hacerlo?

No hay "ira" en la respuesta de los servicedesk. Hay un malentendido sobre su motivación para exagerar regularmente los problemas a los que se enfrenta.

La motivación es puramente egoísta. Quiero que todo funcione de forma predecible, según la documentación. Los errores son molestos, ese es el resultado.

Los promotores están en condiciones de cambiar. Pero suelen ser muy cautelosos con las sugerencias de "quitar y prohibir" incluso comportamientos no documentados, a menos que sean claramente perjudiciales. Este "hack" es bastante específico, pero quizás alguien lo esté utilizando.

Es posible que todavía haya ediciones en el terminal sobre esto, pero ciertamente no es un problema gigantesco y la prioridad de este asunto es mínima.

Estoy de acuerdo con lo de la prioridad.

Resulta que eres muy consciente de que este "grave fallo" del terminal sólo te interesa a ti.

Terminemos la pregunta en este punto. Todos los detalles técnicos se discuten, pero las emociones son innecesarias en este hilo.

No, no comentan por otra razón. No importa lo grave que sea el bicho. Mi "seriedad" se refería a los bichos que YA se pueden hacer y poner en el mismo Mercado. Y luego enfrentarse al hecho de que el VPS no tiene suficientes recursos informáticos. De todos modos, ya se entiende la idea.
 
Vladimir Pastushak:

No lo necesito así, estoy tratando de hacer un montón de trabajo para hacer mi vida más fácil en el futuro.

Resolví mi problema de esta manera en el padre todo proteced y la herencia va bajo proteced y luego override.

Si el padre está todo protegido, entonces no hay necesidad de hacer protección-inherencia (se puede dejar público). Pero ahora no está claro lo que querías inicialmente. Si necesitas ocultar los métodos del padre dentro de la clase (no fuera como pensaba), entonces ¿qué tiene que ver la protección? Necesitas una primitiva.
 
Alexey Navoykov:
Sólo que ahora ya no está claro lo que querías originalmente.
Parece que sólo hay que deshacerse de los métodos no disponibles en la lista emergente.
 
Sergei Vladimirov:
Parece que sólo hay que deshacerse de los métodos no disponibles en la lista emergente.
Así que los inaccesibles no aparecen, ¿verdad?
 
Sergei Vladimirov:
Parece que sólo hay que deshacerse de los métodos no disponibles en la lista emergente.

No sólo eso, sino que reescribí las clases de objetos gráficos para mí y a partir de una clase en la que se describen todas las propiedades de los objetos, ahora hago fácil y comprensiblemente (al menos para mí) los descendientes de tipo Botón.

Además, a partir de estos elementos sencillos puedo construir otros más complicados con la mínima probabilidad de error, la máxima rapidez y sencillez (al menos, para mí).

Tal vez me den una patada amistosa y digan que la biblioteca estándar lo tiene todo, pero ya les digo que no es todo y que es todo incomprensible. Estoy acostumbrado a trabajar con lo que entiendo completamente, y para entender cómo funciona todo hay que probarlo todo...

 
Alexey Navoykov:
Así que los inaccesibles no aparecen, ¿verdad?

No, lo hacen.

Por cierto, es lo mismo en el estudio.

 
Sergei Vladimirov:

No, lo hacen.

Entonces Metakvots debería prestar atención a esto. Por qué mostrar los métodos inaccesibles. Después de todo, todo está oculto para la sección protegida como debería ser. Así que debería ser lo mismo aquí.
1...169516961697169816991700170117021703170417051706170717081709...3187
Nuevo comentario