Si MetaTrader 6 sale mañana - página 3

 
Urain:
Quiero opciones a MT, con todos los deltas y engaños.
MT5 lo soporta. Pero pasarán años antes de que los corredores lo hagan bien.
 
Acabo de recordar, que hay una solicitud para hacer una diferencia en el color de los niveles de parada para las posiciones de compra y venta, la demanda y la oferta se establecen por separado, por lo que los niveles de parada activados por ellos también deben establecerse por separado.
 
Y también ha habido una petición de larga data para hacer un análisis de avance en el probador.
 
Realice la formación NS en el probador.
 
Urain:

Me gustaría que el probador se dividiera en dos partes, probador-optimizador rápido y probador-depurador preciso (debería incluir también el visualizador).

El optimizador sólo comprueba la rentabilidad de las señales de los indicadores, el depurador comprueba la precisión de la ejecución.

Parece que es necesario separarlos hace mucho tiempo, incluso sin el depurador. // El uso del probador y del optimizador desde un mismo botón es un coñazo, la usabilidad es baja.

¿Qué puede aportar en la práctica?

1. pruebas hasta el minuto actual.

Si es comprensible limitar el optimizador de esta manera, ¿por qué limitar las pruebas?

Creo que ahora se debe al excesivo pegado de probador+optimizador, estoy empezando a ver todo tipo de horrores de la serie:

"Renat: - ¿Sugieres inundar servicedesk con peticiones que los resultados de la optimización no coinciden con los resultados de las pruebas?" :)))

2. La posibilidad de probar a fondo las implementaciones individuales de los conjuntos de parámetros sin interrumpir el proceso de optimización, una característica muy útil.

3. Por último, llame para probar y optimizar directamente desde los Asesores Expertos que trabajan en los gráficos (desde MQL).

El último argumento "en contra" mencionado por los desarrolladores: "¿Cómo probar los EA autooptimizados? Cuando el comprobador y el optimizador se implementan por separado, la recursividad se evita fácilmente prohibiendo que el optimizador llame al comprobador, pero permitiendo que el optimizador sea llamado desde el comprobador.

4,5,6.... Puedo dar muchos más argumentos, pero cualquiera de ellos será suficiente.

Urain:
Y también desde hace mucho tiempo hay una solicitud para hacer el análisis Walk-Forward en el probador.
 
C-4:
Por ejemplo, en C#. Al intentar enlazar una función o una variable, el compilador generará un error, porque la función o la variable son conceptos de un nivel inferior y sólo pueden colocarse dentro de una clase o estructura. Y en MQL5, parece haber cierta confusión - hay clases, pero también hay funciones que llaman a estas clases, y debería ser al revés: muchas clases se comunican entre sí a través de métodos soportados por ellas.
Entendido. Estoy de acuerdo en que la ideología de C# es mucho mejor que la de C++, pero es la orientación del partido hacia ++. No estoy seguro de que tenga sentido manifestarse sobre este tema, aunque seguro que es inútil.
 
Me gustaría ver algo tan pequeño como un evento de pulsación de ratón o de tecla, además de los eventos de pulsación ya existentes.
 

1 Gráficos. Mejorar la usabilidad de la carta, los objetos gráficos... Quiero una sombra para las etiquetas de texto. Y estilos con puntos para ser dibujados con puntos... Y ventanas de gráficos que se dibujan detrás del terminal, y ventana de propiedades que se estiran, y pestañas que se arrastran en la ventana de mercado. Eso es todo.

2 Historial personalizado.

3 CCA, Si se hace

Документация по MQL5: Основы языка / Препроцессор / Свойства программ (#property)
Документация по MQL5: Основы языка / Препроцессор / Свойства программ (#property)
  • www.mql5.com
Основы языка / Препроцессор / Свойства программ (#property) - Документация по MQL5
 
Urain:
Realizar la formación de NS en un probador.
Eso es poco profundo. Necesitas un optimizador genético impulsado por MQL en general. Y cualquier entrenamiento de NS estaría a distancia.
 
Urain:
Me gustaría ver una cosita así como eventos de clic de ratón o pulsación de teclas, además de los eventos de pulsación ya existentes.

Esto es superficial. Necesito ventanas normales manejadas por MQL, diálogos estándar de Windows y medios para su edición visual. Naturalmente, con un manejo completo de todos los eventos del usuario.

Lo ideal sería que toda la interfaz del terminal se implementara en mql6. Entonces los desarrolladores seguramente no echarán de menos consultas tan claras del programador a las funciones de la interfaz.