Intentaré (o intentaré, si me interesa) hacer un marco para los EAs. Lo más adecuado posible sólo para cosas sencillas y que no requieran conocimientos sustanciales por parte del programador aplicado.
A diferencia de la práctica localmente aceptada,el diseño se realizaráde arriba a abajo. Desde el caso de uso deseado por el usuario, no desde los fundamentos de ingeniería del terminal.
Es decir, declaras el diseño no desde la base de ingeniería del terminal y con el primer listado estás profundamente atado a la base de ingeniería de los terminales. Estás tan atado que incluso utilizas macros de compilación condicional, porque no puedes prescindir de ellas, incluso al más alto nivel de usuario.
En principio, puede utilizar una entrada como esta dentro de GetData OnCrossSignal. Potencialmente, incluso podría escribir guiones :-) Pero todo a su tiempo... El manejo de los datos está construido como una mesa electrónica.
Así está mejor, empiezas a entender lo que quiero decirte. Si declara un enfoque de arriba a abajo, empiece por arriba. Por eso, el "todo a su tiempo" no vuelve a funcionar. Esta es la primera prioridad.
¿Se está inventando EasyLanguage? Como muchos asesores de MT4 que he visto, todos ellos están escritos a través de MT4-API, sin envolturas complejas. Aparentemente es más sencillo y fiable, ya que el código sale muy conciso.
Si, por ejemplo, utilizamos tal MT5-wrapper para el comercio, o tal para MAX, entonces sería fácil sólo para el autor de estas envolturas.
¿Se está inventando EasyLanguage? Como muchos asesores de MT4 que he visto, todos ellos están escritos a través de MT4-API, sin envolturas complejas. Aparentemente es más sencillo y fiable, ya que el código sale muy conciso.
Si, por ejemplo, utilizamos tal MT5-wrapper para el comercio, o tal para MAX, entonces sería fácil sólo para el autor de estas envolturas.
Estoy de acuerdo, y el desarrollo y el apoyo en el futuro es importante para usar y aprender algo. Ejemplo tonto pero aun así, saldrá mql6 o un nuevo tipo de órdenes, el punto era tratar con estos envoltorios si todavía hay que leer mana en este sitio.
Aleksei Beliakov: Estoy de acuerdo, y el desarrollo y apoyo en el futuro es importante para usar y aprender algo. Ejemplo tonto, pero aún así, mql6 saldrá o nuevo tipo de órdenes, el sentido era tratar con estas envolturas si todavía tiene que leer maná en este sitio.
Lees maná, bebes pita, comes comida...
Es muy fácil añadir nuevos objetos a una estructura bien organizada mientras fumas pollos y escuchas rumores :)
Bueno, lo escribes correctamente. Pero el usuario entiende mucho mejor ese pseudocódigo:
Otra cosa es que sea mucho más difícil hacerlo funcionar de esta forma concreta (procedimental, aviso), pero aun así es posible. Esto es lo que hay que intentar conseguir: que las instrucciones a nivel de usuario sean lo más sencillas y abstractas posible. En su caso, el usuario necesita especificar macros de compilación condicional, funciones específicas para el cálculo de promedios y otros detalles técnicos que simplemente no puede manejar.
¿Y cuál es el problema de implementarlo? Escribes una clase universal como la diseñada por TC, luego la incluyes con un inluder y debajo de él, otro inluder con defines donde envolvemos las llamadas a métodos:
Aquí está:
Intentaré (o intentaré, si me interesa) hacer un marco para los EAs. Lo más adecuado posible sólo para cosas sencillas y que no requieran conocimientos sustanciales por parte del programador aplicado.
A diferencia de la práctica localmente aceptada,el diseño se realizará de arriba a abajo. Desde el caso de uso deseado por el usuario, no desde los fundamentos de ingeniería del terminal.
En principio, puede utilizar una entrada como esta dentro de GetData OnCrossSignal. Potencialmente, incluso podría escribir guiones :-) Pero todo a su tiempo... El manejo de los datos está construido como una mesa electrónica.
Así está mejor, empiezas a entender lo que quiero decirte. Si declara un enfoque de arriba a abajo, empiece por arriba. Por eso, el "todo a su tiempo" no vuelve a funcionar. Esta es la primera prioridad.
¿Se está inventando EasyLanguage? Como muchos asesores de MT4 que he visto, todos ellos están escritos a través de MT4-API, sin envolturas complejas. Aparentemente es más sencillo y fiable, ya que el código sale muy conciso.
Si, por ejemplo, utilizamos tal MT5-wrapper para el comercio, o tal para MAX, entonces sería fácil sólo para el autor de estas envolturas.
¿Se está inventando EasyLanguage? Como muchos asesores de MT4 que he visto, todos ellos están escritos a través de MT4-API, sin envolturas complejas. Aparentemente es más sencillo y fiable, ya que el código sale muy conciso.
Si, por ejemplo, utilizamos tal MT5-wrapper para el comercio, o tal para MAX, entonces sería fácil sólo para el autor de estas envolturas.
Estoy de acuerdo, y el desarrollo y apoyo en el futuro es importante para usar y aprender algo. Ejemplo tonto, pero aún así, mql6 saldrá o nuevo tipo de órdenes, el sentido era tratar con estas envolturas si todavía tiene que leer maná en este sitio.
Bueno, lo escribes correctamente. Pero el usuario entiende mucho mejor ese pseudocódigo:
Otra cosa es que sea mucho más difícil hacerlo funcionar de esta forma concreta (procedimental, aviso), pero aun así es posible. Esto es lo que hay que intentar conseguir: que las instrucciones a nivel de usuario sean lo más sencillas y abstractas posible. En su caso, el usuario necesita especificar macros de compilación condicional, funciones específicas para el cálculo de promedios y otros detalles técnicos que simplemente no puede manejar.
¿Y cuál es el problema de implementarlo? Escribes una clase universal como la diseñada por TC, luego la incluyes con un inluder y debajo de él, otro inluder con defines donde envolvemos las llamadas a métodos:
la implementación está oculta para el usuario, pero se necesitará la facilidad de uso
así que
Nada de comercio, por favor.