Galería de interfaces de usuario escritas en MQL - página 42
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
Añadido:
Las ventanas de menú ahora siempre permanecen dentro del espacio del gráfico y no salen de la vista. Ejemplo:
NO SOBREPASAN EL BORDE DERECHO DEL GRÁFICO:
NO SOBREPASAR EL BORDE INFERIOR DEL GRÁFICO:
La falta de prioridades en las direcciones de desarrollo nunca conduce a buenos resultados. Una verdad elemental que todos los desarrolladores profesionales conocen. Hace 4 años no podía poner una versión acabada del diseñador porque no tenía un plan de finalización. Si hubiera tenido un plan, todo habría estado terminado hace tiempo. La siguiente razón para detener el proyecto son las discusiones infructuosas con las opiniones de otras personas en el foro. Debates sobre enfoques en la programación o la necesidad-no necesidad de la GUI como tal... Por desgracia, fue una pérdida de tiempo inútil.
Entonces, ¿cuál es la culminación de este proyecto? La respuesta a esta pregunta es muy importante porque determina la elección de las direcciones para el desarrollo posterior.
Y así, como lo presento:
1. Control por software de los elementos de la interfaz.
Esta es una de las principales tareas en este momento. Ahora el usuario sólo puede "atrapar" eventos de la interfaz gráfica en el archivo API, pero no obtener/cambiar las propiedades de los elementos o los valores de los parámetros. Sopesando la complejidad, puedo decir que la tarea es fácil y estará resuelta antes de la próxima versión. Dar al usuario acceso programático a un amplio conjunto de elementos GUI y propiedades de las ventanas.
2. Tablas regulares y dinámicas .
Las tablas regulares ya se han implementado. Su funcionamiento se ha probado repetidamente. Funcionaron funciones como arrastrar y soltar columnas y filas (cambiando su lugar en la tabla), contraer/ampliar filas de la tabla (añadiendo el elemento T_FOLDER) u ocultar/desocultar columnas. Funcionó la integración automática de controles en la tabla. Por ejemplo, casillas de verificación, listas desplegables, botones, controles deslizantes, campos de entrada con botones y campos de entrada simples: todos ellos se integraban en la tabla por sí solos cuando se añadía la palabra clave IS_TABLE a la cabecera del grupo. Los valores de las celdas podían colorearse según su valor. Las tablas podían incluso incrustarse en listas de árbol.
Pero, ¿merece la pena dedicar tiempo a recuperar todas las funciones antiguas?
Es difícil decirlo.
Creo que lo primero que hay que hacer es recuperar las funciones básicas de las tablas normales y asegurarse de que funcionan bien. El resto es lo que toca.
Pero lo principal en la interfaz de un robot de trading serio son las tablas dinámicas. Las que son capaces de pasar por un flujo interminable de datos de la bolsa. Nunca las había implementado.
Conclusión: las tablas dinámicas son una prioridad.
(Tenemos que empezar a desarrollarlas).
3. Listas de árboles.
Elemento GUI bastante realizado y rehecho muchas veces antes. Y cada vez funcionaba mejor. La última versión es particularmente buena, pero no está terminada. Si recuerdo en detalle, puedo terminarlo en un día o dos. Pero, ¿hasta qué punto lo necesitas en una GUI? Creo que no te hará daño, pero no deberías obsesionarte con ello.
Conclusión: la lista de árboles no es una prioridad para el desarrollo futuro.
(La terminaré cuando tenga tiempo).
4. Ventanas dinámicas.
Los mecanismos básicos - redimensionamiento, desplazamiento vertical y horizontal, escalado, adaptación de la ventana escalada al cambio de tamaño del gráfico - ya funcionan bien. Pero hay muchos errores pequeños y molestos. Al estar completas, las ventanas dinámicas son ideales para tablas dinámicas grandes y listas largas.
Conclusión: terminar las ventanas dinámicas es una prioridad.
(Puede llevar un par o tres de días de duro trabajo con entusiasmo).
5. Minimizadores de grupos y tablas.
Elementos G_FOLDER y T_FOLDER. Ya funcionaron muy bien en el pasado. Cómo funcionan ahora no lo sé, ya que no he tenido tiempo de probarlos. Curiosamente, en el último desarrollo de la función fenómeno elemento, he unificado la gestión de la lista de árbol y estos dos tipos de colapsadores. Una función gestionaba tres elementos y no tenía más de 400 - 500 líneas de tamaño (que no es mucho para mis estándares). Si consigo que esta función vuelva a funcionar (ahora está desactivada), los tres elementos funcionarán perfectamente. Veamos.
Conclusión: los elementos G_FOLDER y T_FOLDER no tienen prioridad.
(Lo haré si tengo oportunidad y ganas).
Y la última tarea prioritaria que se me ha ocurrido ahora:
6. Creación de una rama de plantillas de grupos de elementos y ventanas escritas en el lenguaje de marcado.
Esto permitirá a los usuarios construir rápida y fácilmente la interfaz necesaria para resolver tareas, incluso sin un conocimiento profundo del lenguaje.
Si alguien tiene alguna idea sobre las prioridades para el desarrollo futuro, por favor, compártala. Tomaré nota.
Sí, la gestión del programa es lo más importante, una obligación para cualquiera que vaya a utilizar el motor.
Para mí, las tablas dinámicas son imprescindibles. Necesito la interfaz principalmente para la visualización de eventos e informes en tiempo real. Los controles son el fleje para gestionarlos (filtros, etc.) Con la implementación de esto podría empezar a integrar el motor.
La segunda prioridad es una ventana de pantalla completa. Pero esto es muy simple - ya lo tienes hecho en el diseñador. Con una barra de tareas. Y temporalmente puedo utilizar la ventana más grande posible. Tengo que elegir el tamaño, es doloroso.
La tercera prioridad son los gráficos. No sé lo difícil que es. Tal vez debería utilizar las herramientas estándar kanvas, si son lo suficientemente flexibles. Nunca he probado otra cosa que Fast And Furious Easy And Fast v1.
Dios quiera que la motivación sea suficiente. La mayoría de las veces se desvanece tras un encuentro con los haters. "La gente buena es mayoría, pero los malvados están mejor organizados".
La segunda prioridad es una ventana a pantalla completa. Pero esto es muy simple - ya tiene esto hecho en el diseñador. Con una barra de tareas. Y temporalmente puedo usar la ventana más grande posible. Tengo que recoger las dimensiones, que es doloroso.
La tercera prioridad son los gráficos. No sé lo difícil que es. Tal vez debería utilizar herramientas estándar kanvas, si son lo suficientemente flexibles. Nunca lo he probado, excepto Fast And Furious Easy And Fast v1.
Dios quiera que la motivación sea suficiente. La mayoría de las veces se desvanece tras un encuentro con los haters. "La gente buena es mayoría, pero los malvados están mejor organizados".
1. La gestión programática de artículos estará en la próxima versión. Tentativamente en 7 - 10 días.
2. Las tablas dinámicas están "en desarrollo". Todavía no puedo decir cuánto tardará. El proceso puede ser muy rápido.... o no tan rápido. Se desconoce.
3. Ya tienes una ventana a pantalla completa. Pruébalo. En las propiedades de la ventana escribe "DINAMICA" en lugar de "AJUSTES". Pruébalo y escribe tus impresiones.(Sólo tienes que ir a la versión de campo del constructor). Puedes cambiar el tamaño tirando de los bordes de la ventana o hacer zoom con el botón superior. Hay una opción con doble clic en la barra superior (donde está el nombre de la ventana), o simplemente coge la ventana por la "tapa" y arrástrala hacia arriba hasta que se escale sola. Las mismas manipulaciones funcionan a la inversa.
4. Imprime el archivo API de tu ventana y publícalo aquí. Miraré y entenderé cómo se imprimen las tablas allí. Esto es importante para la futura implementación de la conexión de software.
5. Voy a pensar seriamente en gráficos personalizados. He visto la implementación de Anatoly, pero no he intentado replicar este elemento.
Un matiz importante cuando se trabaja con una ventana dinámica:
La ventana no acepta elementos de tipo V_BOX, porque contienen su propio lienzo. Esto provoca la superposición de un lienzo sobre otro. Por lo tanto, este elemento debe ser comentado junto con todas las líneas i, IN, "V1", .
Es decir, los grupos que se colocan en el elemento V_BOX deben estar sólo en la ventana en "MF". No es necesario comentar específicamente la línea i, IN , "V1".
Si no funciona, mañana te lo enseño con más detalle. En imágenes.
Un ejemplo de conversión de la ventana de ajustes en una ventana dinámica:
(haga clic en la imagen)