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
Observa, Peter, cómo he implementado un multigradiente de 6 colores.
donde p cambia de 0 a 1.
ZS Pero hay un problema con el color más exterior, que aún no he podido arreglar.
Muy original. ) p es un número arbitrario del usuario, o está ligado a algún parámetro?
¿Para qué sirve esto?
p=p*5;
Después de esta línea p no vuelve al valor inicial.
Aquí:
puedes escribir:
y por qué no utiliza en lugar de
int n=MathRound(p);
?
¿La función ARGB es una función estándar de CCanvas, o es suya?
Sin embargo, hay un fallo en el color más externo, que aún no se ha corregido.
Lo he arreglado:
El código anterior ha sido corregido.
¿La función ARGB es una función propia de CCanvas, o es suya?
ARGB es una definición de CCanvas. Para averiguarlo, haz clic con el puntero del ratón en el nombre y pulsa Alt+G
¿Para qué es esto?
5 es el número de colores -1
y por qué no se utiliza en lugar de
ARGB es una definición de CCanvas. Para averiguarlo, pulse el puntero del ratón sobre el nombre y pulse Alt+G
5 es el número de colores -1
Bien. No estaba criticando, sólo preguntando. Eres genial trabajando con el color.
Eres genial con el color.
Estoy de acuerdo. Pero hay una categoría de usuarios que lo necesitan de forma diferente.
¿Qué pasa si los datos devueltos del indicador kanvas superan los 512? Los topes no ayudarán en este caso. Y los usuarios sólo quieren recibir datos de los indicadores en sus programas. Y no quieren incrustarlas en el cuerpo del Asesor Experto (me ahorraré un búho - que vuele sin cascabeles en el ...). Y quieren recibir datos sobre cualquier barra que se solicite, no sólo sobre las visibles. Y esto está justificado. Y se justifica no sólo por la pereza y el deseo de que todo sea fácil y sencillo, sino también por las exigencias del TS.
Si hablamos de la gran mayoría de usuarios que no son programadores, necesitan el búho o el indicador. No necesitan un indicador para el búho.
Sólo he dado algunos datos para reflexionar, no estoy imponiendo nada. Dejemos que los programadores decidan por sí mismos lo que es conveniente y lo que no. Sin embargo, personalmente no creo que vaya a utilizar la función iCustom en mis EAs.
Tal vez, no estoy del todo bien.
Es bastante lógico suponer que un usuario que compró o descargó un indicador sin lienzo del Mercado querrá utilizar sus datos en su EA.
Entonces lo más razonable para mí sería el intercambio a través de una estructura especialmente creada por el productor de este indicador, que se lee a través de un recurso.
El programador debe cuidar en su indicador kanoval bufferless que esta estructura se mantenga en el recurso al día, y proporcionar al usuario el archivo inclu, en el que esta estructura se lee utilizando los eventos de los usuarios o al llegar cada tick (no es razonable utilizar el temporizador, creo).
Y el usuario sólo tendría que incluir una línea de código #include... y entonces esta estructura estará siempre disponible con los datos reales del indicador.
Sería más conveniente que el uso clásico de iCustom, porque esta estructura puede contener convenientemente variables con nombre y matrices de datos de diferentes tipos (no sólo de tipo doble, como en los buffers del indicador clásico).
Estoy bastante seguro de que los recursos de MQ se implementan de la misma manera que los búferes de los indicadores.
Creo que no estoy del todo bien.
Es bastante lógico suponer que un usuario que compró o descargó tal indicador de canva del Mercado querrá usar sus datos en su EA.
En este caso, lo más razonable para mí sería el intercambio a través de una estructura especialmente creada por el productor de este indicador, que se lee a través de un recurso.
El programador debe cuidar en su indicador canva bufferless que esta estructura se mantenga en el recurso al día, y proporcionar al usuario el archivo inclu que lea esta estructura utilizando los eventos del usuario.
Y el usuario sólo tendría que incluir una línea de código #include... y esta estructura estará siempre disponible con los datos reales del indicador.
Creo que es incluso más conveniente que el uso clásico de iCustom porque puede contener variables y matrices de datos convenientemente nombradas y el usuario no tendrá que preocuparse de lo que significa el número de buffer e incluir sólo una línea de código en su programa para tener un acceso completo y conveniente a los datos del indicador.
Estoy bastante seguro de que los recursos del MQ se implementan de la misma manera que los búferes de los indicadores.
El mecanismo de transferencia de datos a través del propio recurso es extremadamente sencillo. Se trata más bien del método de "comunicación" entre los dos programas. Un programa escribe, el otro programa lee. Por lo tanto, el programa que escribe datos (indicador) en el recurso debe adherirse al formato de mensaje especificado y el programa que lee debe "conocer" este formato. Así, la comunicación entre los programas será universal y eficiente.
El mecanismo de transferencia de datos a través del propio recurso es extremadamente sencillo. Se trata más bien del método de "comunicación" entre los dos programas. Un programa escribe y el otro lee. En consecuencia, el programa que escribe sus datos (indicador) en el recurso debe adherirse al formato del mensaje, y el programa que lee debe "conocer" este formato. Entonces la comunicación será universal y aplicable.
Por supuesto que sí. Al fin y al cabo, la parte de recepción y transmisión la realiza el único desarrollador que ha diseñado el propio indicador.
El mecanismo de compartir a través de un recurso no es tan sencillo. Requiere ciertas habilidades. Eso es lo que veo como ventaja de este método, porque será un privilegio para los programadores más avanzados.
ZS Peter, hace un mes no te parecía que es extremadamente sencillo y necesario. Me alegro de que hayas escuchado y entendido mi mensaje. :))
Pues claro que sí. Al fin y al cabo, la parte de recepción y transmisión está hecha por un solo desarrollador, que ha desarrollado él mismo este indicador.
El mecanismo de intercambio a través del recurso no es tan sencillo. Requiere ciertas habilidades. Eso es lo que veo como ventaja de este método, porque será un privilegio para los programadores más avanzados.
ZS Peter, hace un mes no te parecía que es extremadamente sencillo y necesario. Me alegro de que hayas escuchado y entendido mi mensaje. :))
Sí, Nikolai, los recursos resultaron ser un método muy eficaz de intercambio de datos entre programas, y su uso se basa en las uniones que me comentaste (y Vasiliy también). Así que, gracias a ambos).
El mecanismo en sí de transferir datos a un recurso y leer de él es bastante sencillo, pero el formato de los mensajes es un asunto complicado si se busca la universalidad. Si resolvemos la cuestión para un indicador concreto, todo es sencillo.