Qué significa la anotación en el cuaderno de bitácora - página 4
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
Y órdenes pendientes:((
Registro 1:
Intentando comprar, intento 0 fallido, error 6
Tratando de comprar, intento 1 fallido, error 129
Tratando de comprar, intento 2 fallido, error 129
Tratando de comprar, intento 3 fallido, error 129
Intentando comprar, intento 4 fallido, error 129
Error de compra en zigzag: 4050
2.28000000, 0.02700000, 0.00000000
Intentando comprar, intento 0 fallido, error 6
Tratando de comprar, intento 1 exitoso
El pedido se abrió al séptimo intento. Se recibieron varios mensajes de error en el camino y no tenían nada que ver con la realidad.
Registro 2.
7.9.2005 11:0:15, Señal: vender7.9.2005 11:0:15 Intentando vender, intento 0.
Ask: 1.24820000, StopLoss: 0.00600000, TakeProfit: 0.00000000
falló, error 6
7.9.2005 11:0:15 Tratando de vender, intento 1.
Ask: 1.24820000, StopLoss: 0.00600000, TakeProfit: 0.00000000
éxito
En el segundo intento. El error número seis fue objeto de toda una rama, más de cien posts. Siguiendo el consejo de los desarrolladores, Rosh y Composter, la frecuencia de los errores se redujo de "de vez en cuando" a "aproximadamente una de cada cinco". Pero sigue ahí.
Registro 3.
Intentando cerrar una posición larga, ticket: 1784257
6.9.2005 12:0:13 El pedido con este billete sigue presente, intentándolo de nuevo
6.9.2005 12:0:13 El pedido con este billete sigue presente, intentándolo de nuevo
6.9.2005 12:0:13 El pedido con este billete sigue presente, intentándolo de nuevo
6.9.2005 12:0:13 El pedido con este billete sigue presente, intentándolo de nuevo
6.9.2005 12:0:13 El pedido con este billete sigue presente, intentándolo de nuevo
Cinco fallos, no había ningún código de error. El programa pensaba que esa posición estaba cerrada. Estaba cogiendo el billete en el bucle, si no lo hacía, no se detectaba el problema.
Y así sucesivamente.
{
int nTicket = OrderTicket();
SaveComment("Intentando cerrar la posición larga, ticket: " + nTicket);
int nResult = OrderClose(OrderTicket(), OrderLots(), Bid, nSlip, Aqua);
Sleep(10000);
if(nResultado == -1)
{
int nError = GetLastError();
Alert(strExpertName + ", error: " + nError);
}
}
Tuve que usar una cita para poner el texto en negrita.
El objetivo de Sleep es esperar hasta que la condición que causa el fallo desaparezca (ya sabes, los pings empiezan a pasar). Porque - teniendo en cuenta que las operaciones comerciales "toman" el control y no lo dejan hasta que vuelven, entonces si hay un error, debería aparecer inmediatamente. Si no es así, es un error.
La única excepción posible es mi bucle de comprobación de una entrada de una posición recién cerrada. Pero incluso aquí podemos discutir cómo debería comportarse el sistema de forma ideal.
Una vez más, el problema no es sólo que los errores se devuelvan, sino que los códigos de error se toman del techo, y a veces no hay códigos en absoluto - se devuelve el código de éxito de la operación.
Si no entiendo algo, por favor, explíquelo.
1. Se envía un SMS informando de la intención de retirar dicha orden.
2. Se intenta cancelar el pedido
3. Se analiza el resultado de la función OrderDelete() y si es negativo (la orden no ha sido eliminada), entonces
4. Envía un SMS confirmando el fallo.
Ayer recibimos 2 SMS, todo de acuerdo con las reglas pero el pedido fue cancelado en el mismo segundo, según los registros.
Así que el EA estaba tratando de obtener el resultado de la operación de cancelación de la orden una fracción de segundo antes de obtener el resultado. Es como en el chiste de los chinos que plantaron patatas y las desenterraron al día siguiente. Cuando se les preguntaba "¿Está madurando tan rápido?", decían "No, pero está picando" :)
1. Hice todo este alboroto sobre los pedidos reales. Y si se comportan así, hay que arreglarlo.
2) La idea es que los EAs de MT sean capaces de operar SIN un ciclo retardado. Así es como debe ser.
Pondré un retraso, pero, como se dice, "sin gusto" :)
Yo tampoco me lo creo, ¿pueden los desarrolladores explicarme lo equivocado que estoy?
Es un poco vergonzoso el hecho de que para 37 mensajes en este hilo sólo hay uno de los desarrolladores...
por qué interferir en una discusión ya productiva
y aquí están los productos =)
Hice algunas pruebas. Un Asesor Experto abre y cierra una posición (alternativamente compra y vende). Pausa mínima entre todas las operaciones - 10 seg.
OrderSend attempts: 996
Successful*: 888
Errores**: 108
* - Por intento "exitoso" me refiero a lo siguiente: orderSend devolvió el número de ticket, GetLastError devolvió 0, posición abierta seleccionada con éxito orderselect.
** - Todos los errores #148 "el contexto comercial está ocupado" - eso es lo que preguntó Slava en un hilo vecino - "¿y si desactivamos la comprobación isTradeAllowed?". Los errores comenzaron a las 07:16:46 y siguen acumulándose)
-----------------------------------------------------------------------------------------------------------------------
Intentos de OrderClose: 890
Exitoso*: 736
Errores**: 154
* - Por intento de cierre "exitoso" me refiero a lo siguiente: orderclose devolvió true, GetLastError devolvió 0, posición cerrada seleccionada con éxito orderselect en mod_history.
** - 152 error #1 "sin error", uno #6 y uno #138(requotes)
La situación que se captó no se produjo. Es decir, todas las posiciones cerradas estaban efectivamente cerradas.