Deseos para MQL5 - página 28

 

tal vez esto ya se ha dicho....

1) añadir la capacidad de compilar cuando está encriptado y con la capacidad de generar un número de serie vinculado a un ID de ordenador (análogo a armandillo packer),

todo esto debería hacerse internamente dentro del traductor y no desde el código fuente

2) Añadir la posibilidad de trabajar de forma interactiva con programas externos lo que permitiría gestionar el terminal desde otros programas, conectar/desconectar al servidor, comprobar la conexión con el servidor, solicitar el archivo de cotizaciones, realizar el pedido... etc.

3) posibilidad de colocar órdenes independientemente de los ticks entrantes

4) Apoyo al trabajo simultáneo con varios DTs/cuentas

5) Reactivar la depuración de la DLL

6) Al menos añadir soporte para estructuras, en general sería deseable ampliar las posibilidades, para que sean más similares a c++

 

Es necesario añadir un enlace ejecutable a la ayuda que proporciona el programa (por ejemplo, para abrir una ventana con el texto deseado) y a la página web.

Si el usuario hace algo incomprensible, el programa le dice: aquí tienes una consulta sobre la situación, léela bien y no vuelvas a hacer ninguna tontería.

 

SK,

Por ejemplo, debe establecer TP=2 y SL=10 una vez y luego sólo comprar o vender, es decir, el pipsing será muy conveniente. Debido a este inconveniente, recientemente he hecho un Asesor Experto especialmente para establecer TP y SL con los valores especificados después de hacer clic en Comprar o Vender.

 

¡Muchos deseos para todo! ¡28 páginas ya!

Me gustaría que los desarrolladores me dijeran qué deseos están ya en desarrollo, cuáles no se aplicarán nunca y cuáles sí.

Por lo demás, no está claro si debemos desear otra cosa, no vemos ninguna respuesta.

Por supuesto, también queremos saber el momento. Entiendo que predecir las condiciones de lanzamiento de un software no es a veces más fácil que predecir el movimiento de los tipos de cambio.

Al menos en esta forma: "La versión beta de MT5 se lanzará no antes de .............". ¿Es posible escribir una frase así?

 
Better:

Por lo demás, no está claro si se puede desear algo más, no se ve ninguna reacción.


Bueno, el hecho de que el tema se haya arreglado indica que los desarrolladores lo consideran útil :)
 
¿Se ha hablado de reasignar a Magic en una orden activa? La idea es simple: en el comercio multiperiodo será posible pasar la orden a un marco temporal superior cuando haya una tendencia larga.
 
Cronex:
¿Se ha hablado de reasignar a Magic en una orden activa? La idea es simple: en el comercio multiperiodo será posible pasar la orden a un marco temporal superior cuando haya una tendencia larga.
¿Puede ser un poco más específico? ¿Qué quieres decir?
 
SK. писал (а):
Cronex:
¿Se ha hablado de reasignar a Magic en una orden activa? La idea es simple: en el comercio multiperiodo será posible pasar la orden a un marco temporal superior cuando haya una tendencia larga.
¿Puede ser un poco más específico? ¿Qué quieres decir?

En resumen: utilizo la misma estrategia de trading para 4 periodos, es decir, principios de entrada/salida/salida utilizando un algoritmo (un conjunto de indicadores y tipos de señales), pero los parámetros de los indicadores son diferentes para cada periodo (en realidad son 4 EAs en un gráfico), división por Magic. El resultado es el siguiente: en los plazos más bajos todo indica que hay que cerrar las posiciones mucho antes de lo que realmente merece la situación del mercado (es decir, cualquier giro hacia el lado equivocado se traduce en una toma de beneficios), aunque en los plazos más altos la situación es muy estable. Afecta a la volatilidad relativa de los indicadores. Creo que la idea es clara: si se producen situaciones estables en los plazos senior, no se deben cerrar las posiciones abiertas en los junior, sino que al cambiar de Magic se deben pasar a la lógica de los plazos senior. En realidad, la aplicación se utiliza no sólo para los plazos, sino para transferir a otra lógica de procesamiento. Me parece que no habrá problemas para la empresa de corretaje, porque el billete se mantiene, y el beneficio se puede encontrar.
 
