Creación de una interfaz gráfica para los MQL en modo gráfico. - página 14
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
Tengo un TS externo, no necesito la retroalimentación de la GUI del terminal.
¿Así que no usas un terminal? ¿Cambia usted telepáticamente?
¿Así que no usas un terminal? ¿Comerciar telepáticamente?
Sinceramente, no he sentido la necesidad de adjuntar formularios a los gráficos.
Hay un gráfico activo que está directamente conectado al gráfico (todo tipo de líneas, leyendas, letras, etc.).
Pero hay controles de la interfaz gráfica de usuario: ajustes, informes, estadísticas. Y son bastante grandes y es un crimen contra el usuario ponerlos 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.
actualización/ a punto de poner el formulario - poner RectLabel en el gráfico y en el gráfico-acontecimientos para seguir el cambio de las coordenadas. Cuando cambie - coloque su formulario estrictamente en la parte superior :-) Se necesita un poco de pandereta cuando se cambia de pestaña, se minimiza la ventana, se oculta el 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 estoy de acuerdo. Si las órdenes se abren mediante GUI, como en su primer ejemplo, el formulario correspondiente debería pertenecer al gráfico correspondiente. Por ejemplo, tiene 5 gráficos abiertos y de estos 5, se abren los formularios de gestión de órdenes (no los informes ni las configuraciones). La gratuidad de 5 formularios "pertenecientes" a diferentes gráficos confundirá y desconcertará a los usuarios. Y cuando sólo tienen ante sus ojos el formulario que pertenece a la carta activa, la cosa cambia.
No estoy de acuerdo. Si la GUI se utiliza para abrir órdenes, como en su primer ejemplo, entonces el formulario correspondiente debe pertenecer al gráfico correspondiente. Por ejemplo, tiene 5 gráficos abiertos y de estos cinco, los formularios de gestión de pedidos están en marcha (no los informes ni las configuraciones). La gratuidad de 5 formularios "pertenecientes" a diferentes gráficos confundirá y desconcertará a los usuarios. Y cuando sólo tienen ante sus ojos el formulario que pertenece a la carta activa, la cosa cambia.
Por cierto, también hay una tabla (árbol) de pedidos, pero es sólo un ejemplo...
La principal duda de los usuarios es "cómo colocar los gráficos/formularios" en 3 monitores :-) No hay pestañas durante el comercio - todo debe ser visible
)) el terminal es el proveedor de datos y. el receptor que ejecuta la aplicación. Eso es todo. No hay nada que configurar en él.
¿Me estás tomando el pelo o es algún tipo de truco? Llevo dos días intentando obtener una respuesta. ¿Qué canal utiliza el segundo receptor para recibir estas peticiones? Tal vez deberías ser un explorador. Si les pillan, agitarán la mano, escupirán y lo dejarán estar, no deja de ser una ceja de chorlito...
¿Me estás tomando el pelo o es algún tipo de truco? Llevo 2 días intentando obtener una respuesta - ¿a través de qué canal de comunicación recibe el segundo - receptor-ejecutor estas peticiones? ¿Por qué no te unes a los scouts? Si les pillan, saludarán, escupirán y lo dejarán estar, de todas formas es un solo trasero...
Alexei, mi opinión es que el esquema es el siguiente: cada gráfico tiene un EA que envía datos a la aplicación. Estos son los proveedores de datos. Hay un EA en un gráfico separado que sondea la aplicación para los comandos. Este EA acepta peticiones y las ejecuta. Como resultado, los EAs en los propios gráficos no están ocupados descargando encuestas. Envían los datos y siguen trabajando en su modo. Y un EA separado se dedica a hacer encuestas todo el tiempo.
Pero no veo la necesidad de un Asesor Experto separado. El sondeo puede ser manejado por el indicador porque estará en un hilo separado del EA. Y cuando el indicador revela una orden para este gráfico, puede enviar un evento que será interceptado y ejecutado por el Asesor Experto.
Alexei, creo que el esquema es el siguiente: cada gráfico tiene un EA que envía datos a la app. Estos son los proveedores de datos. Hay un EA en un gráfico separado que sondea la aplicación para los comandos. Este EA acepta solicitudes y las ejecuta. Como resultado, los EAs en los propios gráficos no están ocupados descargando encuestas. Envían los datos y siguen trabajando en su modo. Y un EA separado se dedica a hacer encuestas todo el tiempo.
Pero no veo la necesidad de un Asesor Experto separado. El sondeo puede ser manejado por el indicador porque estará en un hilo separado del EA. Y cuando el indicador detecta una orden para un gráfico determinado, puede enviar un evento que será interceptado y ejecutado por el Asesor Experto.
Me importa una mierda si se desglosa en 5 EAs o en 100500. Preguntaba por el canal de comunicación, ya que puede haber varios tipos. De nuevo, lo hacía hace 10 años en los oleoductos. En ese momento no había pips incorporados en mql, usaba C++DLL nativo. Y todo el robot estaba en Sharp. Los comandos del Asesor Experto se acumularon en el búfer de la DLL, ya que se emitieron de forma asíncrona para mayor rapidez. Y el MQL4 Expert Advisor accedía a la DLL en cada tick (aún no tenía temporizador), pasaba las cotizaciones y recogía los comandos. Todo era multidivisa, no entiendo por qué necesitamos muchos gráficos.
Aquí he descrito el mecanismo de intercambio en dos líneas. ¿Es tan difícil describir su mecanismo en lugar de un océano de agua?
Aquí he descrito el mecanismo de intercambio en dos líneas. ¿Es tan difícil describir su mecanismo en lugar de un océano de agua?
Mierda. Primero pregunté por la interfaz gráfica de usuario: ¿cómo se comunica? Respondió que de ninguna manera, no es necesario. Ahora, resulta que necesita cómo se comunican los asesores. 100 veces escribió sobre ello.
Eres realmente incapaz de aceptar preguntas. No me interesa cómo se comunican los concejales. Ya está, cierro el hilo, porque no tiene sentido.
Me importa un carajo si se desglosa en 5 concejales o en 100500. Preguntaba por el canal de comunicación, ya que puede haber varios tipos. De nuevo, lo hacía hace 10 años en los oleoductos. En ese momento no había pips incorporados en mql, usaba C++DLL nativo. Y todo el robot estaba en Sharp. Los comandos del Asesor Experto se acumularon en el búfer de la DLL, ya que se emitieron de forma asíncrona para mayor rapidez. Y el MQL4 Expert Advisor accedía a la DLL en cada tick (aún no tenía temporizador), pasaba las cotizaciones y recogía los comandos. Todo era multidivisa, no entiendo por qué necesitamos muchos gráficos.
Aquí he descrito el mecanismo de intercambio en dos líneas. ¿Es tan difícil describir su mecanismo en lugar de un océano de agua?