Mi enfoque. El núcleo es el motor. - página 26
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
Los constructores de GUI están hechos para una biblioteca gráfica específica. Si hubiera un constructor de GUI para MQL, estaría aquí.
He visto un artículo en algún lugar, en hubre, parece, como "crear un constructor de GUI para Python", así que pensé que tal vez alguien ha visto una GUI multiplataforma donde podría añadir mi propio código
Pero si quiero escribir un constructor desde cero, prefiero usar MQL.
1. Nunca lo he desarrollado en Sharp, no me interesaba, pero hace unos 5 años utilicé Delphi para conectar la .dll con los botones y formularios y funcionaba sin problemas, incluso todo el proyecto de Delphi estuvo listo durante un día, incluso me pasé medio día intentando encontrar la razón por la que los formularios estándar no funcionaban, y cuando lo conecté a través de la llamada a las ventanas del sistema todo funcionaba correctamente, pero MT4 era muy lento entonces, ahora se retrasa y vuela
no tengo problemas para conectar la .dll, sincronizar con los mutex estándar - iniciar un hilo para conectarse a la terminal y eso es todo, entonces todo va por sí mismo - por separado un formulario en la .dll, por separado MT nadie está esperando a nadie
SZS: tenga en cuenta, que Delphi es bastante poco práctico para crear un .dll, pero lo que estaba a mano (lo que estaba sentado en ese momento) que he utilizado))
2. Pero en cuanto al punto, no entiendo por qué no pueden usar clases estándar del toolkit de MT, sería genial unificar el proceso de creación de gráficos, tal vez sería un include universal donde se podrían comentar los botones/diálogos innecesarios, etc.
1. esta es una manera muy, muy amateur de ver el problema (sin ofender). Un proyecto que se hace en un día no es un proyecto. Es una tarea pequeña.
Imagina que creas una aplicación que consta de 10 ventanas, entre las que hay grandes tablas de datos, ventanas de configuración y cuadros de diálogo. Se dibujan en Delphi. Entonces se crea una DLL. Luego lo conectas a tu proyecto de MT.
Su aplicación MT necesita conectarse a la GUI de Delphi a través de la memoria compartida. Conecte las funciones a los controles y los datos a las celdas de la tabla. Hay que organizar la compleja interacción de las dos partes de la aplicación y pensarla bien.
Es necesario el funcionamiento sincrónico y el intercambio de valores de parámetros entre las dos partes - GUI y Aplicación MT.
Una vez más: si su aplicación es grande y seria (tablas, ventanas de configuración, cuadros de diálogo, listas antiguas, etc...) crear un trabajo único, coherente y eficiente de dos partes vía DLL es una tarea MUY seria. Lo he hecho y sé de lo que hablo.
Y usted está hablando de una pequeña tarea que se puede hacer en un día. No es grave.
Puede utilizar la biblioteca estándar hace mucho tiempo. Pero la cuestión es el esfuerzo que se requiere y el resultado que se obtendrá. ¿Qué son? Sé que Anatoly utilizó la biblioteca estándar como trampolín para crear su propia biblioteca. Pero, ¿por qué lo hizo, si la biblioteca estándar también funciona? La respuesta es sencilla: implementó todo de mayor calidad y fue más allá de la Biblioteca Estándar. Pero la distribución masiva sólo puede lograrse reduciendo la dificultad de uso. Cuanto más fácil sea su uso, más usuarios habrá (con un aumento de la calidad, por supuesto).
1. esta es una manera muy, muy amateur de ver el problema (sin ofender). Un proyecto que se hace en un día no es un proyecto. Es una tarea pequeña.
Imagina que creas una aplicación que consta de 10 ventanas, entre las que hay grandes tablas de datos, ventanas de configuración y cuadros de diálogo. Se dibujan en Delphi. Entonces se crea una DLL. Luego lo conectas a tu proyecto de MT.
Su aplicación MT necesita conectarse a la GUI de Delphi a través de la memoria compartida. Conecte las funciones a los controles y los datos a las celdas de la tabla. Hay que organizar la compleja interacción de las dos partes de la aplicación y pensarla bien.
Es necesario el funcionamiento sincrónico y el intercambio de valores de parámetros entre las dos partes - GUI y Aplicación MT.
Una vez más: si su aplicación es grande y seria (tablas, ventanas de configuración, cuadros de diálogo, listas antiguas, etc...) crear un trabajo único, coherente y eficiente de dos partes vía DLL es una tarea MUY seria. Lo he hecho y sé de lo que hablo.
Y usted está hablando de una pequeña tarea que se puede hacer en un día. Esto no es serio.
¿Cuáles son sus quejas? Simplemente no entiendes que el intercambio de datos entre MT y .dll es tan antiguo como el mundo
Estaba haciendo un .dll porque antes no había gráficos decentes en MT, quería botones y un panel
¿mesas? - ¿dibujar bien las tablas, los controles? - dibujar.... No se puede separar la tarea, en el mismo Delphi hay muchos componentes ya hechos, tanto para crear bases de datos como para trabajar con ellas
Es decir, de MT sólo necesita los datos en sí, y el resto va a hacer un programa de terceros, usted puede tomar su palabra, pero en el mismo Delphi para escribir el trabajo con la base de datos, con la salida en tablas, gráficos, etc trabajo para un día ;)
¿Qué son los datos en MT? = es sólo un tick y una barra, y no tiene sentido "correr" a través de un .dll - sólo volcar todo en un archivo una vez y trabajar con el archivo en un programa de terceros
SZS: alguien escribió hace poco en el foro que las empresas informáticas modernas valoran a los empleados que no entienden a fondo el código en el que trabajan, sino a los que cuanto antes pueden realizar un gran volumen de tareas, es decir, necesitan ser capaces de integrar el trabajo de otras personas en su tarea, ¡y no construir cada vez desde cero! No sé su ocupación principal, nunca he trabajado como programador, pero estoy trabajando constantemente en campos relacionados, durante mucho tiempo dedicado al mantenimiento de los controladores industriales, ACS y ACS, y tuvo que hacer añadir soluciones de programas e interactuar con los desarrolladores, así que tuve que entrar en todas las soluciones de software ya hechas - aquí no se puede escribir todo desde cero )))), y los fabricantes de "hierro" industrial utilizar sistemas de programación especializados, donde C, donde SCADA, y ensamblador, y cada vez debe ser capaz de leer el código de otra persona ;))
¿Propone crear, basándose en su "motor", un diseño condicionalmente viable, que no pueda ser modificado por los programadores?
¿Cuáles son los resentimientos? Simplemente no entiendes que el intercambio de datos entre MT y .dll es tan antiguo como el mundo
Hice el .dll porque antes no había gráficos decentes en MT, quería botones y panel
¿mesas? - ¿dibujar bien las tablas, los controles? - dibujar.... No se puede separar la tarea, en el mismo Delphi hay muchos componentes ya hechos, tanto para crear bases de datos como para trabajar con ellas
Es decir, de MT sólo necesita los datos, y el resto va a hacer un programa de terceros, puede tomar su palabra, pero en el mismo Delphi para escribir el trabajo con la base de datos, con la salida en tablas, gráficos, etc trabajo para un día ;)
ZS: ¿Qué son los datos en MT? = es sólo un tick y una barra, y no tiene sentido "correr" la historia a través de un .dll - sólo volcar todo en un archivo una vez y trabajar con el archivo en un programa de terceros
Si se toman sólo los datos que llegan desde MT, y se pasan a través de una DLL a una aplicación escrita en Delphi o C++ o C#, entonces sí es posible. Entonces, la aplicación de comercio estará completamente escrita en un lenguaje de programación diferente.
Es decir, las series de tiempo, el comprobador, la optimización, los sintéticos y muchas otras cosas deben crearse en otro lenguaje.
¿Por qué necesita MQL? Basta con suministrar los datos directamente a una aplicación de terceros, y utilizar la plataforma como emisora de eventos y órdenes. Y eso es todo. Pero se perderán las ventajas de MQL como lenguaje de sistemas de comercio.
¿Por qué necesita MQL?
Porque MQL es un lenguaje de aplicación desarrollado para escribir aplicaciones de comercio. Esta es su principal ventaja. Es ligero y sencillo. Tiene un montón de soluciones preparadas para los programadores. Los toman y los usan.
Los programadores tienen una opción:
Obviamente, la opción más preferible es usar MQL y MT, porque dan ventajas - Pruebas, Optimización, Investigación (sintética), Indicadores, funciones prácticas, series de tiempo... + Soporte técnico lingüístico en el foro.
Pero este ideal tiene un grave defecto: la capacidad limitada para crear aplicaciones complejas, debido a la dificultad de crear una interfaz gráfica de usuario de calidad.
Este último problema lo he resuelto en su mayor parte.
Por lo tanto, cuando llegue el momento de la práctica y empiece a escribir una solicitud seria, seguramente elegirá MT. También lo harán muchos, muchos otros.
...
¿Está sugiriendo crear, sobre la base de su "motor", un diseño condicionalmente viable, que no pueda ser modificado por los programadores?
El motor es el "portador" de esa GUI que se crea en mi constructor. No es necesario modificarlo. Sólo conéctalo a la aplicación y la GUI creada funcionará.
Una vez más: si la aplicación es grande y seria (tablas, ventanas de configuración, diálogos, listas antiguas, etc...) crear un funcionamiento único, coherente y eficiente de las dos partes a través de la DLL es una tarea MUY seria. Lo he hecho y sé de lo que hablo.
Quien pueda crear una aplicación grande y compleja utilizará sin duda la biblioteca gui. ¿Qué debe hacer el desarrollador si desarrolla su aplicación y decide añadir una animación, por ejemplo? ¿Debe buscarte y preguntarte, o debe romper todo y construir desde cero?
¿De dónde has sacado la idea de que hay un problema con la creación de interfaces gráficas? Mira el mercado, hay muchas aplicaciones con GUI.
1. Quien pueda crear una aplicación grande y compleja utilizará sin duda la biblioteca gui.
2. ¿Qué debe hacer el desarrollador si, mientras desarrolla su aplicación, decide, por ejemplo, añadir una animación? ¿Buscarte y preguntar, o romper todo y construir desde cero?
3) ¿Y de dónde has sacado la idea de que hay un problema con la creación de la interfaz gráfica? Mira en el mercado, hay un montón de aplicaciones con GUI.
1. La biblioteca GUI es una biblioteca diseñada para programadores serios. No se puede producir en masa debido a la dificultad de uso. ¿Qué sentido tiene eso? ¿Sólo algunos de nosotros estudiarán a fondo la biblioteca y crearán aplicaciones complejas mientras que otros no podrán hacerlo?
2. Deja que el desarrollador cree la animación en su aplicación. ¿Qué tiene que ver esto conmigo? Puede llamar a esta animación independientemente de la GUI y del Motor, o vincular la llamada de su animación a algún botón.
3) Sólo hay unas pocas personas cuya interfaz gráfica de usuario es digna de atención. Tú, Anatoly y quizás alguien más... El resto no alcanza el más mínimo nivel de seriedad.
3. sólo hay unas pocas personas cuyo GUI es digno de mención.
Yo no sería tan categórico. Y no me refería al desarrollo de bibliotecas gui, sino a aplicaciones gui. Hay muchos en el mercado, algunos usando sus propios desarrollos, otros usando el estándar y otros usando la biblioteca de Anatoly.
1. Esa es la cuestión. La biblioteca GUI está diseñada para programadores serios. No puede difundirse masivamente debido a la dificultad de su uso. ¿Qué sentido tiene eso? Algunos de ellos estudiarán detenidamente la biblioteca y crearán aplicaciones complejas y otros no podrán hacerlo...
2. Deje que el desarrollador cree la animación en su aplicación. ¿Qué tiene que ver esto conmigo? Puede llamar a esta animación independientemente de la GUI y del motor, o vincular la llamada de su animación a algún botón.
3) Sólo hay unas pocas personas cuya interfaz gráfica de usuario es digna de atención. Tú, Anatoly y quizás alguien más... El resto no alcanza ni el más mínimo nivel de seriedad.
Peter, creo que el principal problema que tienes es el posicionamiento del proyecto.
Sólo puede ser de interés para aquellos participantes que tienen una experiencia bastante buena en la programación, pero al mismo tiempo - prefieren intercambiar las manos.
¿Cree que son muchos?
Mire, todos los que critican su diseño son personas que no se dedican al comercio "manual" de forma habitual. Como mucho, de vez en cuando. Y, como no ven su proyecto como comerciantes "manuales", lo ven como programadores. Y, como es lógico, encuentran un montón de soluciones muy dudosas.
En mi opinión, su pregunta ahora debería ser sobre la búsqueda de este nicho (en mi opinión, uno muy estrecho): los programadores que prefieren cambiar de mano.
Creo que vi un artículo en algún lugar, como en hubra, llamado "crear un constructor de GUI para Python", así que pensé que tal vez alguien ha visto una GUI multiplataforma donde puedo añadir mi propio código
Si quiero escribir un constructor desde cero, prefiero usar MQL.
Los constructores de GUI modernos (los que "extienden los botones en los formularios") son algo bastante tecnológico y adjuntarles elementos MQL no parece fantástico.
En la forma intermedia ( archivo de proyecto, etc.), casi todos tienen XML que describe la disposición y las relaciones entre los elementos.
La generación de código de la plataforma de destino es, de hecho, la transformación XSLT, que puede hacer cualquiera que se crea desarrollador web :-)
Tomemos como ejemplo EasyAndFast (https://www.mql5.com/ru/code/19703) porque está basado en objetos y tiene todos los componentes necesarios. (y abierto y documentado por cierto, a diferencia de este hilo),
y simplemente escribir un traductor.
No hay constructores de gui-mql, no porque sea megacomplejo, sino simplemente porque no tiene demanda.