Mi enfoque. El núcleo es el motor. - página 146
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
Реter Konow:
...
No es una mala idea.
Pero, ¿qué nos aporta?
Quizá 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.
En MT5 los gráficos se pueden separar. Y entonces hay que volver a idear el concepto.
Cada EA tiene su propia copia del núcleo de parámetros. Se puede desconectar temporalmente de la GUI común y conectar otro EA al motor. Es importante que sean copias del mismo EA.
Sin embargo, hay algunas dificultades, que yo mismo aún no he comprendido en su totalidad.
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, nos encontraremos con 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 el motor 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.
Deje que las copias de EA le digan al motor su dirección con frecuencia. Una cadena corta. El motor reaccionará y "hablará" con la copia que tenga la misma dirección que la actual. El intercambio estándar se llevará a cabo. Si la dirección cambia en el motor, comienza a "intercambiar" con la copia que establece la dirección correspondiente. Al intercambio estándar a 'éter' añade asesores o indicadores para exponer su dirección corta. Varios bytes. Y la función "escuchar las direcciones del motor se inicia cuando el usuario pulsa el botón "reconfigurar" en la GUI del motor. Tal vez sea algo así.
En MT5 se pueden separar los gráficos. Y entonces hay que volver a idear el concepto.
Sólo que no soy consciente de ello. La carta se desprende puramente "territorial", se libera de las coordenadas de la ventana principal del terminal? En los flujos de intercambio, ¿sigue conectado al terminal en su totalidad?
Sólo que no soy consciente de ello. La carta se desprende puramente "territorial", se libera de las coordenadas de la ventana principal del terminal? Y en los flujos de intercambio con el terminal, ¿sigue conectado al terminal en su totalidad?
El gráfico se desprende, pero no cambia la esencia. (Se están haciendo un lío para nada). No tiene sentido hacer copias de la GUI para cada copia del EA. No que yo pueda ver, al menos. Pero sería genial poder mover una GUI entre los gráficos de las copias.
Si hay un gráfico del centro de control de la copia de EA con el motor y la interfaz gráfica de usuario principal ubicado en él, sería útil.
La interfaz gráfica de usuario del EA debe hacerse con la expectativa de que el EA tendrá muchas copias colocadas en diferentes instrumentos.
SZY. El gráfico permanece en la misma ventana, sólo se puede "sacar" la propia ventana, desde el terminal.
Que las copias de los asesores le digan al motor su dirección con frecuencia. Una cadena corta. El motor reaccionará y "hablará" con la copia que tenga la misma dirección que la actual. El intercambio estándar se llevará a cabo. Si la dirección cambia en el motor, comienza a "intercambiar" con la copia que establece la dirección correspondiente. Al intercambio estándar a 'éter' añade asesores o indicadores para exponer su dirección corta. Varios bytes. Y la función "escuchar las direcciones del motor se inicia cuando el usuario pulsa el botón "reconfigurar" en la GUI del motor. Tal vez sea algo así.
Usted ve la esencia correctamente. Sólo que los detalles no son exactos.
Cambiar la "comunicación" en sí, no es un problema. Pero, al cambiar, hay que reiniciar toda la interfaz gráfica de usuario. Al fin y al cabo, en las ventanas y elementos de diferentes copias, diferentes valores. Por lo tanto, es necesario rediseñar casi todo.
Los valores de los parámetros de cada copia se almacenan en el núcleo de parámetros. Esto es una matriz. Mientras la copia esté desconectada del motor, los cambios de valores sólo se producirán en la copia del Asesor Experto del núcleo de parámetros. Tan pronto como se conecta el motor, todo debe ser transferido a él desde este núcleo. Sincronizar las copias del Núcleo de Parámetros en el Motor y en el Asesor Experto conectado. Por lo tanto, es necesario transferir una gran cantidad de información (núcleo de parámetros), y volver a dibujar las ventanas. Después de eso, será posible ajustar el Asesor Experto conectado y los demás pasarán al modo independiente. Entonces se conectará con ellos y ocurrirá lo mismo.
Será así. Sin embargo, hay muchos matices técnicos.
Peter. Con un periodo de N ms el EA recibe algo del motor, y después pasa su algo preparado al motor. A continuación, el asesor espera la llegada de la garrapata o de una nueva tanda de interrogación-interrogación. ¿Verdad?
Casi correcto. La comunicación y la anticipación de los tics, u otros eventos, se producen de forma asíncrona.
El horario se desprende, pero no cambia el punto. Es una pérdida de tiempo).
...
SZY. El gráfico permanece en la misma ventana, sólo se puede "sacar" la propia ventana, desde el Terminal.
Y de acuerdo con su concepción de que sólo un gráfico actual es visible a la vez de todos modos, y sólo se puede actualizar, se romperá - habrá tantos gráficos visibles como se desprenden.
Ciertamente no es una pesadilla, pero tampoco es bueno - sólo uno de los gráficos visibles "vivirá", ¿y el resto?
¿Cree que esto es normal? Pues si es así, una vez más me convenzo de la falta de seriedad a la hora de solucionar los bugs, si es que la hay, no es para arreglarlo, sino para ocultarlo.
Casi correcto. La comunicación y la espera de un tick, u otros eventos, se producen de forma asíncrona.
¿Qué tal esto? Los asesores, cada uno con frecuencia alguna (OnTimer), envían al motor su cadena de código. Todas las líneas de código son diferentes. El motor analiza internamente las cadenas entrantes y "reconoce" una, por ejemplo la del Asesor Experto número 3. En respuesta a este EA, envía una "señal" para iniciar la transmisión principal. El motor funciona con este Asesor Experto.
Si una persona pulsa el botón Switch, el motor analizará a los asesores permitidos, y se indexarán, bajo números. Indica al EA actual que pase al estado de establecer una dirección, como si lo apagara desde el flujo de trabajo, selecciona una cadena de código con el índice por 1 más y espera la llegada de la misma cadena de código desde cualquier otro EA. Cuando la dirección coincide, envía una señal al Asesor Experto para que deje de exponer la dirección e inicie el intercambio. El único Asesor Experto y la serie de copias, que no está en modo de facturación, recibirán el intercambio. En resumen, algo así como.
Si el motor recibe una dirección, hace un timeout para prohibir la recepción de direcciones. Para que las direcciones no se superpongan.
¿Qué te parece esto? Los Asesores Expertos, cada uno con una frecuencia de algún tipo (OnTimer), envía al motor su propia cadena de códigos. Todas las líneas de código son diferentes. El motor analiza internamente las cadenas entrantes y "reconoce" una, por ejemplo la del Asesor Experto número 3. En respuesta a este EA, envía una "señal" para iniciar la transmisión principal. El motor funciona con este Asesor Experto.
Si una persona pulsa el botón Switch, el motor analizará a los asesores permitidos, y se indexarán, bajo números. Indica al EA actual que pase al estado de establecer una dirección, como si lo apagara desde el flujo de trabajo, selecciona una cadena de código con el índice por 1 más y espera la llegada de la misma cadena de código desde cualquier otro EA. Cuando la dirección coincide, envía una señal a este Asesor Experto para que deje de exponer la dirección e inicie el intercambio. El único Asesor Experto y la serie de copias, que no está en modo de facturación, recibirán el intercambio. En resumen, algo así como.
Si el motor recibe una dirección, se agotará el tiempo de inhibición de la dirección. Para que las direcciones no se solapen.
Este no es el enfoque correcto. Déjeme explicarle:
Cada copia de EA no deja de escribir sus mensajes al motor en su propio recurso separado. Al mismo tiempo, cada copia del EA inicializa los valores de sus propios elementos en su copia de los parámetros del núcleo. Es decir, incluso cuando se desconecta del motor, todas las copias del EA deberían funcionar correctamente.
Cuando el motor cambia de conexión entre las copias del EA, debe sincronizar los parámetros de su núcleo con el núcleo del EA conectado. Después, redibuja los elementos en las ventanas, para que muestren la información real.
En cuanto a la comunicación con el Asesor Experto seleccionado, todo es sencillo. El recurso para recibir mensajes del motor (así como el recurso de mensajes para el motor), cada EA tendrá el suyo. Es decir, el motor se limitará a grabar sus mensajes en el otro recurso, y a leer los mensajes del otro recurso. Ese recurso pertenece a la EA conectada.