Realización de un proyecto crowdsourced en Canvas - página 34
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
La aplicación está separada, la GUI está separada.
Pero el procesamiento de los datos deducidos en la GUI se realiza de todos modos de forma sincrónica.
Por ejemplo, la aplicación envía 10000 elementos a GUI y GUI procesa todos estos elementos secuencialmente.
Este es el problema. Es necesario paralelizar el procesamiento de los elementos entrantes y su salida en la GUI. Base, texto, icono.
Además, hay tres ciclos por célula.
Así es. Pero, en las circunstancias actuales, el procesamiento en paralelo es inconveniente. Necesitamos conectar más EAs o servicios. Resultará una aplicación engorrosa e inconexa.
Hay una forma basada en los gráficos de objetos. No me he puesto a ello, pero puede ayudarme a crear varios hilos. Tiene algo que ver con las plantillas...
Entiendo el punto, la aplicación está separada, la GUI está separada.
Pero el procesamiento de los datos de salida en la GUI se realiza de forma sincrónica de todos modos.
Así, por ejemplo, la aplicación envía 10000 elementos a la GUI y ésta procesa todos estos elementos secuencialmente.
Este es el problema. Es necesario paralelizar el procesamiento de los elementos entrantes y su salida en la GUI. Base, texto, icono.
Tanto más cuanto que hay tres ciclos por una célula.
Es poco probable que esto funcione. Incluso el winda procesa la interfaz en un solo hilo. De lo contrario, las ventanas y los controles no tendrán prioridad. Sólo la propia interfaz gráfica de usuario y el procesamiento de los distintos datos pueden dividirse en hilos. De facto, ni siquiera se permite cambiar los datos en los controles desde otro hilo. Un diálogo debe ser siempre coherente, por lo que cualquier renderización y reacción de cualquier diálogo es estrictamente en un hilo, es decir, todo ocurre de forma sincrónica.
Todas las operaciones en MT son estrictamente sincrónicas y esto no puede cambiarse realmente a menos que los desarrolladores añadan hilos a la aplicación.
Es bastante sorprendente que los desarrolladores traten de ampliar la funcionalidad de MT en términos de trabajo con bases de datos, con python, con sharpe... pero ofrecen hacerlo todo en el mismo hilo...
Es simplemente increíble.
Estoy de acuerdo con la sorpresa.
La única salida es ver una dll con funciones asíncronas para sus aplicaciones.
Pero tales aplicaciones no pueden ni siquiera colocarse en el kodobase, porque la dll no está permitida.
Es poco probable que esto funcione. Incluso la interfaz de Windows se maneja en un solo hilo. De lo contrario, las ventanas y los controles no tendrán prioridad. Sólo la propia interfaz gráfica de usuario y el procesamiento de los distintos datos pueden dividirse en hilos. De facto, ni siquiera se permite cambiar los datos en los controles desde un hilo diferente. Un diálogo debe ser siempre coherente, por lo que cualquier renderización y reacción de cualquier diálogo se realiza estrictamente en un hilo, es decir, todo ocurre de forma sincrónica.
Me parece que todo saldrá bien, sólo hay que pensar de antemano en la prioridad del procesamiento asíncrono de datos.
Es decir, construir un esquema de procesamiento asíncrono, con procesamiento síncrono.
Estoy de acuerdo, con sorpresa.
La única salida es serrar una dll con funciones asíncronas a tus aplicaciones.
Pero estas aplicaciones no pueden ni siquiera colocarse en un kodobase porque la dll no está permitida.
De hecho, todavía no es necesario paralelizar el procesamiento de eventos de la interfaz gráfica de usuario. Si las tablas de 1000 celdas funcionan relativamente rápido incluso en MT4, hay velocidad más que suficiente para el resto de los eventos. En mi consulta no hay ralentización. Si necesitas una animación súper rápida, puedes conectar OpenCL. MT5 tira de la GUI normal perfectamente. No hay ningún problema. Acabo de demostrar que hay que estar muy atento al rediseño del lienzo.
Si el propio Asesor Experto incluye cálculos pesados, la frecuencia de salida de datos en la GUI puede reducirse. El redibujado de una ventana grande puede alcanzar los 100 ms, pero suele ser mucho menos. Por lo tanto, un retraso de 100ms en la GUI sólo puede ser perceptible con cálculos de EA MUY pesados.
Estoy de acuerdo, con sorpresa.
La única salida es ver una dll con funciones asíncronas para sus aplicaciones.
Pero estas aplicaciones no pueden ni siquiera colocarse en un kodobase porque la dll está prohibida.
Se pueden hacer muchas cosas a nivel de DLL.
Eso es todo lo que MT no está diseñado y puede+debe+hacer allí :-)
No se puede controlar el dll, por eso no está en el mercado. Por cierto, puedes encontrar dlls en kodobase. Tal vez lo hayan prohibido ahora por alguna razón.
PS por cierto pregunta curiosa - DLL puede ser firmado con la clave del desarrollador. Es posible permitir tal DLL en el mercado y kodobeise también, pero será atado a la infraestructura de Microsoft. ¿Alguien está dispuesto a comprar una licencia de este tipo para Visual C?Estoy de acuerdo, con sorpresa.
La única salida es ver una dll con funciones asíncronas para sus aplicaciones.
Pero estas aplicaciones no pueden ni siquiera colocarse en un kodobase porque la dll está prohibida.
Sí, ese es el principal problema. El mismo mercado prohíbe el uso de dlls, por lo que hay que reinventar la rueda. Ok, si alguien piensa que la GUI no es necesaria, pero cualquier cálculo largo y complejo en cualquier caso en un hilo no funcionará, ¡todo se colgará! Así que hay que hacerlo en un dll... que está prohibido en el mercado...
Y así sucesivamente. Por esta razón tengo que dibujar y resolver todo con métodos mql.
De hecho, la separación de la GUI y la lógica en hilos es, por supuesto, ya posible. Aquí los chicos ya han discutido el tema del paralelismo https://www.mql5.com/ru/forum/288985/page5#comment_14722396.
Como resultado, el formulario en sí podría dejarse en el hilo principal, como se hace en winnda, mientras que cualquier cálculo adicional podría trasladarse a la ejecución en "segundo plano". Así es como funcionan windows, linux y android.
Se pueden hacer muchas cosas a nivel de DLL.
Para eso no está la MT y puede+debe+hacer :-)
No puedes controlar el dll, por eso no está en el mercado. Por cierto, tenemos dlls en kodobase. Tal vez lo hayan prohibido ahora debido a algún alboroto.
PS por cierto pregunta curiosa - DLL puede ser firmado con la clave del desarrollador. Es posible permitir esas DLL en el Marketplace y en Kodobeise también, pero estará ligado a la infraestructura de Microsoft. ¿Alguien está dispuesto a comprar una licencia de este tipo para Visual C?Sí, no puedes controlar la dll, pero podrías permitir que las mismas bibliotecas de viento...
Ni siquiera vayas tan lejos: ¡incluso como parte de una biblioteca estándar hay funciones para acceder a winAPI! ¿Pero qué sentido tiene? Después de todo, no se puede poner en el mercado....
Bien, con toda esta charla nos metimos en otra inundación.
Hay muchas cosas que se pueden hacer a nivel de DLL.
Para esto no está pensada la MT y puede+debe+hacerse allí :-)
No puedes controlar el dll, por eso no está en el mercado. Y en kodobase, por cierto, puedes encontrar dlls. Tal vez lo hayan prohibido por alguna razón.
PS por cierto pregunta curiosa - DLL puede ser firmado con la clave del desarrollador. Es posible permitir esas DLL en el Marketplace y en Kodobeise también, pero estará ligado a la infraestructura de Microsoft. ¿Alguien está dispuesto a comprar una licencia de este tipo para Visual C?¿Por qué debería vincularse a la infraestructura de Microsoft?
Creo que se puede utilizar absolutamente cualquier clave para firmar una dll, siempre que esté controlada por MQ.
De ello se deduce que estas claves deben ser emitidas por MQ, y controlan la cantidad de hash de la aplicación.
¿Por qué deberían atarse a la infraestructura de Microsoft?
Creo que se puede utilizar cualquier clave para firmar una dll, siempre que esté controlada por MQ.
De ello se deduce que estas claves deben ser emitidas por MQ, y controlan la suma de hash de la aplicación.
pero porque microsoft es el que manda en este hormiguero :-)
¿Por qué crees que la gente pierde sus datos de acceso al actualizar y activar productos en vinilos piratas?