Discusión sobre "Cómo escribir una DLL para MQL5 e intercambiar datos en 10 minutos". - página 3
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
¿Será posible crear dlls sencillos con medios mcl5? ¿Simplemente escribirlos en unitor y compilarlos?
¿Y dónde conseguir el compilador y el enlazador con todas las bibliotecas de Windows y el SDK de la plataforma?
Puedes hacerlo mucho más fácil: descargar e instalar gratuitamente Visual Studio 2008 Express y hacer las DLLs necesarias en él.
¿Y dónde conseguir el compilador y el enlazador con todas las bibliotecas de Windows y el SDK de la plataforma?
Puedes hacer algo mucho más sencillo: descargar e instalar gratuitamente Visual Studio 2008 Express y utilizarlo para crear las DLL necesarias.
La cuestión no es ser libre...
La cuestión es que he tenido que descargar e instalar un monstruo por una pequeña.
De todos modos, gracias por su respuesta...
Una pequeña pregunta más...
Lo que hay que descargar de esta página:
http://www.microsoft.com/express/Downloads/
es
Visual C++ 2008 Express Edition
o todos
Todos - Archivo de imagen ISO de instalación sin conexión
?
Visual C++ 2008 Express Edition
Es suficiente.
Gracias, lo estoy descargando ahora.
Pero está todo en un solo archivo (800 mb).
No me fío mucho de la instalación de la red...
Hemos creado metódicamente 4 generaciones de lenguajes de trading desde 2001 con una enorme comunidad de traders. Los competidores morían, sus lenguajes de control no se desarrollaban, pero nosotros trabajábamos, trabajamos y seguiremos trabajando.
Pero, ¿dónde conseguir el compilador y el enlazador con todas las bibliotecas de Windows y el SDK de la plataforma?
Es mucho más fácil: descargar e instalar el Visual Studio 2008 Express gratuito y utilizarlo para crear las DLL necesarias.
En primer lugar, hay que averiguar cuáles son "sus" lenguajes de control, delimitar "sus" funciones y, a continuación, averiguar qué significa "su" desarrollo. No me refiero a los competidores, sino a los idiomas. Como puede ver, los programas y sistemas de comercio viven entre una variedad de conchas circundantes, incluso bajo winndas tenemos C++/.net/JScript/shell script/ y otros, y se señala correctamente arriba que no tiene sentido tratar de arrastrar todo en una plataforma de comercio - la creación de algunos DLL, o proporcionar temporizadores, intercambio de datos y así sucesivamente debe basarse en los medios existentes y ampliamente conocidos del propio sistema operativo, complementos disponibles libremente. módulos (digamos, el marco de trabajo .net en constante desarrollo con sus versiones en tiempo de ejecución) + las herramientas de desarrollo y depuración más potentes - ¿por qué molestarse con una bicicleta o un sistema operativo de próxima generación como Chrome OS en todas partes?
En mi opinión, el desarrollo del lenguaje de escritura de CT debe servir para las tareas específicas del comercio, es decir, la recopilación de información, el análisis, las pruebas, la gestión del comercio y la integración con otros sistemas; todo esto puede y, en mi opinión, debe hacerse con un alto nivel de herramientas de desarrollo modernas, es decir, integrando y ampliando el marco estándar seleccionado utilizando métodos generalmente aceptados (OOP, etc.). La tarea no es escribir una plataforma autónoma y autosuficiente en una mezcla de C / C + + o lo que sea, pero sobre todo la calidad de escribir un marco de la plataforma de comercio, sus servicios, la API y la interfaz de usuario. Pues la tarea de integrar la plataforma de comercio que ya tenemos, aunque sea la mejor, es ineludible. Un ejemplo sencillo es AutoTrading. Probablemente está claro que el arranque de Windows con autologin y МТ terminal en la carpeta de Inicio del SO - ya es un anacronismo malicioso, necesitamos un servicio normal de Windows para que los robots funcionen independientemente de los inicios de sesión de los usuarios (¿servidores?). Juguetear con DLL's puede no ser necesario, basar la plataforma en digamos .net. Escribe en C#, C++ gestionado, Delphi, J++ y un montón de cosas más. En mi opinión, esto se debió al miedo de los desarrolladores a hacer una plataforma demasiado extensible y flexible que sería mucho más difícil de controlar que cualquier caja de arena de baja suscripción.
Cuántas veces he oído exactamente esas palabras: por qué reinventar la rueda, por qué no tomar como base java, Net, etc. Y yo mismo empecé a escribir mis primeras estrategias de trading hace exactamente 11 años, cuando no había ni idea de API a una cuenta de trading.
Tome API listo de diferentes corredores y hacer sus propias soluciones, por el amor de Dios.
Excepto que la práctica demuestra que sólo los programadores demandan APIs en bruto. Y por un programador dispuesto a ir "mano a mano" para escribir el sistema, hay 1000 operadores que quieren probar sus estrategias en un marco listo y seguro.
Los novatos piden la API, a veces la consiguen, y luego pasa un mes de agonía y comprenden que la API para escribir incluso la más simple estrategia de trading no es suficiente, y todo lo que necesitan es un entorno de mercado preparado. Resulta que no hay mercado para los programas más sencillos sin API, que a los compradores no les interesa estar atados a un terminal, etc. Y el deseo de escribir más se pierde invariablemente.
El desarrollo normal de un entorno de autoprogramación en las plataformas comerciales requiere un marco seguro con un sandbox rígido, ya que de lo contrario nadie compartirá los scripts por miedo a los troyanos. Si no lo comparten, la comunidad morirá y la lengua también.
La comunidad no está formada por 50, 100 o 500 programadores (que te limpiarán los pies alegremente), sino por decenas y cientos de miles de comerciantes que utilizan sistemas con un mínimo de complejidad.
Por cierto, sólo MQL4. community recibe más de 30 000 visitantes únicos cada día, y estimamos que hay más de un millón de usuarios de MetaTrader 4 en todo el mundo.
En la compilación 240 se han simplificado las envolturas, la tasa de llamadas es ahora de 19.911.000 llamadas por segundo.
Cuántas veces he escuchado estas mismas palabras: por qué reinventar la rueda, por qué no utilizar java, Net, etc. como base. Pero yo mismo empecé a escribir mis primeras estrategias de trading hace exactamente 11 años, cuando prácticamente no había ninguna API en mi cuenta de trading.
Es una forma de decirlo. E incluso después de 11 años algo tenía que cambiar :)
Tome la API lista de diferentes corredores y haga sus propias soluciones.
A veces la gente tiene la tentación de hacerlo. ¿Y por qué no intentar mejorar la situación, sobre todo si la posición lo permite?
Pero la práctica demuestra que sólo los programadores demandan la API en bruto. Y por cada programador que está dispuesto a escribir "mano a mano" el sistema, hay 1000 operadores que quieren comprobar sus estrategias en un marco listo y seguro.
Lo crudo es un concepto relativo. Sin embargo, a veces una API es mejor que nada. O peor aún, se ven obligados a utilizarlos debido a las limitaciones inherentes a la plataforma.
Sobre el tema de los marcos "seguros", el debate está abierto, qué protegemos, de quién y cómo.
Los novatos exigen una API, a veces la consiguen, luego pasa un mes de agonía y se dan cuenta de que la API no es suficiente para escribir ni siquiera la más sencilla estrategia de trading, y necesitan un entorno de mercado preparado para todo lo demás. Resulta que no hay mercado para los programas más sencillos sin API, que a los compradores no les interesa estar atados a un terminal, etc. Y el deseo de escribir más se pierde invariablemente.
De esto es de lo que estamos hablando: no de una API, sino de un marco extensible con interfaces especializadas, adaptadas a tareas específicas. La vinculación al terminal no interesa a nadie, pero a los corredores les "encanta" vincularse. Por supuesto, hay que sentir pena por ellos.
Un entorno de desarrollo normal para la autoprogramación en las plataformas comerciales requiere un marco seguro con una caja de arena rígida, de lo contrario nadie compartirá los scripts por miedo a los troyanos. Si no lo comparten, la comunidad morirá, y la lengua también.
Siento discrepar con usted en este punto, pero estoy abierto a cambiar de opinión y a modificar mi posición. Nombra un ejemplo de la historia de las plataformas comerciales de autoprogramación en el que la (excesiva) potencia de un determinado entorno de desarrollo disponible superó el miedo de los usuarios y condenó dicho entorno a la destrucción y la extinción. Estoy de acuerdo en que permitir que se marquen las llamadas a DLL en MT no resuelve prácticamente nada en este sentido, especialmente si hay una razón justificada para recurrir a las DLL.
La comunidad no está formada por 50, 100 o 500 programadores (que te limpiarán los pies alegremente), sino por decenas o cientos de miles de comerciantes que utilizan sistemas con un mínimo de complejidad.
Es entonces cuando hay que decidirse desde el principio, en lugar de intentar atiborrar de OOP a un tipo que tiene una vaga idea de programación. Hablando específicamente de los sistemas de autotrading, dale a los operadores un mínimo de complejidad y se convertirá en un máximo de complejidad bajo la manta de una interfaz gráfica (y, eventualmente, en una pesadilla para el programador del sistema) - ¿no es más fácil no engañar a nadie y permitir la máxima flexibilidad en la creación de sistemas, en lugar de tratar de encontrar un compromiso de lo que se permite que funcione para el 95% de los casos (léase - "todos, excepto unos pocos desplumados, están muy contentos, así es como nuestra empresa se posiciona")?
Por cierto, MQL4. community recibe más de 30 000 visitantes únicos cada día y estimamos que hay más de un millón de usuarios de MetaTrader 4 en todo el mundo.
¿Qué vas a hacer con estas estadísticas? Claramente, en términos de negocio, las compañías de corretaje tienen un 98% de pobres traders que han comprado un Asesor Experto de aspecto agradable en el terminal de comercio con, sin duda, un terminal de aspecto agradable con todo tipo de trucos...
Querida pisara,
Seamos claros: hay una discusión entre un teórico y un profesional. Por supuesto, nadie te prohíbe luchar por la "paz mundial", pero ten en cuenta más factores que "¿por qué no mejorar?
Ради бога, берите готовые API разнообразных брокеров и делайте свои решения.
Иногда к этому склоняют. А почему бы не постараться улучшить ситуацию, тем более если позиция позволяет?
Eso es lo que escribí: no lo usarás, porque no quieres dedicarte al trabajo rutinario. Tendrá que tener todo en bandeja de plata: todos los indicadores, todo el entorno del mercado, toda la historia en diferentes períodos, etc. Y tendrá que haber gráficos, porque no manipularás todos los indicadores en tu mente.
Así que, de hecho, necesitas un terminal completo. Y te lo damos: MetaTrader 5 + MQL5 + DLL. Llámalo framework o simplemente danos el terminal en código fuente/componentes (porque es lo que quieres).
Los programadores creen erróneamente que es "poderoso" poder escribir scripts para sistemas de comercio en lenguajes nativos no protegidos, y luego se sorprenden de que nadie vaya a utilizar sus creaciones. Por eso mueren antes de nacer. Los que desarrollaron y crearon la comunidad de usuarios, piensan mucho más profundamente (porque recibieron los golpes antes) y no cometen esos errores.
La llamada de DLL controlada (desactivada por defecto) es aceptable, pero la descarga de DLLs hechas por otra persona en su terminal de comercio es un agujero tan grande como un Internet Explorer 6 sin parchear.
Para obtener información, las estadísticas de Google Trends sobre terminales de comercio con automatización: