Errores, fallos, preguntas - página 989
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
No, todas las máquinas son individuales. Incluso los ejes tienen licencia, desde grusha hasta WS. Tengo una sensación de presunción de culpabilidad... Voy a tener que poner excusas... Justificarme... Registros, esto y aquello...
Debería prohibirse la venta de más agentes de cierre que de núcleos, ¡y ya está!
...
Y poner más agentes de cierre que núcleos debería estar prohibido por ley, ¡eso es todo!
Buenas tardes. Tengo una pregunta para los desarrolladores. El ciclo ideal de generación de transacciones consta de los siguientes pasos:
1.Envío de una solicitud a través de OrderSend() seguido de la comprobación de que el método devuelve true y retcode correcto.
2.A continuación, hay que seguir el paso de la solicitud en el servidor mediante OnTradeTransaction(). Este manejador es muy práctico y da un control total sobre el proceso.
Pero vivimos en el mundo real y, por ejemplo, debido a un fallo de conexión o simplemente porque la transacción se "perdió en la entrega", es posible que no esperemos una transacción como TRADE_TRANSACTION_REQUEST. De este modo, el ciclo de espera se hará interminable y será imposible determinar si la transacción se ha completado a petición o no.
¿Existe algún procedimiento de fondo para manejar tales emergencias con la obtención inequívoca de una finalización del proceso lógicamente correcta para cualquier fuerza mayor? Por ejemplo, si no esperamos a TRADE_TRANSACTION_REQUEST en 20 (o 30 o 40) segundos, entonces cambiamos a un algoritmo más lento pero correcto, a saber: comparamos el volumen actual del símbolo con el volumen antes de OrderSend(), buscamos en el historial de órdenes y calculamos su estado y decidimos si hacer una solicitud más para abrir o saltar la señal. La tarea se complica aún más para el método OrderSendAsync(): tenemos que tener un criterio preciso de cuándo una determinada orden no se ha disparado y saber cuándo empezar a aplicar ese criterio. Si he entendido algo mal, por favor, corríjanme.
Para el método OrderSendAsync(), la tarea es aún más complicada - necesitamos tener un criterio exacto para que una orden específica no se dispare y saber cuándo empezar a aplicar ese criterio. Si he entendido algo mal, por favor, corríjanme.
HistorySelectByPosition - en teoría, debería ayudar, el id se da cuando se envía la orden.
VanHelsing:
Los sistemas Win7 de 32x tienen problemas con las operaciones con números reales, en XP se niega a funcionar al pasar valores a la librería"wininet.dll".
1. Establezca como regla el envío de órdenes comerciales en el tick actual y la comprobación de su ejecución en el siguiente tick. Así no tendrás bucles interminables.
2. Cuando se comprueba la ejecución de las órdenes dadas durante el tick anterior, no se molesta con OnTrade()/ OnTradeTransaction(). Comprueba los cambios en el estado de tu cuenta, es decir, trabaja con la fuente. Al fin y al cabo, cualquier acuerdo comercial tiene como objetivo cambiar un estado de su cuenta comercial. Así que comprueba el cambio de estado.
3. Dependiendo de los resultados de las pruebas y hacer más lógica de su robot.
Antes de utilizar funciones como OnTrade()/OnTradeTransaction(), decida qué es más importante para usted:
a). lograr la apertura/cierre/modificación de una posición en unas condiciones de mercado determinadas;
b) Perder el tiempo tratando de averiguar la razón por la que no se ejecutó su orden de negociación, y buscar a alguien a quien culpar.
Aun así, me queda algún malentendido. Si los resultados de la comprobación en el siguiente tick NO muestran ningún cambio en la posición, entonces qué debemos hacer en este caso. Las razones de la ausencia de cambios pueden ser muy diferentes. Como alternativa:
se formó un pedido en el servidor, pero fue rechazado por alguna razón,
el servidor está sobrecargado: la ejecución se retrasa,
la conexión se pierde durante algún tiempo.
Nos gustaría tener un criterio exacto para que la orden no se ejecute. La vinculación con el tiempo en un sistema asíncrono no me parece muy precisa y, por tanto, permite la incertidumbre. Tal vez tenga sentido seleccionar la orden en el historial y comprobar su estado, o, como sugiere sion, utilizar HistorySelectByPosition. Supongo que si los desarrolladores diseñaron este sistema de esta manera, entonces debería haber métodos "correctos" para manejar tales operaciones clave.
Queremos tener un criterio exacto para que la orden no se ejecute
Ya se le ha explicado que
no te molestes con OnTrade()/ OnTradeTransaction().
Trabaja con el código fuente.
Hola a todos.
¿Cómo puedo hacer que todo el contenido de la pestaña "Expertos" se sobrescriba al iniciar el script? (Como el comando cls), porque puede ser difícil distinguir dónde ha terminado la salida de impresión del inicio anterior del script y el actual.
¡¡¡Gracias!!!
Hola a todos.
¿Cómo puedo hacer que todo el contenido de la pestaña "Expertos" se sobrescriba al iniciar el script? (Como un comando cls), porque puede ser difícil distinguir dónde ha terminado la salida de impresión del inicio anterior del script y el actual.
¡¡¡Gracias!!!
Añade la siguiente línea al script deinit
Print("===================== El final ===================")