Cronex:
En resumen: utilizo una única estrategia de trading para 4 periodos, es decir, principios de entrada/salida/retroceso utilizando el mismo algoritmo (un conjunto de indicadores y tipos de señales), pero los parámetros de los indicadores son diferentes para cada periodo (en realidad son 4 Expert Advisors en un solo gráfico), división por Magic. El resultado es el siguiente: en los plazos más bajos todo indica que hay que cerrar las posiciones mucho antes de lo que realmente merece la situación del mercado (es decir, cualquier giro hacia el lado equivocado se traduce en una toma de beneficios), aunque en los plazos más altos la situación es muy estable. Afecta a la volatilidad relativa de los indicadores. Creo que la idea es clara: si se producen situaciones estables en los plazos senior, no se deben cerrar las posiciones abiertas en los junior, sino que al cambiar de Magic se deben pasar a la lógica de los plazos senior. En realidad, la aplicación se utiliza no sólo para los plazos, sino para transferir a otra lógica de procesamiento. Me parece que no habrá problema para DC, porque el billete se queda, y podemos obtener algún beneficio.


El significado es claro.

Pero no creo que sea necesario cambiar el lenguaje y la tecnología de comunicación entre el terminal y el servidor por esta idea. Al fin y al cabo, todo lo que necesita puede ser contabilizado en el programa del lado del terminal. Además, la propia idea de cambiar el majik es una prueba elocuente de la estrategia subdesarrollada, su criterio. La magia (como muestra claramente tu ejemplo) no soporta ni puede soportar un criterio fijo para cerrar o abrir una orden. Simplemente porque un majik no está relacionado con el mercado de ninguna manera.

En mi opinión, éste es uno de los puntos clave del comercio. Por casualidad teníamos un magik en nuestras manos, y nos atamos a él. De hecho, deberíamos considerar la situación en cada nuevo tick como una nueva sin ninguna historia previa (historia de eventos en la cuenta del juego, incluyendo la hora y el precio de las órdenes de apertura del mercado).

Y la magia es, aunque en parte útil, pero en mi opinión, no un mecanismo muy conveniente para seguir... quién sabe qué. Creo que si se pudiera identificar una orden de forma única (en la reapertura y el cierre parcial), la marca mágica dejaría de tener sentido en absoluto.

 
SK. писал (а):


El punto es claro.....

Intentaré dar algunos argumentos, empezaré por el final...

En mi opinión, si aceptamos la orden como un objeto, entonces la magia en este momento es una propiedad totalmente variable de este objeto desde el punto de vista de la programación, así como los niveles de SL o TP. Puede que me equivoque pero actualmente es imposible identificar claramente una orden en MQL en relación con un código ejecutado en el terminal en todas las etapas posibles de su vida (durante la reapertura y el cierre parcial) y la magia compensa en gran medida esta situación. La magia no debe ir unida al mercado, simplemente tiene otra aplicación y no tiene sentido más que por su significado.

No estoy de acuerdo contigo en tu postura de ver la situación del mercado como algo sin historia... Pero esta es mi opinión. Si la orden es rentable debemos mirar el marco temporal superior para tomar una decisión y esperar un pequeño pullback y seguir trabajando con la orden en un marco temporal superior o simplemente cerrarla ya que no será rentable.

No voy a discutir sobre la solidez y la pobreza de la estrategia, estoy totalmente de acuerdo... Pero estoy trabajando en ello :-)

Cambiar el idioma y el protocolo de intercambio entre el servidor y el terminal, pues no sé... Por el momento el valor majic ya está ahí y es aceptado por el servidor al realizar un pedido. Desconozco el formato del protocolo de intercambio, pero sospecho que se trata de la transmisión por lotes de alguna estructura de datos a través del transporte con la posterior verificación de la consistencia. Creo que no es demasiado difícil añadir un parámetro opcional más a la estructura de datos transmitida por OrderModify. Dudo mucho que los desarrolladores hayan tomado el camino del protocolo de intercambio atómico y se hayan enfrascado así en el pesado proceso del soporte de versiones.

Pero en general sólo he preguntado por los planes :-) No, no.

Razón de la queja: