Procesamiento de OnTradeTransaction - página 6
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
Buenas tardes.
Nadie se deja intimidar por nadie.
No tiene switch(trans.type)
Bueno, por supuesto el caso dado está en switch(trans.type). Como había otro caso no quise mostrar todo el código para no sobrecargarlo con información innecesaria.
fxsaber , ¡gracias por el ejemplo!
Alexey, es exactamente lo mismo. Estoy usando 2 robots diferentes para operar con el mismo símbolo en modo de red. Esos 2 posts que citaste se complementan.
Es interesante resolver el problema a partir del disparador de cambio principal - onTradeTransaction.
Total de problemas actuales encontrados:
1. deal_add se dispara, pero no se posa. No hay pensamientos hasta ahora.
2. deal_add se activa, pero la orden está en la tercera dimensión. Poner un resbalón, el último par de días parece ayudar. La orden consigue llegar a la historia en 1 segundo. No tengo robots de negociación de alta frecuencia y no utilizo órdenes de mercado, por lo que esta solución sería adecuada.
3. deal_add se activa 2 veces, es decir, un mismo deal_add se activa 2 veces. Esto puede resolverse comprobando el ticket de un acuerdo anterior y comparándolo con el actual.
Queda el punto 1. Explicaciones para ello.
Ayer puse sell_limit, funcionó, llegó deal_add, pero no apareció la posición y abrimos una orden stop para nada. Me puse a mirar la descripción de la transacción y vi que el tipo de operación es DEAL_TYPE_SELL pero el tipo de orden es ORDER_TYPE_BUY. Al mismo tiempo, el billete de pedido es nuestro. No parecía muy lógico. He decidido comprobar que el tipo de orden y el tipo de operación deben ser iguales en OnTradeTransaction, que el tipo de orden y el tipo de operación deben ser iguales.
Activé el Asesor Experto en la demo y obtuve otra transacción similar pero esta vez la posición ha cambiado. Pero debido a nuestra comprobación la orden de stop no se ha ejecutado. ¿Qué está pasando?
Te diré de inmediato que esto es lo que está llegando a la terminal. Sin que me lo invente.
Ayer coloqué sell_limit, se activó, llegó deal_add, pero no apareció ninguna posición y abrimos órdenes de stop para nada. He empezado a mirar la descripción de la transacción y he visto que el tipo de operación es DEAL_TYPE_SELL y el tipo de orden es ORDER_TYPE_BUY. Al mismo tiempo, el ticket de pedido es nuestro. No parecía muy lógico. He decidido comprobar que el tipo de orden y el tipo de transacción deben coincidir en OnTradeTransaction en la transacción deal_add.
Pero aquí vale la pena releer la ayuda"Estructura de las transacciones comerciales" - en cuanto a los campos que se rellenan para el tipo deal_add.
Y tomar las propiedades del pedido no de la transacción (donde no se rellenan, pero los ceros también corresponden a algunos valores en enum-type), sino del propio pedido, si está disponible en el momento (y no en el proceso de transición de los pedidos al historial).
Esto facilita el análisis de cómo van las cosas.
Puede añadir que, junto con las transacciones, también se puede registrar el estado de las posiciones, las órdenes actuales y el historial de operaciones. Entonces se dispondrá de la imagen completa.
Aquí es donde vale la pena releer la ayuda"Estructura de una transacción comercial", en cuanto a los campos que se rellenan para el tipo deal_add.
Y tomar las propiedades del pedido no de la transacción (donde no se rellenan, pero los ceros también corresponden a algunos valores del tipo enum), sino del propio pedido, si está disponible en ese momento (y no está en proceso de transición de los pedidos al historial).
Estoy de acuerdo, era consciente de ello, pero no presté atención. Gracias por recordármelo.
Sin embargo, el problema de que una posición no aparezca en un caso y sí en otro sigue siendo poco claro.
Илья Ребенок:
Sin embargo, el problema de que la posición no aparezca en un caso y sí en el otro sigue sin estar claro.
La posición fue registrada en la transacción deal_add, pero la posición no existía antes y no aparecía? Esto tiene que solucionarse.
La posición fue registrada en la transacción deal_add, pero la posición no estaba allí antes y no apareció? Esto debe solucionarse.
la posición no existía antes
la posición no existía antes
¿Hubo un boleto de posición en la transacción?
¿Hubo un boleto de posición en la transacción?
En el post anterior debo haber cometido un pequeño malentendido. Hubo una posición, luego se cerró con órdenes de stop. Es decir, el número de posiciones pasó a ser 0. Entonces se activó una operación, pero la posición no apareció.
Creo que esto es lo que quieres decir. La transacción contenía información sobre el billete de la posición, pero este billete = billete de la orden anterior. Como debería ser en el modo de red, si entiendo bien.
Position: 82675534En el post anterior debo haber cometido un pequeño malentendido. Hubo una posición, luego se cerró con órdenes de stop. Es decir, el número de posiciones pasó a ser 0. Entonces se activó una operación, pero la posición no apareció.
Creo que esto es lo que quieres decir. La transacción contenía información sobre el billete de la posición, pero este billete = billete de la orden anterior. Como en general debe estar en modo de red, si entiendo bien.
Si la posición en el símbolo (acumulada, todos los robots y las operaciones manuales juntos) se convirtió en 0,0, la siguiente transacción abrirá (DEAL_ENTRY_IN) una nueva posición, con un nuevo ticket (==ticket de la orden).
En realidad, me parece que cuando se hace el netting, no hay necesidad de mirar la posición en absoluto - cada robot tiene que contabilizar "su" - como los resultados de las operaciones en sus órdenes.
La presencia de las posiciones y las banderas DEAL_ENTRY no deben intervenir en la lógica de ninguna manera.
Sólo tenemos que mirar la magia y el comentario de las nuevas operaciones y las órdenes actuales como identificadores de propio/extraño.
El código de trabajo mostró. Es exactamente lo mismo.
Tratar de resolver el problema a través de OnTradeTransaction es una mala idea por la cantidad de trampas. Lo que en una tarea particular a veces todavía puede ser evitado. Pero si cambias la tarea sólo un poco, toda la lógica se rompe durante la implementación de OnTradeTransaction.
Los desarrolladores han creado un modelo de comercio basado en eventos, pero no han proporcionado un solo ejemplo de funcionamiento. Porque es una completa gilipollez lo que vierte el código y lo mucho que depende de cada ejemplo.
Por lo tanto, yo recomendaría mirar las operaciones de comercio sincrónico y la función OnTrade. Todo es mucho más fácil allí y la lógica es muy flexible para los cambios. Además, es más fiable.
La transición a Async+Transactions es comparable a la transición del lenguaje de alto nivel al ensamblador. Es decir, debe hacerse en la última etapa de la creación de la ST, cuando está TOTALMENTE investigada, lista para ser REAL y lo último es acelerar las operaciones de comercio SIN cambiar la lógica de comercio.