Deseos para MQL5 - página 19

 

Maldita sea! al menos una palabra con sustancia en los últimos posts, es todo un barullo que no termina nunca. Olvídate de .net y dios quiera que melkosoft se interese por este ámbito, pueden hacer un lío de todo, eso no se lo puedes quitar. sí, .net es bueno... Para el desarrollador, pero para el usuario es un verdadero dolor de cabeza, empezando por el tamaño y terminando con la incompatibilidad de versiones, y cuando los desarrolladores comienzan a utilizar los frutos de los demás, el instalador quiere la segunda versión, un componente en la primera y todo lo demás - la tercera, entonces comienza la canción. Prescindamos del .net al menos.

¿Quizás deberíamos tener una sección separada para estos debates?

 
Renat:
Por favor, exprese sus deseos a MQL5.

El desarrollo de MQL5 está en marcha y es una de nuestras posiciones destacadas en la nueva plataforma comercial. Nos abstenemos a propósito de discutirlo en aras de la calma. Pero dentro de un tiempo empezaremos a publicar información sobre el nuevo lenguaje, las bibliotecas y el entorno de programación.

...

idioma


1 orientado a objetos (el deseo más fuerte)

2 lo más cerca posible de C++

2.1 estructuras ( sería bueno verlas )

3 añadir eventos

3.1 gestión de pedidos... ( toma de beneficios, stop )

3.2 error ( en lugar de sondear después de la función o juntos)

3.3 evento del temporizador ( permitiría gestionar mejor la aplicación )


...

editor

depurador visual

...

terminal

posibilidad de elegir un intervalo TF no estándar ... digamos 3 minutos o 6 horas 25 minutos, etc... es decir, escalable

Probador W1

comprobador multidivisa

probador de TF múltiple durante la visualización

 

Sería una buena idea volver a reflexionar sobre la base del límite StopLevel para las órdenes stop pendientes antes de ejecutar 5. En mi opinión, no debería ser el precio de apertura indicado de la orden (esencialmente, el precio de apertura), sino el precio de cierre de la orden de mercado correspondiente (como para las órdenes de mercado).

Ahora es posible (spread = 3, StopLevel = 3) abrir BuyStop = 1.0050 con el SL más cercano = 1.0047, TP = 1.0053. En el momento en que el pendiente se convierte en uno de mercado, la situación se vuelve técnicamente posible, cuando el BId (precio de cierre correcto) ya está en el SL. (Esta situación no se permite en el mercado original, y con razón).

Si se cambia la base de cálculo, el mismo BuyStop = 1,0050 puede tener el SL = 1,0044 y el TP = 1,0050 más cercanos. En el momento de la conversión al mercado BId estará a la misma distancia de la orden de stop. Para cerrar este mercado uno, el precio todavía tendrá que pisar 3 puntos.

 
TedBeer:

Maldita sea! al menos una palabra con sustancia en los últimos posts, es todo un barullo que no termina nunca. Olvídate de .net y dios quiera que melkosoft se interese por este ámbito, pueden hacer un lío de todo, eso no se lo puedes quitar. sí, .net es bueno... Para el desarrollador, pero para el usuario es un verdadero dolor de cabeza, empezando por el tamaño y terminando con la incompatibilidad de versiones, y cuando los desarrolladores comienzan a utilizar los frutos de los demás, el instalador quiere la segunda versión, un componente en la primera y todo lo demás - la tercera, entonces comienza la canción. Prescindamos del .net al menos.

¿Tal vez debería crear una sección separada para este tipo de debates?


La incompatibilidad de versiones se produce normalmente sólo en los desarrolladores, en ese caso, el desarrollador utiliza un software y alguien más, de lo contrario el usuario se asocia generalmente con una actualización del servicio, por lo general los administradores de mantener un seguimiento de este, los usuarios de la licencia y otros, los desarrolladores tienden a mantener un seguimiento de dicha actualización global, en cualquier caso, todos los problemas se resuelven de una manera u otra y no veo un problema global. En la mayoría de los casos no es necesario intervenir. La dependencia de la versión es algo a lo que hay que aspirar, porque si no, hay más bugs, agujero sobre agujero, eso es un hecho, en su día hubo muchos problemas con ella y sobre todo los desarrolladores, un dolor de cabeza interminable, y el usuario se convulsiona si el desarrollador no se ocupó de ello y cualquier desarrollador es sobre todo el propio usuario.

