El lienzo es genial. - página 55
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 te acuerdas de Borland, la interfaz gráfica de usuario se montaba en un editor visual, la disposición de los controles se colocaba en una barra de herramientas, y luego se escribían los manejadores.
Si ME tuviera una función gráfica de este tipo para construir diseños en modo visual, facilitaría mucho la construcción de aplicaciones gráficas.
Como la mayoría de los programadores modernos, que estudiaron la construcción de GUI, se acostumbraron (así se les enseñó) al editor visual de GUI,
Y construir un diseño de una aplicación gráfica en código de estilo C puro es de poco interés para ellos. Dado que ya es de estilo C duro.
Necesitamos un editor visual para construir una aplicación gráfica, y entonces la gente estará ansiosa por aprenderlo, y aquellos que trabajaron en VS o RadStudio, incluso dominan rápidamente el editor visual.
En este caso, ya existía un prototipo de dicho editor visual en MQL. Sin embargo, la gente se opuso con vehemencia. Dijeron que no era necesario en el comercio.
En general, desmoralizaban como podían. Por lo tanto, no sé lo que realmente necesita la comunidad.
Apoyo totalmente la necesidad de tener la capacidad de recoger...
Pero si es necesario o no es otra cuestión.
Me pregunto si los propios desarrolladores ven el terminal como una herramienta de comercio o de programación.
Puede que me equivoque a estas alturas, pero siempre he pensado que ME está diseñado para implementar exactamente la funcionalidad que el usuario necesita para operar. ¡Exactamente el comercio!
Pero hoy en día la profundidad de la programación en ME se ha adentrado en áreas en las que realmente hay que ser capaz de "construir" dados y tener un conocimiento muy serio de la programación....
¿Y a qué conduce esto al final? Esto lleva a que las herramientas de negociación avanzadas estén disponibles sólo para los programadores experimentados.
Es decir, si no eres programador, no tienes nada que hacer en el comercio... Pero esto es absurdo.
ME es sólo un asistente para rellenar la funcionalidad que falta, que habría sido más correctamente incorporado en el propio terminal (diferentes asistentes).
Y, de hecho, ME está evolucionando como un nuevo entorno de desarrollo que requiere cada vez más conocimientos por parte de los usuarios.
Partiendo de esta conclusión, las herramientas de visualización son necesarias, pero su uso debe estar al alcance de los usuarios que no tienen conocimientos profundos de programación.
Sólo que en este caso tendrán demanda.
Esta es sólo mi opinión y no la impongo a nadie.
Si se considera la clase CCanvas, hay unas 20 funciones de dibujo de primitivas gráficas. Supongamos que un usuario las conoce todas y conoce las reglas y la sintaxis de la POO. Sin embargo, es demasiado poco hasta la más simple visualización de sus datos. Por no hablar de la creación del control más sencillo: un botón. Es decir, es relativamente fácil dibujar primitivas en el lienzo, pero utilizar estas primitivas en la creación de una visualización o GUI es mucho más difícil. Y no se puede hacer aquí sin conocimiento, no se puede hacer aquí sin el talento del desarrollador. Pero, ¿cuántas personas lo tienen? Ese es el problema principal.
Para utilizar el potencial de la clase Kanvas es necesario poder combinar las primitivas gráficas en objetos más complejos (controles), vincular su funcionamiento con el modelo dirigido por eventos, escribir las relaciones con funciones... O bien, convertir datos numéricos en diferentes curvas gráficas... Este es un trabajo para usuarios con talento y muy trabajadores. De hecho, no los usuarios, sino los desarrolladores.
En este caso, ya existía un prototipo de dicho editor visual en MQL. Sin embargo, la gente se opuso con vehemencia. Dijeron que no era necesario en el comercio.
En general, desmoralizaban como podían. Por lo tanto, no sé lo que realmente necesita la comunidad.
Vaya, así que hay un prototipo.
Así que tal vez los desarrolladores deberían reconsiderar las opiniones superficiales de la comunidad. Y reactivar el plan para desarrollar un modo visual.
Es un poco raro, por supuesto, desmoralizar una característica esencialmente muy buscada.
Ahora hay muy pocos sitios donde enseñan a construir una GUI en estilo C, si es que lo enseñan todavía.
Ahora todo el mundo está enseñado a trabajar en IDE con el modo visual, y desde que MT5 ha ido más allá de sólo la plataforma de comercio
, el modo visual de la construcción de aplicaciones gráficas estaría en gran demanda.
Sinceramente, me sorprende que los desarrolladores hayan escuchado a los miopes que estaban en contra.
Si consideramos la clase CCanvas, hay unas 20 funciones para dibujar primitivas gráficas. Supongamos que el usuario las conoce todas y conoce las reglas y la sintaxis de la POO. Sin embargo, hasta la más simple visualización de sus datos - es demasiado poco. Por no hablar de la creación del control más sencillo: un botón. Es decir, es relativamente fácil dibujar primitivas en el lienzo, pero utilizar estas primitivas en la creación de una visualización o GUI es mucho más difícil. Y no se puede hacer aquí sin conocimiento, no se puede hacer aquí sin el talento del desarrollador. Pero, ¿cuántas personas lo tienen? Ese es el problema principal.
Para utilizar el potencial de la clase Kanvas es necesario poder combinar las primitivas gráficas en objetos más complejos (controles), vincular su funcionamiento con el modelo dirigido por eventos, escribir las relaciones con funciones... O bien, convertir los datos digitales en diferentes curvas gráficas... Este es un trabajo para usuarios con talento y muy trabajadores. De hecho, no los usuarios, sino los desarrolladores.
Peter, ¡dices las palabras correctas!
Así que abogo por la creación de tales bibliotecas que sean intuitivamente comprensibles para los programadores que no están familiarizados con la POO también.
Y esto se aplica no sólo a la interfaz gráfica de usuario.
En la biblioteca estándar y en la biblioteca de Anatoly, ¡se necesitaría mucho esfuerzo para construir un simple formulario! De verdad. Un paso a la derecha o a la izquierda de los ejemplos y ya está, nada funciona, hay que entender todos los detalles.
En todos los idiomas, por supuesto, la interfaz gráfica de usuario también se basa en las bibliotecas, pero hay un PERO importante. Hay un conjunto inicial de controles, que en el nivel central de la biblioteca están completamente "atados", todos los manejadores de eventos básicos están "cableados", todo lo que queda es suscribirse a ellos si se quiere cambiar el comportamiento o la presentación.
En esencia, la arquitectura de la biblioteca estándar está muy bien pensada y podría utilizarse como base para una biblioteca más avanzada.
Wah, así que hay un prototipo disponible.
Así que tal vez los desarrolladores deberían reconsiderar las opiniones superficiales de la comunidad. Y reactivar el plan para desarrollar un modo visual.
Es extraño, por supuesto, que hayan desmoralizado una característica esencialmente muy buscada.
Al fin y al cabo, son pocos los lugares en los que se enseña a construir una interfaz gráfica en C, si es que todavía se enseña.
Ahora enseñan a trabajar en IDE con el modo visual, y como MT5 ya no es sólo una plataforma de trading,
entonces el modo visual de construir aplicaciones gráficas sería muy demandado.
Para ser sincero, me sorprende que los desarrolladores hayan escuchado a los miopes que estaban en contra.
Hay algunos otros factores sorprendentes: los indicadores son 100% visuales, los EAs son 80% visuales y los scripts son 20% visuales. Hay visualidad en todo y la comprensión de esto está en la superficie. Sin embargo, hay un desarrollo en la integración con otros entornos de desarrollo, y lo que está en la superficie....
Al parecer, todos los demás usuarios de la terminal piden python y sql.
Roman, Peter, Nikolai... los desarrolladores del terminal tienen su propia visión, son los autores y propietarios del producto de software. Supongo que el desarrollo de la funcionalidad de ME y del terminal en su conjunto se basa en un estudio de mercado.
Pero nadie nos impide hablar :)
Hay algunos otros factores sorprendentes: los indicadores son 100% visuales, los EAs son 80% visuales y los scripts son 20% visuales. Como quiera llamarlo, todo es visual y la comprensión de esto está en la superficie. Sin embargo, hay un desarrollo en la integración con otros entornos de desarrollo, y lo que está en la superficie....
Al parecer, todos los usuarios de terminales preguntan por python y sql.
Roman, Peter, Nikolay... Los desarrolladores del terminal tienen su propia visión, son los autores y propietarios del producto de software. Creo que el desarrollo de la funcionalidad de ME y del terminal en general se basa en la investigación de mercado.
Pero nadie nos impide hablar :)
Así es.
Mi opinión es: la interfaz visual de los EAs permitirá acumular estrategias en una sola aplicación, lo que afectará negativamente a las ventas en el mercado. Si todo el mundo puede crear fácilmente Asesores Expertos con un conjunto dinámico de estrategias (la GUI lo permite), su rotación actual en el Mercado bajará, lo que afectará a las ventas. Los Asesores Expertos que integran y modifican las estrategias internamente pasarán a primer plano y eliminarán los clones que sólo difieren en la configuración o en unas pocas condiciones. ¿Será esto bueno para el mercado? No lo sé. Pero el nivel de los Asesores Expertos aumentará y será mucho más interesante examinarlos en el escaparate.
Tal vez la mayoría de los usuarios quieran que CCanvas, CGrafic y CCanvas3D sean aplicaciones que produzcan las visualizaciones requeridas, en lugar de clases que requieran conocimientos de principios y sintaxis de POO. Y no sólo para conocer, sino esencialmente para construir su propio sistema de visualización, como hace Nicholas.
¿Cuál es el principio de la oop que hay que conocer? ¿Poner un punto y elegir un método de la lista?
Una pregunta complementaria: ¿cuántas y cuáles de las funciones MQL "más potentes" y "más sencillas"
es suficiente para escribir un Asesor Experto completamente funcional y potencialmente el más rentable para cualquier
de los principales pares de divisas del mundo?
¿Y qué función de R o Python, que aquí todo el mundo ha perdido la cabeza, es suficiente para escribir...? Y mira, el taburete en el que estás sentado, ¿es adecuado para eso?
Bueno, si te acuerdas de Borland, la GUI se montaba en un editor visual, ponías la disposición de los controles en el panel y luego escribías los manejadores.
Si ME dispusiera de esa capacidad gráfica para construir diseños de forma visual, simplificaría enormemente la construcción de aplicaciones gráficas.
Como la mayoría de los programadores modernos, que estudiaron la construcción de GUI, se acostumbraron (así se les enseñó) al editor visual de GUI,
Y construir un diseño de una aplicación gráfica en código de estilo C puro es de poco interés para ellos. Dado que ya es de estilo C duro.
Necesitamos un editor visual para construir una aplicación gráfica, y entonces la gente estará ansiosa por aprenderlo, y aquellos que trabajaron en VS o RadStudio, incluso dominan rápidamente el editor visual.
¿Por qué son necesarios aquí?
Así es.
Mi opinión es: la interfaz visual de los EAs permitirá acumular estrategias en una sola aplicación, lo que afectará negativamente a las ventas del Mercado. Si todo el mundo puede crear fácilmente Asesores Expertos con un conjunto dinámico de estrategias (la GUI lo permite), su rotación actual en el Mercado bajará, lo que afectará a las ventas. Los Asesores Expertos que integran y modifican las estrategias internamente pasarán a primer plano y eliminarán los clones que sólo difieren en la configuración o en unas pocas condiciones. ¿Será bueno para el mercado? No lo sé. Pero, el nivel de los EAs crecerá y será mucho más interesante verlos en el escaparate.
Un problema absolutamente inverosímil.
La interfaz visual para la recopilación de estrategias es innecesaria, si necesitas dados, ve a tslab.
Y he visto programas para generar código mql que recogen estrategias con cubos en modo visual.
No necesitamos el modo visual para el desarrollo de estrategias e indicadores de trading, es realmente innecesario.
Pero para las aplicaciones gráficas modulares, el modo visual, como has mostrado en el gif, sería útil.