Mi enfoque. El núcleo es el motor. - página 172
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
Peter, parece que estás buscando algo de lo que quejarte.
La respuesta es no, la interlesencia nunca ha funcionado con un elemento de texto y nunca funcionará. Pero si esa es la única cuestión, no es un problema hacer interlesencia sobre lo mismo define en absoluto.
s.s. Por cierto, a ti tampoco te funcionará:
Vasily, no es ni mucho menos algo trivial. Al crear ventanas complejas y tablas de gran tamaño, el usuario se atascará con los nombres de los elementos, que tiene que prescribir manualmente, y seguir recordando o buscando en el formulario.
Para mí, esta línea
se convierte en una envoltura:
No necesito recetar ni recordar el nombre. Encuentro el elemento deseado en la lista de inteligencias.
Vasiliy, esto está lejos de ser un asunto trivial. Al crear ventanas complejas y tablas de gran tamaño, el usuario se verá atascado con nombres de elementos que tiene que escribir manualmente, e incluso recordar o buscar en el formulario.
...
Repito, nunca es un problema hacer una intercalación para los parámetros de texto. ¿Quieres que te sugiera todo a la vez? No hay tal cosa.
Repito que nunca es un problema hacer una intercalación para los parámetros textuales. ¿Quieres que te sugiera todo a la vez? No hay tal cosa.
Sí, pero para hacerlo en Sharp, hay que imprimir un archivo con definiciones, que luego se transfiere a la caja de arena de archivos MQL y se conecta al programa. Sería especialmente bueno hacer esto en cada cambio de contenido de la GUI)).
Dmitry, hay un modelo arquitectónico llamado MVC. El planteamiento que he propuesto tiene que ver exactamente con eso. Así que cuando lo criticas, estás criticando el MVC en primer lugar y soluciones como Angular, ASP Net MVC, Ruby on Rails y otros productos que no merecen tu atención de experto, hechos por el "culo" en tu opinión. Así que creo que deberías entender por qué no quiero discutir contigo y demostrar la validez de mi decisión: es inútil.
Así que el MVC viene en todo tipo de formas...
Además, es muy fácil justificar la inadecuación de este modelo aquí en absoluto, no sólo por el razonamiento teórico, pero puramente práctico, porque es como una máscara de gas en un paseo en un prado de flores aquí.
Supongamos que el usuario decide cambiar el nombre de un elemento, después de llamarlo en decenas de lugares del programa. ¿Tiene que cambiarlo en todas las llamadas?
En mi programa, no es necesario. Al envolver un elemento sólo se transmite su nombre de forma imprecisa. Por ejemplo, "Set lot" se convierte en"E_Trade_panel__Set_lot();" y si cambio el nombre a "SET LOT", no necesito crear un nuevo wrapper.
Y en tu solución, Vasiliy, tengo que reescribir el nombre en todas las llamadas.
Sí, pero para ello hay que imprimir un archivo con definiciones en Sharp, que luego se transfiere al archivo MQL sandbox y se conecta al programa. Sería especialmente bueno hacerlo en cada cambio de contenido de la GUI)).
Peter, es que no conoces todas las tecnologías que ofrecen C# y Visual Studio. En particular, con la ayuda de T4 y las directivas de construcción, este proceso puede ser completamente automatizado, incluyendo la transferencia de las definiciones generadas a la caja de arena de archivos.
No, Pyotr, no puedes competir con C# y Visual Studio. Son categorías de peso diferentes.
Peter, es que no conoces todas las tecnologías que ofrecen C# y Visual Studio. En particular, se puede automatizar completamente este proceso con la ayuda de T4 y las directivas de construcción, incluyendo la transferencia de las definiciones generadas en la caja de arena de archivos.
No, Pyotr, no puedes competir con C# y Visual Studio. Son categorías de peso diferentes.
Bueno, ¿por qué no debería competir contigo? Aunque sólo sea porque las utilidades escritas en MQL nativo se pueden vender, y por mucho que te esfuerces con C# no me vas a superar en esta ventaja).
En cuanto a la facilidad para escribir programas GUI complejos, yo ya lo he probado y tú aún no. Así que, por el momento, eres tú quien intenta ganar con C# y no al revés. :))
En cuanto a la facilidad para escribir programas GUI complejos, yo ya lo he probado y tú aún no. Así que, en este punto, eres tú con C# quien intenta competir conmigo, no al revés. :))
Piotr, ¿qué has probado? ¿Dónde se encuentra su liberación? Hasta ahora lo tienes todo sobre el papel.
¿Por qué no puedo competir? Yo ya voy ganando al menos porque las utilidades escritas en el MQL nativo se pueden vender, y por mucho que lo intentes con C#, no me vas a superar en esta ventaja)).
Peter, ¡resultas ser un Q mercurial!
Peter, es que no conoces todas las tecnologías que ofrecen C# y Visual Studio. En particular, se puede automatizar completamente este proceso con la ayuda de T4 y las directivas de construcción, incluyendo la transferencia de las definiciones generadas en la caja de arena de archivos.
No, Pyotr, no puedes competir con C# y Visual Studio. Son categorías de peso diferentes.
Bueno, estás llevando el desarrollo en una dirección equivocada, Vasily.
Aquí ha hecho este adaptador de código abierto en GitHub. Y estás hablando de las enormes posibilidades de C#, como la posibilidad de portar cualquier cosa a una caja de arena de archivos. ¿Y crees que nadie añadirá a este adaptador lo que quiera y no empezará a distribuir la versión viral cerrada? ¿Y no habrá ningún "pringado" que lo acepte?