Usted está usando Windows, es importante para usted ver el funcionamiento sin errores, así que ¿por qué toma para los errores, las advertencias sobre la incompatibilidad, ¿realmente cree que los errores de los usuarios deben preocuparse por el desarrollador? ¿Y cómo vas a explicar al desarrollador dónde está el error si no hay control sobre la compatibilidad y más aún sobre los errores?

Yo, como usuario, siempre me he esforzado por utilizar productos más perfectos, eligiendo el que más lo es, de lo contrario puedes quedarte atrás en la vida y perder aún más tiempo, pero como desarrollador me fijo también en muchos otros factores. Tu escribes en MQL, yo no escribo en MQL, aunque uso MT y conozco MQL, pero por eso no lo hago. Cada uno elige su camino, mientras tu solo esperas a los desarrolladores, lo que te falta, ya lo tenemos para nosotros, estamos tratando de desarrollarlo en un círculo estrecho :) Básicamente no tengo nada más que hacer aquí y puede que no aparezca por aquí, hasta que haya una nueva construcción y una nueva versión de la MT. Sin embargo, si no se participa en las discusiones, se puede descuidar un área importante y perder aún más tiempo, precisamente en vano, ya que todo debe ser rediseñado y adaptado al nuevo nivel de alguna manera inimaginable, hay que considerar literalmente todo, para deshacerse de tal problema lo más rápido posible al pasar a una nueva versión.

Literalmente me estás diciendo que renuncie a todo y me conforme con lo que hay, como dicen, que Dios provee, el resto es tu problema, no pasa, en cualquier desarrollo se necesita tiempo y dinero y sobre algunos dichos que Dios provee, simplemente no puedes pensar, necesitas empujar la idea por cualquier medio.

 

TedBeer escribió (a):..., Andy_Kon escribió (a):..., pxx escribió (a):..., xnsnet escribió (a):.

Voto por la "tolerancia religiosa". :)

Sobre el tema:

Lenguaje - Las excepciones también estarían bien.

 
YuraZ:

1 Orientación al objeto (deseo más fuerte)

Probablemente sea lo más acertado. Una persona acostumbrada a la programación orientada a objetos (OOP) lo pasa mal con los lenguajes orientados a procedimientos.
 

Para acelerar la depuración, necesitamos añadir etiquetas y trazas (como en los viejos lenguajes procedimentales). Y también - tenemos que proporcionar la capacidad de llamar a un EA desde otro (ejecutable Ex4).

Igor

 

En la ventana del probador y del terminal deben añadirse todas las columnas que caracterizan la orden - MN y el comentario.

En el probador más libre a través de casillas de verificación (útil para ahorrar recursos):
- emitir/no emitir ningún mensaje al juranal;
- sacar todo/saltar todo menos el último centenar;
- mostrar/no mostrar gráficos;
- mostrar/no mostrar resultados.

En la ventana de gestión manual de pedidos, marque la opción
- para activar/desactivar el lado izquierdo;
En el lado izquierdo, mostrar (con pestañas o marcas)
- gráfico de garrapatas;
- visión general del mercado;
- ventana de datos;
- mostrar información útil de un programa de aplicación en ejecución;
- variaciones.

 

Hacer posible la salida del indicador en la ventana con el gráfico o en una ventana separada - debajo del gráfico - seleccionando la casilla [v], sin recompilar.

También sería bueno permitir la selección de elementos separados(herramientas gráficas) de un indicador en la ventana con el gráfico y en la ventana debajo del gráfico por ticking.

Supongamos que el Pitchfork de Andrews se muestra en la ventana con el gráfico, mientras que algunos elementos calculados del mismo indicador, por ejemplo, las marcas de tiempo deben mostrarse en la ventana debajo del gráfico, por ejemplo, como el histograma.

==============

Las ventanas para la salida del indicador o los elementos del indicador por separado también deben poder seleccionarse estableciendo el número de la ventana en la que debe mostrarse la salida.

 
nen:

Las ventanas de visualización del indicador o de los elementos individuales del indicador también pueden seleccionarse especificando el número de ventana en el que debe producirse la salida.

Sí. Y permite cambiar el orden de las ventanas de los indicadores (cuál está más arriba y cuál más abajo) tanto programáticamente como manualmente.