Creación de una interfaz gráfica para los MQL en modo gráfico. - página 12
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
En realidad, no. No hay diferencia entre un programa externo y un programa en MT. Las capacidades son las mismas, la interacción es la misma.
No has explicado nada en absoluto. ¿Cómo se obtienen los datos de MT* en el panel de Sharpe?
He estado haciendo la retroalimentación a través del Mapeo de la Memoria con un sondeo cronometrado. El panel sólo me envió diferentes configuraciones y resultados de cálculo lentos.
La ignorancia da confianza. Pero el conocimiento multiplica las penas.
Ok, entonces voy a hacer el panel por separado, la comunicación a través de la asignación de memoria. A finales de los años 2000 lo hacía por tuberías, pero no me gustaba.
Conectado directamente, sin embargo, no notó ningún horror.
La interfaz COM del terminal sería genial, aunque se está quedando rápidamente obsoleta.
Parece que no encaja con el tiempo real :-(.
La interfaz COM probablemente no estará disponible.
Pero, ¿puedo preguntar por qué está obsoleto?
Además, se está quedando rápidamente obsoleta.
La interfaz COM probablemente no estará disponible.
Pero, ¿puedo preguntar por qué está obsoleto?
Además, se está quedando rápidamente obsoleta.
ha sido sustituido por .net con sus interfaces de comunicación
ha sido sustituido por .net con sus interfaces de comunicación
y en COM los GUIDs valen mucho por sí solos
MS sigue comprando los GUID no utilizados por un dólar cada 10. Si te sobra algo de los viejos tiempos, ¡puedes sacar un buen provecho!
Y en COM, los GUIDs valen mucho por sí solos
MS sigue comprando los GUIDs no utilizados por un dólar la decena. Si te sobra algo de los viejos tiempos, ¡puedes sacar un buen provecho!
Tengo algunos por ahí :-) Te dejaré enviarlos a MS
066cd265-e2fe-468e-9492-4228e9759e38
8e1040ba-dc3e-4e2a-9208-e3ea8da9ad05
03dcd7cd-4b9b-4ff7-bff0-e0839a0f9d8b
d69f2c8c-de51-4557-8188-4ebb870da7da
a79a8cc6-f785-4268-bc4e-2deda0f1ecd0
f4f59f52-1da8-4f74-a71e-9aec1992674d
85608797-6015-456d-af64-ad7890120372
9289991a-e287-47fb-b595-6d719c1b7dbd
63d3b953-3229-4045-a82a-fc9e7795bb01
c75c4e0f-8320-42df-943c-9aada54b60eb
si hay algo más, podría encontrarlo.
Colegas. Creo que la discusión sobre qué entorno de desarrollo es mejor y qué código es más rápido no tiene ningún sentido. Todo es cuestión de gustos y depende de las tareas a resolver. Independientemente del entorno de desarrollo, seguimos teniendo problemas de interacción entre una aplicación externa y una herramienta de MetaTrader. Veamos un ejemplo sencillo. Has implementado en un dll nativo un algoritmo de cálculos matemáticos complejos. Usted pasó los parámetros requeridos de la herramienta MT a esta biblioteca e inició el cálculo, la herramienta continuó su trabajo hasta que el cálculo se completó. Y, de nuevo, este problema no depende del entorno de desarrollo.
Veo varias opciones:
1. La posibilidad de llamar desde fuera del programa al método OnChartEvent, utilizando por ejemplo el PostMessage
2. Añadir a las herramientas de МТ nuevo método, como ofreció Renat: OnExternal, especificando el tipo de evento o los datos generalmente transferidos, es decir, en este método puede devolver los datos
3. Implantación en herramientas de MT de winsocket. Esto es similar al segundo punto, pero permite que la herramienta MT se conecte a un puerto específico para escuchar datos.
Si el primer y el segundo elemento permiten la interacción a nivel de una sola máquina, el tercer elemento proporcionará una red de herramientas de MT.
He aquí un ejemplo:https://www.mql5.com/ru/articles/2599
Pero aquí también tienes el problema de tener que comprobar si los datos de la toma están disponibles todo el tiempo.
Por lo tanto, el problema de la devolución de llamada se mantiene en todos los casos y no se resuelve.
El control del tiempo no es una solución, sino una muleta. Sí, a falta de otras opciones, así es como lo estamos resolviendo ahora.
Si los desarrolladores implementaran una solución para estos problemas a nivel de plataforma, entonces no habría necesidad de acceder al terminal de la API. Al fin y al cabo, no se pide por la buena vida, sino porque no hay una interacción plena entre la MT y las aplicaciones que se crean. Y repito: este problema existe independientemente del entorno de desarrollo de aplicaciones externas elegido.
Información sobre la posibilidad de utilizar bibliotecas de red )))https://www.mql5.com/ru/forum/13388
El tema es muy antiguo en principio. Los propios desarrolladores anunciaron en su día la posibilidad de trabajar con librerías de red sin ninguna dificultad... Mucha agua ha corrido desde entonces, pero la cuestión sigue sin resolverse...
O aquí, un mensaje del propio Renat:https://www.mql5.com/ru/forum/3153/page2#comment_298866
https://www.mql5.com/ru/forum/3153/page2#comment_298892
Colegas. Creo que la discusión sobre qué entorno de desarrollo es mejor y qué código es más rápido no tiene ningún sentido. Todo es cuestión de gustos y depende de las tareas a resolver. Independientemente del entorno de desarrollo, seguimos teniendo problemas de interacción entre una aplicación externa y una herramienta de MetaTrader. Veamos un ejemplo sencillo. Has implementado en un dll nativo un algoritmo de cálculos matemáticos complejos. Usted pasó los parámetros requeridos de la herramienta MT a esta biblioteca e inició el cálculo, la herramienta continuó su trabajo hasta que el cálculo se completó. Y, de nuevo, este problema no depende del entorno de desarrollo.
Veo varias opciones:
1. La posibilidad de llamar desde fuera del programa al método OnChartEvent, utilizando por ejemplo el PostMessage
2. Añadir a las herramientas de МТ nuevo método, como ofreció Renat: OnExternal, especificando el tipo de evento o los datos generalmente transferidos, es decir, en este método puede devolver los datos
3. Implantación en herramientas de MT de winsocket. Esto es similar al segundo punto, pero permite que la herramienta MT se conecte a un puerto específico para escuchar datos.
Si el primer y el segundo elemento permiten la interacción a nivel de una sola máquina, el tercer elemento proporcionará herramientas de MT con comunicación en red.
He aquí un ejemplo:https://www.mql5.com/ru/articles/2599
Pero aquí también tienes el problema de tener que comprobar si los datos de la toma están disponibles todo el tiempo.
Por lo tanto, el problema de la devolución de llamada se mantiene en todos los casos y no se resuelve.
El control del tiempo no es una solución, sino una muleta. Sí, a falta de otras opciones, así es como lo estamos resolviendo ahora.
Si los desarrolladores implementaran una solución para estos problemas a nivel de plataforma, entonces no habría necesidad de acceder a la API del terminal. Al fin y al cabo, no se pide por la buena vida, sino porque no hay una interacción plena entre la MT y las aplicaciones que se crean. Y repito: este problema existe independientemente del entorno de desarrollo de aplicaciones externas elegido.
Voy a añadir acerca de la supervisión y el sondeo, sólo que no todo el mundo lo sabe - para evitar sacudir la DLL en cada encuesta, puede tener int[] para "compartir" banderas. Dentro de la DLL todos los accesos a ellos como __atomic__ .
En principio esto funciona y es bastante económico en recursos, pero hay que contar con que en el lado de MQL los incrementos/decrementos son también atómicos y el optimizador no hace suposiciones sobre los valores.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Para hacer las cosas realmente bien, bastaría con un atributo atómico (¿volátil?) y un conjunto de primitivas adecuadas. En mi opinión, es más fácil que construir un nuevo mecanismo en el sistema y no cambia el protocolo DLL existente
Añadiré sobre la monitorización y el sondeo, no todo el mundo lo sabe - para no molestar a la DLL con cada sondeo, puedes crear int[] para "compartir" banderas. Dentro de la DLL todos los accesos a ellos como __atomic__ .
En principio esto funciona y es bastante económico en recursos, pero hay que contar con que en el lado de MQL los incrementos/decrementos son también atómicos y el optimizador no hace suposiciones sobre los valores.
int flags[1]={0}; // когда DLL досчитает она инкрементит флаг
handle=InitDLL(flags); //
...
// опрос типично выглядит так:
while ( flags[0] ) // проверить один int это очень быстро
{
flags[0]--;
ReadDataFromDLL(handle);
}
Para hacer las cosas realmente bien, bastaría con un atributo atómico (¿volátil?) y un conjunto de primitivas adecuadas. En mi opinión, es más fácil que construir un nuevo mecanismo en el sistema y no cambia el protocolo DLL existente
Maxim, ¿cómo es mejor esta solución? Al fin y al cabo, para comprobar el estado de una bandera, también hay que comprobarla periódicamente en MQL. Así, resulta que en todas partes hay que vigilar constantemente los cambios de estado de algo para entender que es el momento de recoger los datos. Y este fragmento puede ser almacenado en la propia dll y comprobado allí - eso es lo que yo hago. En tu ejemplo hay una llamada implícita a la dll para devolver el estado de la bandera.