Mi enfoque. El núcleo es el motor. - página 170
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
Divertidísimo :)))
Bien hecho, tú******* coge una tarta de la estantería.
Bien, trataré de justificarlo:
Si vas por tu solución, el usuario todavía tendrá que copiar el código fuente de la clase estática en el proyecto, que traducirá los eventos, ejecutará el formulario en un pozo de hilo separado, etc. Además, debe vincular estáticamente el formulario a esta clase, es decir, introducir explícitamente el nombre de la clase de formulario y sus componentes. Es decir, modificar explícitamente el código de su capa cuando se cambia un formulario o se añade algún elemento. En otras palabras, una solución simple y sencilla, funcionaría bien para demostrar la interacción con un formulario específico, que es lo que has mostrado. En un caso generalizado, es mejor separar la lógica de control de la lógica de visualización, que es lo que he hecho. Además, esta separación le permite asegurar el controlador de la modificación no calificada.
Aquí hay un comentario que responde exactamente a la pregunta de por qué se hizo así y no al revés:
probablemente tengas razón, es más fácil para un usuario esbozar elementos gráficos en un formulario en VS2017, luego comprobar ejecutando su creación en VS, habiéndose asegurado de que "todo está girando", puede pasar a crear un programa de interacción en .Net y MT5
...
Tu manera es probablemente más práctica.
Exactamente. Habrá una enorme base de datos de cibercódigos con imágenes. Entrar, seleccionar, obtener el código, insertar en el constructor, obtener el núcleo con los archivos de conexión. Y la conexión ya está pensada y es mucho más fácil.
Por lo tanto, cada formulario está en un archivo separado. Aunque fuera más sencillo, las posibilidades son limitadas.
También en este caso, cada formulario está en un archivo separado. Aunque fuera más sencillo, las posibilidades son limitadas.
Para ser honesto, aún no he comprendido del todo la tecnología, así que todavía no puedo decir nada sobre las limitaciones de la solución de Vasiliy.
Basil, no te ofendas, pero un panel como este:
Tengo sobre este tipo de código:
Este código puede pasarse simplemente entre sí, o ponerse en una base común y no hay necesidad de dibujar un formulario a cada uno especialmente.
Lo pegué en el constructor y obtuve otra ventana con todos los parámetros del artículo y las conexiones.
Peter, para dibujar el mismo panel que tú, necesito aprender tu lenguaje de marcas. El usuario no necesita más que un ratón y conocimientos básicos para dibujar este panel en Visual Studio. ¿Sientes la diferencia?
Para ser honesto, aún no he comprendido del todo la tecnología, así que todavía no puedo decir nada sobre las limitaciones de la solución de Vasiliy.
Y no escribí sobre las limitaciones de la solución de Vasiliy.
Peter, para dibujar el mismo panel que el tuyo, necesito aprender tu lenguaje de marcas. El usuario no necesita nada para dibujar este panel en Visual Studio, sólo un ratón y conocimientos básicos. ¿Sientes la diferencia?
Vasily, una persona estudia mi lenguaje de marcado y escribe el panel. Otros mil ven la foto del panel y toman el cibercódigo ya hecho. Lo pegan en mi constructor y obtienen el panel en su programa.
Pre-lectura, pero seguiré releyendo para entrar en los detalles.
1. ¿Por qué el artículo dice 5 peticiones por segundo? Mi frecuencia es de 30ms.
2. ¿Puedes mostrarme cómo es una conexión con una tabla de mil celdas?
3 Por lo que entiendo, ¿llamar a los elementos del formulario por sus nombres enviados a la funciónGuiController::SendEvent? ¿Hay que especificar todos los parámetros? ¿Nombre, evento, valor? Algunos ceros más... ¿Y en el temporizador para hacer un bucle en los eventos?
En otras palabras, ¿el usuario crea la cola de eventos por sí mismo y luego la pasa al controlador en el temporizador?
Tengo que darte las gracias, por la gran promoción de mi tema.
1) No hay ninguna diferencia. Puedes ajustarlo a la frecuencia que quieras.
2) Las tablas no son compatibles ahora (gran razón para su alegría por cierto:)
3) Sí, el direccionamiento por nombre, tiene que especificar todos los parámetros. Pero, y esto es lo más importante, no existe un único modelo de eventos monolítico. Si quieres tu propio modelo, eres bienvenido. Es elemental hacerlo. Pero no puedes prescindir del temporizador.
La cola de eventos es un algoritmo generalizado para la gestión fiable de eventos. El usuario no compone nada; los eventos generados por él llegan a la cola por sí mismos. La cola en sí consta de un solo evento el 99,9% de las veces.
Bien, trataré de justificarlo:
Si nos guiamos por tu solución, el usuario seguirá teniendo que copiar el código fuente de la clase estática en el proyecto, que traducirá los eventos, ejecutará el formulario en un hilo separado, etc. Además, debe vincular estáticamente el formulario a esta clase, es decir, introducir explícitamente el nombre de la clase de formulario y sus componentes. Es decir, modificar explícitamente el código de su capa cuando se cambia un formulario o se añade algún elemento. En otras palabras, una solución simple y sencilla, funcionaría bien para demostrar la interacción con un formulario específico, que es lo que has mostrado. En un caso generalizado, es mejor separar la lógica de control de la lógica de visualización, que es lo que he hecho. Además, esta separación le permite asegurar el controlador de la modificación no calificada.
Aquí hay un comentario que responde exactamente a la pregunta de por qué se hizo así y no al revés:
El mayor problema es lanzar el formulario en un hilo separado, pero se resuelve con dos líneas de código, así que al final no es un problema. Además, en mi ejemplo hice intencionadamente la apertura del segundo formulario, para mostrar lo fácil y sencillo que es hacerlo, y cómo se puede abrir cualquier número de formularios en hilos separados.
Y lo destacado en la cita, ¿es lo mismo heno que paja? ¡Sí! Para comer un plátano, hay que pelar la cáscara.
Para ser sincero, aún no he entendido del todo la tecnología, así que todavía no puedo decir nada sobre las limitaciones de la solución de Vasiliy.
Ahí no hay límite de capacidad, todo está limitado ni más ni menos que la funcionalidad de los elementos gráficos de Windows, lee el artículo"Under the bonnet of GuiController", añade los controles necesarios en el diseñador de formularios y añade a MT5 en <elemento - lista de manejadores de eventos> los eventos que creas que necesitas recibir
2) Las tablas no se soportan ahora (gran motivo de alegría por cierto:)
También voy a felicitar a Pedro, hice una tabla de trabajo en una forma separada en .dll en .Net, eventos de clic derecho, la clasificación, y otros encantos dataGridView todo el trabajo, hizo en parte experimentos tabla como el terminal, pero bastante caprichosa y lenta dataGridView , he intentado muchas cosas con él ( y llenó un datatable clon y luego se copia a la datatable que está vinculado a un dataGridView y . y googleando durante una semana y experimentando, mientras que con dataGridView un completo fiasco - no se puede escribir en él más de 3-5 segundos) la tabla de 10x11 ya es crítica, aunque el formulario con la tabla y se ejecuta en un hilo separado
SZY: Yo adjunté un StringGrid a MT4 hace 5 años en Delphi, no me preocupaba para nada como funcionaba, pero todo volaba, sin embargo con el dataGridView de Microsoft es un problema, hoy trataré de experimentar con SourceGrid, según los feedbacks es más rápido que el dataGridView