¿Con qué sustituir OnTradeTransaction() en mql4? - 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
Si necesitamos una solución rápida, entonces colocaría todos los tickets a CArrayInt y compararía los tickets de las órdenes abiertas con CArrayInt; el método Search() está ahí; si no hay ningún ticket, dejamos de comparar CArrayIntcon los contadores de órdenes abiertas, reiniciar CArrayInt y escribir todas las entradas en CArrayInt de nuevo y establecer globalmente la bandera descrita MyOnTradeTransaction - esto es una señal de que la lista de órdenes ha cambiado - el código será bastante compacto
Y cuando necesitamos atrapar algo más que la pérdida del orden, es cuando empezamos a bailar con diamantes...
La comprobación de OrdersTotal() no mostrará, por ejemplo, la activación de una orden pendiente - el número de órdenes sigue siendo el mismo, así como los tickets... Y cuando necesitamos captar el hecho de la modificación del orden/posición...
Todo, sin embargo, ya está pensado, hecho y puesto en el dominio público con explicaciones...
¿Cuáles son esas ventajas que niego? Sólo tengo una negación. Quiero entender cómo funciona algo, y si sólo puede entenderlo alguien que no sea mi mente, entonces no me siento cómodo usándolo, y cualquier cosa con la que no me sienta cómodo la niego. Ya te he dicho que escribes más cartas de las que puedo leer en el resto de mi vida. No la tomes conmigo...
Los pros son que ningún evento puede perderse. A diferencia de OnTrade() y OnTradeTransaction(). Pero no cree que tal evento pueda perderse... Por eso digo que la discusión no tiene sentido.
Y cuando se necesita atrapar algo más que una orden perdida, ahí es donde empieza la pandereta...
Comprobar OrdersTotal() no mostrará la activación de una orden pendiente, por ejemplo - el número de órdenes es constante, las entradas, también... Y cuando necesitamos captar la modificación de una orden/posición...
Sin embargo, todo ha sido ya pensado, hecho y puesto a disposición del público con explicaciones...
No sugiero analizar OrdersTotal, no es fiable.
No podrás hacer un seguimiento de las modificaciones de los pedidos de esa manera, tendrás que escribir tu propia clase basada en CArray o CObj.
He sugerido una solución rápida, no un trabajo fundamental ;)
Las ventajas son que no podemos perder eventos.
No estoy sugiriendo analizar OrdersTotal, no es fiable
la modificación de la orden no puede ser rastreada de esa manera, usted necesita escribir su propia clase basada en CArray o CObj
He sugerido una solución rápida, no una obra fundamental).
pueden si se pulsa el botón de reinicio del PC .... Hace tiempo que no sigo los artículos, pero recuerdo haber preguntado por la técnica de guardar el estado de las clases en un archivo en caso de que se reinicie el terminal, ¿ya está implementada?Y también se puede lanzar un ordenador desde el balcón - para una pérdida fiable :) Y que el rodillo espere abajo. Entonces también puedes verter hormigón encima :)))
No, no está implementado - no es lo principal ahora. Es casi hasta el final - es más fácil hacer todo de una sola vez, en lugar de dividirlo en diferentes franjas de tiempo. Para mí.
No, no se implementa - eso no es lo principal ahora. Es casi al final - es más fácil hacer todo del mismo tipo de una sola vez, en lugar de dividirlo en diferentes franjas de tiempo. Para mí.
Bien, esperemos
Pero me ha resultado lo contrario - ya me he encontrado con este problema - no puse la posibilidad de guardar en la estructura del programa, y empecé a escribir guardando en un archivo, muy engorroso todo ha resultado.... Ya me encontré con este problema - no puse guardar en un archivo en la estructura del programa - empecé a escribir guardar en un archivo y resultó ser muy engorroso - me rendí y volví a escribir la mayor parte del código desde cero - es un trabajo minucioso, tendré que analizar todo el código fuente
Te agradecería que me dieras algún ejemplo reproducible (sin la encuesta del historial comercial).
Estaré encantado de devolverle su utilidad. Lamentablemente, tengo dificultades para forjar un código corto que funcione a partir de un código muy grande y complejo. Que además es muy específico (por ejemplo, sólo abre una postura a la vez).
Así que para Slava tuve que publicar un esqueleto de código en lugar de un ejemplo compilable.
Pero intentaré hacer algo, si no mi conciencia me atormentará. Pero no rápidamente.
PD: Me refiero a que tengo una productividad muy baja a la hora de escribir código. Sólo lo tomo por persistencia. Y al mismo tiempo - super ocupado en traer el EA hasta la velocidad para ejecutar en una cuenta real. Envidio su productividad.
Bien, esperemos
Pero me ha resultado lo contrario - ya me he encontrado con este problema - no puse la posibilidad de guardar en la estructura del programa, y empecé a escribir guardando en un archivo, muy engorroso todo ha resultado.... Ya me he encontrado con este problema - no puse guardar en un archivo en la estructura del programa y empecé a escribir guardar en un archivo, resultó ser muy engorroso y pesado - entonces me di por vencido y volví a escribir la mayor parte del código desde cero - imho, si quieres guardar en un archivo, debes implementarlo inmediatamente, al menos con "stubs", de lo contrario tendrás que recoger todo lo que quieres guardar en cada clase - un trabajo muy laborioso, de hecho tienes que analizar todo el código fuente
Los métodos de guardar/cargar se declaran inicialmente. Y en el objeto base CObject de la biblioteca estándar. La implementación de guardar en un archivo en cada objeto de la biblioteca se puede describir para uno o dos objetos. Pero para escribir en cada artículo las descripciones de los métodos de ahorro / carga - será bastante aburrida lectura de casi la misma "acción" de un artículo a otro, y simplemente omitir - no es agradable para el lector (y por lo que algunas personas dicen que es difícil para ellos para leer tales volúmenes de artículos, creo que - usted también). Por lo tanto - esta tarea para la descripción en dos o tres artículos más cerca del final - de una sola vez en un solo golpe, y no demasiado agobiar al lector.
Otra cosa sería que no se describiera nada en los artículos, entonces por supuesto que sería necesario de inmediato. Todo depende de los detalles de la historia y de los objetivos. Si el propósito - kodobaza, entonces todo a la vez, y si el propósito - artículos de formación - entonces poco a poco - cuando llegue el momento. Tengo la segunda opción.
Se ha vuelto a mencionar el OnTradeTransaction. No hay problema en garantizarOnTradeTransaction en caso de pérdida de conexión, etc., ya que el terminal seguirá sincronizando el entorno de negociación una vez que se restablezca la conexión. ComoOnTrade es secundario, significa que puede confiar en ellos. Si los propios desarrolladores no se equivocaron, sino que eliminaron la cláusula, significa que todo está bien.
Pero para encajar en cada artículo descripciones de los métodos de ahorro / carga - será bastante aburrido leer casi la misma "acción" de un artículo a otro, y simplemente omitir - no es agradable para el lector (y por lo que algunos dicen que tienen dificultad para leer tales volúmenes de artículos, creo que - usted también). Por lo tanto - esta tarea para la descripción en dos o tres artículos más cerca del final - a la vez en un solo golpe, y no demasiado carga el lector.
No he dicho que el volumen de artículos a leer sea muy grande, sino que he escrito que la cantidad de fuentes es enorme e imposible de averiguar cómo utilizarla sin algún tipo de ayuda/FAQ
Esperaré a la implementación de guardar tal cantidad de datos, es interesante ver cómo será
La implementación de guardar tantos datos tendrá que esperar, será interesante ver cómo será
ok