Discusión sobre el artículo "Constructor gráfico de estrategias. Creando robots comerciales sin programación" - página 4
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
En este caso concreto, no veo nada malo en ello. Ya que no se trata ni de un robot ni de una señal, sino de un medio de producción para no programadores.
Una cosa es una mercancía y otra una máquina para la producción de bienes y tecnología. Las mercancías ordinarias están sujetas a aranceles cuando se importan en el país, mientras que las tecnologías se buscan y el propio Estado está dispuesto a pagarlas.
Apenas hay acuerdo entre bastidores, ya que la promoción de este producto está en manos de MQ debido a la promoción de la plataforma.
Además, es cierto que un trabajo serio y extenso en beneficio de MQ debería ser recompensado.
Pero se ha sentado un precedente :)))
No hay reglas sin excepciones, especialmente para aquellos que hacen las reglas. No sería prudente apostar por el principio de las "reglas" en detrimento propio.
Estoy seguro de que cualquiera que cree algo valioso y tecnológico para el bien común tiene derecho a esperar una lealtad similar de MQ. Y con razón.
Eres muy sabio, Nicholas)).
Estoy completamente de acuerdo contigo :)
No hay nada malo en ello, si el constructor concebido e implementado por MQ en el asistente MQL obtiene un nuevo desarrollo, una nueva vida gráfica y es probado y llevado a la perfección en un producto de pago.
No estoy diciendo que haya algo malo en ello, al contrario, estoy diciendo que es útil hacer revisiones de los logros de la gente en la esfera del desarrollo de software.
Sobre MQ - dudo que desarrollen algo más a toda prisa, además, este producto como que dice que no hay necesidad en él, dicen "estamos con nosotros".
Incluso si hay alguna "colusión", sería más correcto llamarlo un acuerdo. ¿Qué delito?
No soy fiscal para buscar conspiraciones y contubernios, no, sólo me gustaría que todos entendieran con qué criterio un artículo sobre su producto interesará o no a MQ.
También espero crear algún tipo de tendencia interactiva en esta comunidad de programadores. Personalmente, llevo mucho tiempo hablando de ello. Hasta ahora veo un gran retraso en este ámbito.
Por supuesto mi visión es muy diferente de esta implementación, pero aún así es algo.
Ni siquiera quiero discutir la utilidad y practicidad de este producto. Lo principal es la tendencia.
He creado un tema sobre la solución de la cuestión con la configuración de Asesores Expertos / indicadores / secuencias de comandos, por lo que sería posible añadir colores y otras golosinas para la comodidad de trabajo - por desgracia, casi no había partes interesadas.
Las versiones gratuitas son totalmente utilizables, sólo menos conveniente que las versiones completas.
Sí, lo haces, lo haces, y luego pum, se borra todo, bueno, un placer dudoso.
¿O he entendido mal alguna de las limitaciones?
Si necesitas el código, intenta generar el código del esquema de una de las plantillas y estúdialo. Tal vez encuentres algo útil. Por ejemplo, la clase de comercio se hace como una clase estática y se puede utilizar por separado del resto del código.
¿Por qué necesito código generado? Es interesante entender cómo funciona tu interactividad, cómo se producen las conexiones (se preparan las plantillas) y luego se interpretan.
¿Podría explicar lo que quiere decir?
Quiero decir que hay una densidad muy alta de iconos, que están conectados a lo largo y a través entre otros iconos, y como resultado tenemos una telaraña, que no es muy conveniente para la percepción.
La ventaja de los gráficos debería ser, en mi opinión, mejorar la percepción de la información, y por lo tanto una lectura más conveniente de la estructura de la lógica/código del programa.
La colocación de elementos en forma de diagramas de flujo clásicos sería más conveniente para la lectura, personalmente para mí, y para ello debería haber más espacio para trabajar, por eso sugerí pensar en el desplazamiento para aumentar el espacio.
Sí, lo haces, lo haces, y luego bang, se borra todo, bueno, una especie de dudoso placer.
¿O he entendido mal alguna de las restricciones?
No se borra nada durante el proceso de creación de un esquema. Los esquemas se borran después de un cierto número de generaciones de código fuente.
¿Por qué necesito código generado? Es interesante comprender cómo funciona su interactividad, cómo se producen las conexiones (se preparan los esquemas) y luego se interpretan.
Esto es exactamente lo que se puede entender a partir del código generado.
Colocar elementos en forma de diagramas de flujo clásicos sería más fácil de leer, personalmente para mí, y para ello debería haber más espacio para trabajar, por eso sugerí pensar en el desplazamiento para aumentar el espacio.
¿Estamos hablando de zoom? ¿O del tamaño de los iconos? El desplazamiento está ahí. La densidad de los iconos depende únicamente del deseo del usuario. Puedes tenerlos menos densamente espaciados.
No se borra nada durante el proceso de generación de esquemas. Los esquemas se borran tras un determinado número de generaciones de código fuente.
Esto es exactamente lo que puede entenderse del código generado.
¿Se trata del zoom? ¿O sobre el tamaño de los iconos? El desplazamiento está ahí. La densidad de los iconos depende únicamente del deseo del usuario. Pueden ser menos densos.
Entonces he entendido mal la descripción.
Tal vez se pueda, pero no para todos.
Se trata del desplazamiento espacial, no lo vi en las pantallas, por eso lo escribí.
Debo haber entendido mal la descripción.
Puede que sí, pero no para todo el mundo.
Se trata del desplazamiento espacial, no lo vi en las pantallas, por eso lo escribí.
Si el tema interesa, se puede escribir un artículo más técnico sobre esta parte.
En resumen: cada elemento corresponde a una clase - un objeto. Los objetos interactúan entre sí mediante el intercambio de datos (a través de punteros - enlaces). Todas las clases de estos objetos y enlaces son visibles en el código generado.
Las barras de desplazamiento aparecerán automáticamente cuando las necesite (cuando los elementos dejen de encajar). El tamaño del esquema puede cambiarse "arrastrando" sus bordes.
Como pequeña crítica:
1. Hay que mejorar el desplazamiento. Hay algo que no funciona del todo bien. A veces se ralentiza o simplemente "se sale".
2. Las ventanas no tienen botones. Intuitivamente llegar a cerrar la ventana, pero no hay cruz).
3. no se dio cuenta de inmediato cómo arrastrar una ventana. Tienes que pulsar una vez, luego pulsar y mantener pulsado. Tal vez un simple asa de movimiento sería más conveniente.
4. Las ventanas son dinámicas, pero su capacidad para cambiar de tamaño no es obvia. No está claro dónde agarrar para tirar y cambiar el tamaño de la ventana. Estaría bien que aparecieran flechas en lugar de los tiradores de las ventanas.
5. Al arrastrar la ventana, el asa superior (con la que sujetamos la ventana) puede sobrepasar el borde superior del gráfico, por lo que si sueltas la ventana, no puedes volver a agarrarla. También es imposible cerrar la ventana. Tenemos que hacer que sea imposible elevar la ventana por encima de la parte superior del gráfico.
En principio, no es crítico. Pero aún así...
1. Entendido. Con el desplazamiento, al igual que con la manija de arrastre de la ventana. Tienes que pulsar una vez y luego otra vez y mantener pulsado. Entonces todo funciona.
5. Si una ventana se ha salido del área de visibilidad, tienes que usar la barra de desplazamiento principal. Entonces puedes traerla de vuelta al área de visibilidad.