¿Cómo crear objetos de forma dinámica? (Algunas cosas de POO) - página 5
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
2. Framework from scratch.
Similar here. When I started to go a bit deeper into the standard libraries I found many things, which I did not like. Not only the bad performance of those, but also lack of flexibility and also because of an incomplete architecture. I am missing for example a global CMouse class/object as well as a class between CWnd and CObject, because CWnd objects are childs of the chart as well as lines are, and there is no connection to such and no final implementation of any such objects at all like I described it above. And, there is no master object, which holds all such chart objects which makes it possible to show/hide all of them with one command, destroy them, whatever. CCanvas, same thing, a nice class but where is the implementation with CWnd which allows me to create interactive objects based on bitmaps that inherit from CWnd? And so on.
¿Cuál es el papel de un CMouse global? ¿Sirve al usuario final como una clase independiente solamente, para obtener un fácil acceso a la gestión del ratón? ¿Qué relación tiene con el framework?
Sobre la clase entre CWnd y CObject, no sigo tu explicación de por qué los consideras necesarios. Los objetos CWnd son hijos del gráfico, así como las líneas - no entiendo el problema en eso, y por qué no hay conexión?
También dices que no hay ninguna implementación final de tales objetos en absoluto como describiste arriba? (¿dónde has descrito?)
La oportunidad de un objeto global del ratón es, por lo menos en mi GUI, para guardar cualquier información sobre el ratón (posición, posición de la prensa, precio de la posición, etc.) accesible para cada clase que trata con tales informaciones. Además, el objeto ratón contiene información sobre el uso exclusivo del ratón, por ejemplo, al arrastrar. Esto ahorra mucho tiempo de la CPU mientras algo es arrastrado o está a punto de ser pulsado, etc.
Por último, pero no menos importante: Nada de la librería estándar funciona en el probador de estrategias cuando se usa en los EAs porque no hay eventos de ratón. Y si quieres implementar el soporte del ratón en el probador de estrategias, también agradecerás una clase de ratón así, porque la clase no se preocupa de dónde viene la información sobre los movimientos del ratón, pero los objetos que necesitan la información todavía saben dónde tienen que buscar.
---
No es sólo la clase entre CWnd y CObject lo que me falta, es más bien el objeto/contenedor maestro que falta y que contiene los objetos basados en píxeles así como los objetos basados en tiempo/precio. Como has mencionado también, todos son objetos del gráfico, por lo que el maestro lógico debería ser un objeto que represente el gráfico y que contenga todos los objetos. Y para realizarlo, debe haber una clase entre CWnd y CObject.
El trasfondo de esta idea no es sólo la lógica, es también una cuestión de rendimiento. En mi caso, cuando el gráfico cambia de alguna manera, el objeto maestro lo detecta, hace un bucle con todos los objetos contenidos que pueden ser contenedores de líneas, contenedores de CWnd así como cualquier objeto individual de cualquiera de estos tipos, e "informa" a cualquier objeto que quiera ser informado por ello. Esto significa simplemente, que hay un solo bucle en exactamente un punto del código, y debido al uso con contenedores y sub-contenedores, esto es extremadamente eficiente.
También uso este maestro para congelar todos los objetos a la vez y evitar cualquier actualización física por una sola línea de código. La diferencia en el rendimiento es drástica. Ejemplo: Cuando creo todos los objetos visuales que necesito para mi EA, y en algunos casos son más de 1000, congelo este objeto maestro por adelantado, creo los otros objetos y lo "descongelo" después, lo que resulta en una actualización física del gráfico. Sin la congelación, este proceso puede durar un minuto entero. Con la congelación, es menos de 2 segundos.
Antes de empezar a crear el GUI por mí mismo, realmente lo probé con las librerías estándar. Más tarde, traté de mantener al menos algunas partes. Pero el problema era que simplemente era imposible realizar lo que tenía en mente debido a una implementación incompleta y una arquitectura que es un poco ... HagamosAlgoQueFuncioneDeAlgoParaNosotrosNoSabe. El rendimiento visual se alcanza con una jerarquía clara, pero las librerías estándar son en cierto modo anárquicas.
De todos modos, no soy la primera persona que reconoce esto. Y como Alain ya mencionó, no estoy seguro si esto realmente ayuda, porque es demasiado teórico. Solo puedo hablar de mi experiencia con todo esto que no se basa solo en MQL, pero mi opinion es sin embargo solo mi opinion y por supuesto no es ley.
Pero para el segundo tipo, la forma de pensar y las consideraciones discutidas aquí son muy valiosas y muy prácticas también. Por supuesto, un artículo sería mejor, pero sin embargo.
No creo que la gente va a construir marcos después de leer sólo este hilo, pero todavía tiene buenas piezas de información y conocimientos, que parece que la falta incluso para las personas que ya construyeron marcos MQL pública.
Por lo tanto, para el ratón y el probador si te entendí bien se utiliza el ::OnTester() para llamar a su ratón en lugar de una entrada de usuario, si te sigo.
Gracias de nuevo, Doerk.
La oportunidad de un objeto global del ratón es, por lo menos en mi GUI, para guardar cualquier información sobre el ratón (posición, posición de la prensa, precio de la posición, etc.) accesible para cada clase que trata con tales informaciones. Además, el objeto ratón contiene información sobre el uso exclusivo del ratón, por ejemplo, cuando se arrastra. Esto ahorra mucho tiempo de la CPU mientras algo es arrastrado o está a punto de ser pulsado, etc.
Por último, pero no menos importante: Nada de la librería estándar funciona en el probador de estrategias cuando se usa en los EAs porque no hay eventos de ratón. Y si quieres implementar el soporte del ratón en el probador de estrategias, también agradecerás una clase de ratón así, porque a la clase no le importa de dónde viene la información sobre los movimientos del ratón, pero los objetos que necesitan la información siguen sabiendo dónde tienen que buscar.
¿O me estoy perdiendo algo?
El objeto ratón no mira por sí mismo si está sobre un objeto o si está en uso por un objeto, esto lo hacen los propios objetos. Pero el objeto ratón es el "lugar" central donde se puede almacenar dicha información.
Las clases de control estándar funcionan así, que en cada movimiento del ratón todos los objetos son puestos en bucle para averiguar, si este movimiento tiene algo que ver con ellos, esto toma mucho tiempo de CPU que se puede ver fácilmente cuando se inicia el administrador de tareas y sólo se mueve el ratón cuando se carga el EA o el indicador y un objeto CDialog es parte del EA o el indicador. Cuanto más complejo sea el diálogo, mayor será el uso de la CPU.
En mi GUI, con la existencia de un objeto global del ratón, esto se hace diferente. Puedes tener 10000 objetos y el uso de la CPU no crece en absoluto cuando se mueve el ratón. Se hace de esa manera, que sólo tan pronto como el botón del ratón se bajó en un objeto específico, este objeto específico informa al objeto del ratón, que tiene el foco, y tan pronto como el ratón se mueve después de este evento de botón hacia abajo, ningún otro objeto tiene que cuidar de él, y cualquier otro movimiento del ratón / cualquier otro evento de movimiento del ratón se dirige directamente al objeto que tiene el foco - que es siempre exclusivo - mediante el uso de su puntero.
Y debido a la circunstancia de que todos los objetos gráficos, no importa si están basados en tiempo/precio (líneas de tendencia, etc.) o en coordenadas de píxeles (paneles, etc.) tienen una clase base común, todos estos objetos pueden utilizar un conjunto común de funciones sobrecargadas para manejar esto. Esa es también la razón por la que mencioné que falta una clase entre CWnd y CObject, porque esta clase base es la misma clase base que utilizan los objetos basados en tiempo/precio y sólo esto hace posible una comunicación efectiva y el manejo de tales eventos.
Sí.
Sin embargo tengo la opción de coger cualquier movimiento si se hace clic o no, y además con mejor rendimiento de la CPU y sin usar los nombres de los objetos, pero esa no era la cuestión aquí.