Creación de una interfaz gráfica para los MQL en modo gráfico. - página 10
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
Sondeo unidireccional desde μl, pips, archivos o consultas web.
Estoy seguro de que eso estaría bien. No estamos hablando de enviar nada a MT. La transferencia en sí puede hacerse de cualquier otra manera. Lo importante es decirle a MT que hay que realizar alguna acción. Es exactamente lo mismo que en la librería de la GUI que has desarrollado: todas las colbecas se hacen a través de eventos.
Por cierto, sobre esta biblioteca: ¿piensan ampliarla y trasladarla completamente a lienzo? Es decir, el "producto" final no es un conjunto de objetos gráficos, sino una imagen completa.
Y en el contexto de la revisión de las dll, por supuesto que me gustaría poder incluirlas como recurso en MT, para no tener que "arrastrarlas" junto con el Asesor Experto o el indicador.
¿Por qué detenerse en dotnet para la gui?
La pregunta no se refiere tanto a la interfaz gráfica de usuario. Las interfaces se pueden crear fácilmente con herramientas de MT. Por supuesto, es un poco complicado y requiere la creación de clases de procesamiento propias, pero todo se puede resolver. Empecé a trabajar con la red debido a la imposibilidad de implementar algunos algoritmos de trabajo con Internet. Es bastante complicado e inestable en C++, incluso en lenguaje nativo, por no hablar de MT. Una vez que domine la red, podré empezar a utilizar la GUI también, porque todo está preparado para ello, a diferencia de lo que ocurre en MT. Entre las cuestiones abiertas del desarrollo de aplicaciones en cualquier lenguaje, concretamente en cualquiera, ya que estas cuestiones no están relacionadas con la red: 1. Retroalimentación, 2. Vinculación de la interfaz gráfica con el gráfico (https://www.mql5.com/ru/forum/103764): uno de los temas.
Sondeo unidireccional a partir de µl, pips, archivos o consultas web.
es su elección ;-)
desde el punto de vista de las aplicaciones - debería haber una forma estándar después de llamar a la DLL para decir a MT "esto es lo que querías, esto es lo que tienes".
Escenario típico para cálculos largos, IO de red - MT llama a DLL, DLL crea un hilo y algo se hace en él. Tiene que haber una forma de decir "ya está, se ha calculado". Sin ella, estamos constantemente sondeando a los EAs por algo.
es tu elección ;-)
Desde el punto de vista de las aplicaciones, debería haber una forma estándar de decirle a MT "esto es lo que quieres, esto es lo que obtienes".
Escenario típico para cálculos largos, IO de red - MT llama a DLL, DLL genera un hilo y algo se hace en él. Tiene que haber una forma de decir "ya está, se ha calculado". Sin ella, estamos constantemente sondeando a la EA en busca de algo.
Yo lo secundo.
Bueno
Todos podemos discutir hasta el final sobre las ventajas de un entorno de desarrollo u otro. ¿Pero para qué? Todos sabemos que ningún sistema de desarrollo es autosuficiente, porque resuelve problemas específicos. Se puede utilizar cualquier otro componente plug-in desarrollado en cualquier otro lenguaje o entorno para ampliar sus capacidades. Sólo tenemos que facilitar la comunicación. No nos vayamos muy lejos: las mismas bibliotecas de Windows que utilizamos a través de la importación... ...los usamos para implementar la funcionalidad que nos falta. Y no se puede decir que esté implementado puramente por medio de mql. ))) Entonces, ¿qué diferencia hay en la aplicación externa que utilicemos para ampliar las capacidades y alcanzar los objetivos deseados? ¿Cómo es que un dll autoescrito es peor que uno de Windows?
He aquí un artículo de ejemplo: https://www.mql5.com/ru/articles/364
Pero no se trata de deshacerse de dll por completo, simplemente nunca sucederá, porque MT tiene estrictamente sus propias tareas. Las bibliotecas del sistema están presentes en este artículo, se mire como se mire. Sí, a diferencia de las librerías caseras, no es necesario llevar estas librerías con el Asesor Experto o el indicador...
¿Qué impide añadir la posibilidad de compilar dlls en los recursos de la herramienta?
Sí, no se puede poner en el mercado, porque el mercado no permite el uso de dll, pero sería mucho más conveniente para su propio desarrollo.
Todos podemos discutir hasta el final sobre las ventajas de un entorno de desarrollo u otro. ¿Pero para qué? Todos sabemos que ningún sistema de desarrollo es autosuficiente, porque resuelve problemas específicos. Se puede utilizar cualquier otro componente plug-in desarrollado en cualquier otro lenguaje o entorno para ampliar sus capacidades. Sólo tenemos que facilitar la comunicación. No nos vayamos muy lejos: las mismas bibliotecas de Windows que utilizamos a través de la importación... ...los usamos para implementar la funcionalidad que nos falta. Y no se puede decir que esté implementado puramente por medio de mql. ))) Entonces, ¿qué diferencia hay en la aplicación externa que utilicemos para ampliar las capacidades y alcanzar los objetivos deseados? ¿Cómo es que un dll autoescrito es peor que uno de Windows?
He aquí un artículo de ejemplo: https://www.mql5.com/ru/articles/364
Pero no se trata de deshacerse de dll por completo, simplemente nunca sucederá, porque MT tiene estrictamente sus propias tareas. En este artículo, las bibliotecas del sistema están presentes se mire por donde se mire. Sí, a diferencia de las librerías caseras, no es necesario llevar estas librerías con el Asesor Experto o el indicador...
¿Qué impide añadir la posibilidad de compilar dlls en los recursos de la herramienta?
Sí, no puedes ponerlo en el mercado, porque el mercado no permite usar dll, pero para tu propio desarrollo sería mucho más conveniente.
Estas reflexiones y publicaciones son de hace 10 años.
Si estamos hablando del ecosistema, entonces deberíamos simplemente cerrar el uso de cualquier importación en MT. Pero no lo hacen. Al fin y al cabo, no se decidieron a utilizar las importaciones de la biblioteca porque sí. Durante un tiempo MT no podía trabajar con peticiones web, había limitaciones a la hora de trabajar con archivos... todo esto se amplió con la importación de bibliotecas. Todo es obvio y todos los sistemas funcionan así. Incluso ahora MQL puede trabajar con archivos sólo desde una caja de arena. No es que nadie cuestione este enfoque, es la política del promotor y todo el mundo lo entiende y lo apoya. Si necesitas salir de una caja de arena o usar el registro para almacenar datos, o una base de datos o un mapeo... entonces usa bibliotecas para este propósito. ¿Verdad? Todo tiene mucho sentido. La herramienta no necesita bases de datos ni nada más... es todo para los desarrolladores, por lo que el lenguaje MQL está disponible, para que puedas implementar herramientas de cualquier funcionalidad. Y desde que existe un entorno de desarrollo, la MT ya no es una cosa en sí misma. )) Sólo tienes que ... ))))
Este tipo de pensamientos y posts tienen 10 años, pero seguimos aquí.
¿Cómo es que sigue siendo así?
Todas las posibilidades de interoperabilidad existen desde hace mucho tiempo. La compatibilidad con DLL se introdujo incluso en 2004.
Nuestras lenguas evolucionan constantemente y se vuelven más potentes y funcionales. Y el ecosistema es más poderoso que cualquier otro.