Realización de un proyecto crowdsourced en Canvas - página 8

 
o_O:

DE ACUERDO.

el CFrame está claro.

---

Me he dado cuenta de que has seguido el camino en el que los bloques de la guía están representados cada uno por su propio mapa de bits.

un punto importante para los que lean esto y que ya hayan empezado a pensar en ello:
sólo debería funcionar en un mapa de bits, con todos los elementos del gui renderizados en él. Incluyendo el orden z.
En este caso, habrá más posibilidades de renderización. (sombras, degradados, etc.)
Y el control se simplifica (no llegaremos al nivel de los objetos MT)

En mi opinión, cada ventana individual de la aplicación (diálogo) debería tener su propio mapa de bits y objeto en el gráfico (ni siquiera considere el caso de que varios EAs o indicadores "violen" un único recurso de mapa de bits).
En este caso, la sombra de una ventana puede implementarse como un mapa de bits de canal alfa y así eliminar la carga computacional de calcular esta sombra.
Todos los elementos GUI de una misma ventana se dibujan en su mapa de bits teniendo en cuenta el orden Z y el anidamiento (no sé cómo llamar correctamente al anidamiento de los objetos GUI)

Monitorear los eventos del ratón a través de CHARTEVENT_MOUSE_MOVE, lo hice en mis proyectos, no se encontraron retrasos.
No fue posible utilizar otros eventos sin perder la calidad de la entrada del ratón.
 
Para mis proyectos MQL, quiero llevar la biblioteca GUI a un análogo de WPF, donde el marcado y los eventos se describen en un archivo de texto (por ejemplo, XML).

Sólo me queda implementar los eventos que el motor de la GUI llamará según la descripción del archivo de texto.
 
Zorro:
En mi opinión, cada ventana de aplicación individual (diálogo) debería tener su propio mapa de bits y objeto en el gráfico (ni siquiera considerar el caso de que varios EAs o indicadores "abusen" de un recurso de mapa de bits).
En este caso, la sombra de una ventana puede implementarse como un mapa de bits de canal alfa y así eliminar la carga computacional de calcular esta sombra.
Todos los elementos GUI de una misma ventana se dibujan en su mapa de bits teniendo en cuenta el orden Z y el anidamiento (no sé cómo llamar al anidamiento de objetos GUI)

esto es correcto.

Yo añadiría que no sólo "cada diálogo", sino específicamente un mapa de bits por experto/indicador. Es posible que haya más, pero eso queda a discreción del codificador.

Creo que cuando se tiene un diálogo que funciona en un mapa de bits, entonces se añaden ventanas modales en el mismo mapa de bits u otro diálogo en el mismo mapa de bits - una cuestión de técnica y no una cuestión de principios ahora.

Primero hacemos un modelo abstracto sin detalles, por ejemplo, qué ventanas se encuentran donde, etc.

Entonces podrá cubrir todas las diferentes características y comportamientos

 
o_O:

Saludos codificadores.

Hay una tarea interesante para hacer algo realmente útil, y creo que el crowdsourcing sería una buena opción.
En primer lugar, los resultados estarán a disposición de todos en las primeras etapas. En segundo lugar, haremos algo nuevo utilizando MQL. Y tal vez incluso pidamos a los desarrolladores de MT nuevos productos.

----

Así que aquí está la primera y básica tarea.

1. Necesitamos hacer una clase de botón (digamos GButton, prefijado con G para no confundir con los existentes).
- Hasta ahora el botón es simple con texto (sin imágenes adicionales)
- el botón se dibuja en un área determinada del lienzo
- el botón tiene un evento de clic.



---
Con el tiempo haremos los códigos en el bitbucket.

Lo estoy siguiendo con interés y me gustaría interferir un poco: imho desarrollador (como yo) invertiría en GUI lleno, si este GUI se puede dibujar no sólo por medio de la terminal. Me explico: una interfaz gráfica de usuario bonita es buena, es un plus para las ventas... pero por ahora, no se come los recursos. Sería ideal tener una biblioteca GUI que pueda cambiar el back-end. Por ejemplo, mientras que no soy demasiado analizado sobre los recursos - dejar que se dibuja por el terminal en el lienzo (demos / mercado), pero tan pronto como algo serio - dibujar a través de herramientas rápidas en el mapa de bits. Hay todo tipo de cairo (por no hablar de OpenGL) que manejan el dibujo más fácilmente.

La interfaz gráfica de usuario ideal se diseña en una aplicación independiente y se importa como XML, por ejemplo. No es una buena idea describir la ubicación de los botones y formularios de diálogo en un EA.
 
Ejemplo, esquema:

Disposición:
<sample>
   <window
     name='Sample'
     caption='Sample'
     x=0
     y=0
     width=320
     height=240
     OnClose='CloseApp'>

     <button caption='Exit' x y width height OnClick='ButtonExitClick'/>    

   </window>

</sample>
Realización de eventos:
class SampleCloseAction : public CloseAction
  {
public:
               SampleCloseAction() { SetActionName("CloseApp"); }
   virtual int Execute() { Print('Bye'); return(0); }
  };

class ButtonExitAction : public ButtonClickAction
  {
public:
               ButtonExitAction() { SetActionName("ButtonExitClick"); }
   virtual int Execute() { GUI::WindowClose('Sample'); return(0); }
  };

BaseAction *actions[];

actions[0]=new SampleCloseAction;
actions[1]=new ButtonExitAction;

GUI::WindowCreate('Sample',actions);
 
Maxim Kuznetsov:

En general, lo ideal sería tener una interfaz gráfica de usuario diseñada en una aplicación independiente e importada como XML, por ejemplo. No es una buena idea escribir el diseño de los botones y formularios de diálogo en el Asesor Experto.

allí )

llegamos a nuestra primera tarea, que haremos después de crear los elementos.

 
Maxim Kuznetsov:
En general, lo ideal sería tener una interfaz gráfica de usuario diseñada en una aplicación independiente e importada como XML, por ejemplo. No es una buena idea escribir diseños de botones y formularios de diálogo en un EA.
En este caso, lo primero que hay que hacer es escribir un parser XML rápido y bueno. Es bueno tenerlo en casa. Yo mismo utilizo una versión de CodeBase, que es demasiado lenta para algunas tareas, especialmente para las nuevas construcciones. Ya tengo todos estos parches y muletas en él. En general, ¡escribid un buen parser compañeros! Póngaselo fácil a todo el mundo.
 
Vasiliy Sokolov:
En ese caso, deberías empezar por escribir un parser XML rápido y bueno. Es algo muy práctico para tener en casa. Yo mismo estoy usando una versión de CodeBase, pero es realmente lento en algunas tareas, especialmente en las nuevas construcciones. Ya tengo todos estos parches y muletas en él. En general, ¡escribid un buen parser compañeros! Póngaselo fácil a todo el mundo.
¿Quizás sepas cómo hacer un deslizador que funcione y se dibuje completamente? Al menos en términos generales... Me gustaría entender el concepto general.
 
Реter Konow:
¿Quizás sepas cómo hacer un deslizador que funcione y esté completamente dibujado? Al menos en términos generales... Me gustaría aprender el concepto general.
Por desgracia, no puedo. Es un elemento bastante complicado incluso si se crea a partir de primitivas normales.
 
Реter Konow:
¿Quizás sepas cómo hacer un deslizador que funcione y se dibuje completamente? Al menos en términos generales... Me gustaría aprender el concepto general.

mira la clase CCanvas. todas las primitivas de renderizado están disponibles.

En segundo lugar, puedes cargar bmp para tus vacíos y barajarlos a la BitBlt en el lienzo.