Mi enfoque. El núcleo es el motor. - página 145
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
Supongo que cada flujo hacia y desde el motor debe tener algún tipo de rasgo de flujo, una especie de número mágico, y un rasgo de flujo que funciona con el probador (es invariablemente único). El motor reacciona al flujo y a los asesores actualmente establecidos, los indicadores reaccionan a su atributo (número pseudo-mágico) del flujo de información.
Todo funciona bien en el probador ahora, estoy controlando el Asesor Experto en el probador desde otra ventana. Está en modo simulador.
Actualmente, los mensajes entre el EA y el motor no están vinculados a un determinado mago o nombre del EA. Significa que si el motor escribe información en un recurso, ésta será leída por cualquier Asesor Experto que haya sido configurado para la comunicación. Para separar los flujos de comunicación, cada EA tiene que definir una etiqueta especial en la cabecera del mensaje. Y luego, o bien lee y sigue las instrucciones o las ignora. Debería haber una etiqueta separada para los Asesores Expertos en el probador.
Pero aquí vemos la necesidad de una GUI universal para el motor a través de la cual podemos configurar y cambiar las comunicaciones. También para recibir información sobre los Asesores Expertos.
Por lo tanto, tenemos que cambiar el concepto de los EA. Para ser más precisos, tenemos que actualizarlo.
Este es el inconveniente.
Tenemos que tener una GUI personalizada para cada EA o una GUI común para todos ellos. Si es común, entonces debería ser invariable. Tiene que estar bien pensado de antemano. Cada Asesor Experto (incluso sin la GUI), debe tener palancas internas que proporcionará al motor.
Algo en lo que pensar...
Pero aquí llegamos a la necesidad de una GUI universal para el motor, a través de la cual configurar y cambiar la comunicación. También, para recibir información sobre los EA.
Simplemente se necesita una parte administrativa necesaria y suficiente, permanentemente diseñada y configurada en el motor, que se ocupe de la administración del control y la más variada parte personalizada, construida según el proyecto del cliente.
Basta con que haya una parte administrativa necesaria y suficiente, permanentemente diseñada y configurada en el motor, que se ocupe de la administración de la gestión y de una gran variedad de partes personalizadas, construidas según el proyecto del cliente.
Esta parte administrativa no es comprensible. ¿Qué se supone que es?
Si el motor funciona con un Asesor Experto, eso es una cosa. Y si funciona con varios diferentes, eso es otra cosa.
Sigue faltando un marco conceptual...
Esta es la parte administrativa que no está clara. ¿Qué debería ser?
Si el motor funciona con un EA, es una cosa. Si funciona con varios diferentes, esa es otra.
Hasta ahora, falta un marco conceptual...
Digamos algo así.
Y en el Asesor Experto o indicador en la configuración de inicio, el mismo campo "Objeto 1", etc.
Supongamos algo así.
Y en el EA o indicador en la configuración de inicio el mismo campo "Objeto 1" etc.
Me pregunto. ¿Quiere decir que debemos cambiar la conexión con estos botones? Pero, en este caso, todos los Asesores Expertos deben ser copias de un EA que se ejecuta en diferentes pares.
¿Y si los Asesores Expertos son diferentes?
Digamos algo así.
Y en el EA o indicador en la configuración de inicio el mismo campo "Objeto 1", etc.
Lo pondré en práctica primero. Con un EA en diferentes pares. Y luego ya veré cómo tratar con diferentes EAs.
Por cierto, aquí hay una buena demostración de cómo trabajar con el constructor. Dinámica, sin palabras y con música. :)
CREACIÓN DE VISUAL STUDIO
https://www.mql5.com/ru/blogs/post/712102
Por cierto, aquí hay una buena demostración de cómo trabajar con el constructor. Dinámica, sin palabras y con música. :)
ESTUDIO VISUAL
Original.
Digamos algo así.
Y en el EA o indicador en la configuración de inicio el mismo campo "Objeto 1", etc.
Estos están marcados como conectados al control. Y sólo hay un objeto que se controla. Así que hay un interruptor de palanca en algún lugar con una gran indicación.
Estos están marcados como conectados al control. Pero hay un control que se controla específicamente. Así que hay un interruptor de palanca en algún lugar con una gran indicación.
Cada EA tiene su propia copia del núcleo de parámetros. Puede desconectarse temporalmente de la GUI común y conectarse al motor mediante otro EA. Es importante que sean copias del mismo EA.
Sin embargo, aquí hay algunas dificultades que yo mismo no comprendo del todo.
En teoría, la pregunta suena así:
¿Por qué necesitamos añadir un motor con GUI para cada gráfico de una copia del EA si podemos hacer un motor con el GUI común y conectarlo a todas las copias del EA?
En la práctica, encontraremos algunas dificultades técnicas.
La copia del Asesor Experto puede escribir nuevos valores en su copia del núcleo de parámetros. Si una de las copias no se conecta al motor, el núcleo sólo cambiará en el lado de la copia. Por lo tanto, al volver a conectar, tenemos que pasar todo el núcleo al motor y éste volverá a dibujar todos los elementos en todas las ventanas donde sea necesario. En principio, esto es posible.
O rehacer el propio núcleo de parámetros convirtiéndolo en un recurso. En ese caso, el motor recibirá todos los cambios a la vez y sólo redibujará los elementos. No es una mala idea.
Pero, ¿qué nos aporta?
Tal vez reduzcamos la carga de la CPU y liberemos hilos. Si tenemos 10 copias de EA corriendo en 10 pares y cargamos cada motor con GUI, la carga total de la CPU puede ser demasiado. Porque cada GUI requiere redibujar los elementos, lo que supone una gran carga para la CPU. Pero en realidad sólo podemos ver una GUI concreta de una copia. Los otros están ocultos.
Así que probablemente sea el camino correcto. Haz un motor común.