Creación de una interfaz gráfica para los MQL en modo gráfico. - página 13
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
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 hago. En tu ejemplo tienes una llamada implícita a la dll para devolver el estado de la bandera.
Comprobar la bandera es una operación muy rápida. Me refiero al más rápido de todos :-)
Y no hay llamadas implícitas en este ejemplo:
InitDLL recibió int *flags como entrada, lo almacenó en algún lugar, generó una traza que cuenta algo y al terminar hace atomic_inc(flags).
El asesor sólo tiene que comprobar las banderas[0].
comprobar la bandera es una operación muy rápida. Es decir, es el más rápido de todos :-)
Y no hay llamadas implícitas en este ejemplo:
InitDLL recibe int *flags en la entrada, lo almacena en algún lugar, genera una traza que cuenta algo y hace atomic_inc(flags) al terminar.
El asesor sólo tiene que comprobar las banderas[0].
Pero no se puede hacer nada con sólo comprobar la bandera - se requiere la sincronización entre hilos, barreras, atómica o mutex que tomar, por supuesto, para no todas las CPU.
Exactamente para comprobarlo. Ese es el punto clave. Y sugiero alertar a la herramienta de que la "tarea" ha sido completada. Es decir, no tiene que gastar recursos constantes en la comprobación. Ha llegado la notificación: tienes los datos.
comprobar la bandera es una operación muy rápida. Es decir, es el más rápido de todos :-)
Y no hay llamadas implícitas en este ejemplo:
InitDLL recibe int *flags como entrada, lo almacena en algún lugar, genera una traza que cuenta algo y al terminar hace atomic_inc(flags).
El EA sólo tiene que comprobar flags[0].
Max, bueno, la situación con el callback está clara por ahora. Usaremos lo que tenemos y esperaremos a que los desarrolladores añadan la función de callback.
Quiero volver a la cuestión de la interfaz gráfica de usuario. No importa sobre qué se dibuje. Por ejemplo yo lo hago en Sharp, tú lo haces en Tcl.
Mientras el formulario exista por sí mismo, no es un problema en absoluto. Pero me gustaría que los formularios no volaran por sí solos, sino que estuvieran vinculados a las cartas correspondientes.
Cuando se establece el padre del formulario creado, se coloca en el gráfico requerido. Pero hay un problema de "fusión" de la ventana con el gráfico y el gráfico sólo dibuja la forma "pegada".
Sugiero que se intente resolver este problema por ahora, ya que todavía está fuera del ámbito de acción de los desarrolladores de MT.
¿Ha intentado adjuntar su interfaz gráfica a los gráficos?
Pero no se puede hacer sólo con la comprobación de la bandera, se necesita la sincronización entre hilos, barreras, atómica o mutex, que no es relevante para todas las CPU, por supuesto.
¿Y cómo se implementan los mutex de todo tipo? Todo a través de la comprobación y el establecimiento de banderas, por lo que sé. De todos modos, hay que comprobar alguna bandera en algún lugar del hilo de µl.
Muy cierto. Pero que ocurra a un nivel muy bajo, de aplicación, como, por ejemplo, funciona con OnChartEvent. Es decir, ahora lo programamos explícitamente (comprobaciones), pero todo podría trasladarse al nivel de la aplicación, como dijo Renat (sugirió algunas variantes).
Me apunto :-) donar - puedes enviarlo 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.
Gracias, aprobado, tengo una libra.
Gracias, aprobado, tengo una libra.
así que es más rentable que el scalper ! listo para venderlos al por menor por un céntimo, los vendes al por mayor por 1$/diez. el único límite es la velocidad de transmisión :-) algunos kilobytes de GUIDs por segundo
Tentador como el infierno. Así es como conquistaremos el mercado de GUIDs usados. Y convertirse en un monopolio, crear un frenesí artificial como con el bitcoin y hacerse rico.
Max, bueno, la situación con el callback está clara por ahora. usaremos lo que tenemos y esperaremos a que los desarrolladores añadan la capacidad de callback.
Quiero volver a la cuestión de la interfaz gráfica de usuario. No importa sobre qué se dibuje. Por ejemplo yo lo hago en Sharp, tú lo haces en Tcl.
Mientras el formulario exista por sí mismo, no es un problema en absoluto. Perome gustaríaque los formularios no volaran por sí solos, sino que estuvieran vinculados a las cartas correspondientes.
Cuando se establece el padre del formulario creado, se coloca en el gráfico requerido. Pero hay un problema de "fusión" de la ventana con el gráfico y el gráfico sólo dibuja la forma "pegada".
Sugiero que se intente resolver este problema por ahora, ya que todavía está fuera del ámbito de acción de los desarrolladores de MT.
¿Ha intentado adjuntar su interfaz gráfica a los gráficos?
No tengo ninguna necesidad de encadenar formularios con gráficos.
Hay gráficos operativos que se conectan directamente a la carta (todo tipo de líneas, leyendas, inscripciones, etc.), esto lo hacen naturalmente las herramientas de MT.
Pero hay interfaces gráficas de gestión: ajustes, informes, estadísticas. Son bastante grandes y es un crimen contra el usuario ponerlas dentro de un gráfico :-)
Sólo tiene que colocar el formulario encima del gráfico. Tendrá que quitar el formulario del gestor de ventanas y seguir los cambios en la geometría y el enfoque del gráfico.
La actualización / sobre la colocación de un formulario - poner RectLabel en el gráfico y en el gráfico de eventos para seguir el cambio de codinates. Cuando cambie - ponga su forma estrictamente en la parte superior :-) Necesitas una pandereta cuando cambies de pestaña, minimiza la ventana para ocultar tu formulario a tiempoTal "puesta de sol a mano" :-) Al menos no te meterás en las tripas de MetaTrader y no impondrás nuevos escalofríos y ganchos en sus ventanas, es decir, te comportarás decentemente
Cualquier GUI llamado desde DLL tiene la característica más desagradable - los Asesores Expertos/indicadores que lo llaman se reiniciarán periódicamente por el más mínimo estornudo. Lo que lleva a la reapertura de formularios y cascadas de lenguaje soez...
Quizás los tan anunciados "servicios" (o como se llamen) no tengan este inconveniente.
No has explicado nada en absoluto. ¿Cómo se llevan los datos de MT* al 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 transmitía diferentes ajustes y resultados de cálculo lentos