El lienzo es genial. - página 58

 
Dmitry Fedoseev:

No he notado esa necesidad entre los comerciantes. No estamos hablando de rentabilidad, estamos hablando de todo tipo de chucherías en un EA.

¡Y la baratija más importante de un EA es su rentabilidad potencial!

 
aleger:

Y lo más importante de un EA es su rendimiento potencial.

Ya veo, todo lo que hay que hablar... sólo para hablar.

 
Dmitry Fedoseev:

Ya veo, lo que sea que quieras hablar... sólo para hablar.

Y habla y hazlo, si tienes estómago para ello.

 
Реter Konow:
Correcto. Un EA clásico - tres indicadores para generar una señal de compra/venta, y un par de fórmulas para los stops.¿Qué más? Eso es triste.

Mejor - su propio asesor basado en el Zigzag "normal" y algunas de sus características

 
aleger:

Mejor - su propio asesor basado en el Zigzag "normal" y algunas de sus características

A cada uno lo suyo.
 
Реter Konow:
A cada uno lo suyo.

Especialmente en alemán...

 
Renat Fatkhullin:

De qué habláis todos de interfaces, cuando todo está hecho desde hace tiempo y está disponible en la biblioteca estándar como análogo de MFC, incluidos los ejemplos:


Es trivial que estés discutiendo sin conocer la existencia de una biblioteca para construir paneles ordenados y de aspecto profesional. Son en vivo, arrastran y sueltan, minimizan, reaccionan a los eventos, etc.

Qué otras estructuras gráficas cuando el embudo pierde la tasa de conversión en el primer paso "nadie sabe que hay una solución". Cualquier solución. No lo leen, no lo saben y no quieren saberlo. Y hay 13 mb de código fuente en MQL5 en la biblioteca estándar. ¿Quién en su sano juicio iría allí a buscarlo?

Es mejor discutir, dar consejos y pensar que se entiende el problema...

Renat, llevo dos años trabajando con esta biblioteca. El principal inconveniente es la discreción de los controles y sus componentes. Probablemente no has tenido la oportunidad de observar el efecto cuando los elementos del formulario se arrastran en un bucle detrás del mismo. Es un espectáculo bonito, pero no productivo. El uso del enfoque MFC para el manejo de eventos es una buena solución. Ya he escrito en posts anteriores que el esqueleto de la librería en sí es bueno, pero eventualmente necesitamos alejarnos de las primitivas discretas y dibujar el resultado final (un formulario con controles) en un solo lienzo y arrastrar y soltar un solo objeto, en lugar de un montón de objetos primitivos cambiando su posición en un bucle.

Por supuesto, se puede decir: hay una biblioteca, ¿qué más se necesita? Y tranquilízate con eso, o trata todo de esa manera. Está en su derecho.

Pero hablando de visualización y GUI nadie te está pidiendo nada, sólo es una discusión entre usuarios interesados.

 
Renat Fatkhullin:

¿Qué estáis discutiendo sobre las interfaces, cuando todo está hecho desde hace tiempo y está disponible en la biblioteca estándar como análogo del MFC, incluidos los ejemplos?

Es trivial que estés discutiendo sin conocer la existencia de una biblioteca para construir paneles de aspecto limpio y profesional. Son en vivo, arrastran y sueltan, minimizan, reaccionan a los eventos, etc.

Se me olvidó mencionar que los gráficos tienen fallos, están mal escritos y no se pueden arreglar durante años.

Hay bastantes temas sobre errores en la biblioteca gráfica estándar, pero no te interesan.

Por otra parte, el principio se establece, los análogos se escriben, y todo el mundo que quiere realmente puede terminar archivo lo que es (si quieren aprender 13 Mb de muy controvertido en algunos lugares el código fuente).

Pero la retroalimentación suele ser realmente escasa, incluso en los informes de errores no siempre hay respuestas...

 
Andrey Khatimlianskii:

Se te ha olvidado mencionar que los gráficos tienen fallos, están poco desarrollados y no se pueden arreglar desde hace años.

No creo que el rendimiento de los gráficos sea necesario para trabajar, en general es realista hacer la mayoría de los gráficos que quieres en un par de días desde el SB

Ni siquiera puedo comentar esto porque la solución es demasiado horrible para usarla en la prueba. - no quiero ni comentarlo

 
Igor Makanu:

No creo que necesites mucho rendimiento para los gráficos, en general es realista hacer la mayoría de tus aspiraciones gráficas en un par de días

No sé si hay que preocuparse por eso, pero el comportamiento de los gráficos en el probador es un verdadero problema. - No quiero ni comentarlo.

No se trata del rendimiento, sino de los fallos en el rendimiento.