Mi enfoque. El núcleo es el motor. - página 24
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
Sí.
El motor que lleva la GUI de la aplicación simplemente realiza la mecánica de los controles (botones, campos de entrada, etc...).
Pulsación de botones, casillas de verificación, introducción de texto y otras acciones del usuario, directamente de se pasan a la aplicación del desarrollador.
La aplicación puede transferir sus datos a campos y tablas.
Todo se hace a través de un simple archivo de conexión.
Oh, bueno, eso es otro asunto entonces.
NET-dlls están llegando a MT. Ya no es difícil hacer una GUI en C-sharp para MT, y con más funcionalidad. Y como en cualquier caso todos los eventos están en MT-ticks, entonces los botones también. Bueno, el análisis de tornillo, imho, más fácil de DLL que a Pedro.
En general, el motor de Pedro, si alguien útil, es sólo los vendedores del mercado, donde DLL nizizzi.
En primer lugar, mientes cuando dices que "no hay ninguna dificultad". Puedes crear fácilmente una GUI en C#, pero ¿conectarla a una aplicación MQL?
Muéstrame un ejemplo de tal conexión. Esto es, al menos, una muleta espeluznante. Todo debe hacerse a través de una DLL. Enviar eventos, recibir eventos...
¿Cuánto esfuerzo y tiempo se necesita para desarrollar una conexión de SharpGUI con una aplicación MT mediante DLL?
¿Quién lo hará, ante la sencillez de mi solución? Ya tengo una interfaz de conectividad. El problema de la conexión es de media hora (si hay varias ventanas). Todo es muy sencillo. No hay DLL.
Así que esto, es una idea "moribunda".
En primer lugar, mientes cuando dices que "no es para tanto". Hacer una GUI en C# es fácil, pero ¿conectarla a una aplicación MQL?
Muéstrame un ejemplo de tal conexión. Esto es, al menos, una muleta espeluznante. Hay que hacerlo todo a través de una DLL. Enviar eventos, recibir eventos...
¿Cuánto esfuerzo y tiempo llevaría desarrollar unainterfaz gráfica de Sharp con una aplicación MT SIN la DLL?
¿Quién lo hará, ante la sencillez de mi solución? Ya tengo una interfaz de conexión. El problema de conexión es de media hora (si hay varias ventanas). Todo es muy sencillo. No hay DLL.
Así que esto, es una idea "moribunda".
Todo es igual. No hay ninguna complicación. Es indiferente la función que se llame, aplicación o DLL. ¿Considera que es complejo llamar a las funciones?
Todo es igual. No hay ninguna complicación. Es indiferente la función que se llame, la de la aplicación o la de la DLL. ¿Ve usted dificultades para llamar a las funciones?
No. Se trata de la memoria donde los valores de los parámetros tienen que ser sincronizados. La memoria tiene que estar en un archivo o en una memoria compartida de la aplicación en la DLL (o en otro lugar).
Pero este no es el punto principal.
EL GENERAL:
Cada desarrollador tendrá que idear su propia interfaz para conectarse a su GUI en Sharp.
¿Y por qué sería necesario si ya tengo todo funcionando?
No. Se trata de la memoria en la que deben sincronizarse los valores de los parámetros. La memoria debe estar en un archivo o en la memoria compartida de la aplicación en la DLL (o en otro lugar).
Pero este no es el punto principal.
EL GENERAL:
Cada desarrollador tendrá que diseñar su propia interfaz para la conexión con la GUI en Sharp.
¿Y por qué sería necesario si ya tengo todo funcionando?
Estás siendo dramático).
Estás siendo dramático).
Ni un poco. Conozco la situación. He realizado la interconexión entre una aplicación MT y una aplicación Sharpe, a través de una DLL escrita en C++. Un terrible dolor de cabeza. Tienes que trabajar con Visual Studio y MT al mismo tiempo. A continuación, para ejecutar aplicaciones en paralelo.
Pero lo principal es que nadie desarrolló un formato de interacción de las partes de la aplicación. Por lo tanto, cada uno agonizará por su cuenta.
Ni una gota. Conozco la situación. He realizado la interconexión entre una aplicación MT y una aplicación Sharpe, a través de una DLL escrita en C++. Es un terrible dolor de cabeza. Hay que trabajar con Visual Studio y MT al mismo tiempo. A continuación, para ejecutar aplicaciones en paralelo.
Pero lo principal es que nadie desarrolló un formato de interacción de las partes de la aplicación. Por lo tanto, cada uno luchará por su cuenta.
La DLL es una herramienta estándar de Windows. La interoperabilidad de las DLL se ha desarrollado y utilizado desde los tiempos del DOS. No hay ningún problema en absoluto.
La DLL es una herramienta estándar de Windows. La interoperabilidad con la DLL se ha desarrollado y utilizado ampliamente durante mucho tiempo, desde los días del DOS. No hay ningún problema.
Se ha desarrollado la interacción de Sharp con la DLL. Y la interacción de una aplicación ICL con Sharp a través de DLL es una molestia personal para el programador.
Necesita organizar la memoria compartida y hacer sus llamadas a funciones basadas en banderas de lectura.
En consecuencia, necesita acceder sin cesar a la memoria compartida que está en la DLL o en el archivo.Después de todo, no hay ninguna llamada de retorno de Sharp a través de DLL a MT.
La interacción con la DLL en el lado de Sharp se ha elaborado. Y la interacción de la aplicación MKL con Sharpe a través de DLL, es una molestia personal para el programador.
Necesita organizar la memoria compartida y hacer sus llamadas a funciones basadas en banderas de lectura.
En consecuencia, necesita acceder sin cesar a la memoria compartida que está en la DLL o en el archivo.Después de todo, no hay ninguna llamada de retorno de Sharp a través de DLL a MT.
Tampoco tiene una devolución de llamada en MT. Todo se hace mediante eventos predefinidos en MT, que de una vez por todas.
Seguirá enviando eventos de terminal a la DLL, y no importa dónde los procese, en MT o en DLL.
Incluso si uno imagina que la verificación constante de los mensajes de Sharp por parte de la aplicación ICL no es una molestia, el desarrollo de un formato de interacción es una tarea muy voluminosa.
Esta tarea incluye lo siguiente:
1. La organización de la memoria compartida.
2. Implementar la interacción de las tres partes.
3. Pruebas sincronizadas de los tres lados (Sharp, DLL, aplicación MT).
Requiere mucho tiempo.
En mi caso, el usuario recibe el archivo y lo rellena. Y la conexión funciona.