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
Parece que no hay manera de saber en MT4 (sin volver a conectarse) si el apalancamiento de la cuenta ha cambiado.
Parece que no hay manera en MT4 para saber (sin volver a conectar) si el apalancamiento en la cuenta ha cambiado.
Lo hice hace unos cinco años. El apalancamiento del cliente se redujo a ciertas horas, y no cambió en la variable AccountInfoInteger(ACCOUNT_LEVERAGE). Y tenía que saberlo.
No sé la ciencia, pero he decidido que hay un apalancamiento de la cuenta que cambia pocas veces, y hay un apalancamiento del símbolo que puede cambiar varias veces al día.
Lo he comprobado así:
A veces el apalancamiento calculado por el símbolo leverageSymb puede dar 199, 198 en lugar de 200 (cuando el apalancamiento es 1:200). Por lo tanto, tuve que restar un determinado % del apalancamiento estándar y compararlo con este valor. La solución anterior fue útil en su momento, puede ser útil.
Lo hice hace unos cinco años. A un cliente se le redujo el apalancamiento a ciertas horas, y no cambió de ninguna manera en la variable AccountInfoInteger(ACCOUNT_LEVERAGE). Y tenía que saberlo.
No sé la ciencia, pero he decidido que hay un apalancamiento de cuenta que cambia raramente, y hay un apalancamiento de símbolo que puede cambiar varias veces al día.
Lo comprobé de esta manera:
A veces el apalancamiento calculado por el símbolo leverageSymb puede dar 199, 198 en lugar de 200 (cuando el apalancamiento es 1:200). Por lo tanto, tuve que restar un determinado % del apalancamiento estándar y compararlo con este valor. La solución anterior ayudó entonces, podría ser útil.
Sí, no hay ningún problema con el seguimiento de los requisitos de margen del símbolo. ACCOUNT_LEVERAGE - sólo reconectar.
Es una práctica muy común filtrar el historial de operaciones recordando las órdenes requeridas en una lista de entradas. Y luego SELECT_BY_TICKET en esa lista.
Nunca he visto una variante en la que no se memorice un billete sino una posición. A continuación se muestra una comparación del rendimiento.
Vemos que la variante del billete pierde casi tres veces en rendimiento.
Se puede ver que la variante del billete pierde casi tres veces en rendimiento.
si una posición está cerrada/abierta, la lógica con el ticket no se romperá, la lógica con la posición podría.
si una posición está cerrada/abierta, la lógica con el ticket no se romperá, la lógica con la posición puede.
Sólo se trata del modo MODE_HISTORY.
¿Es teóricamente posible que este código pierda algún orden que existía ANTES y DESPUÉS de llamar a la función? O contará dos veces.
Es decir, ¿qué ocurre con la indexación cuando se elimina un pedido o aparece durante la enumeración?
O contará dos veces.
Si asumimos una ordenación por defecto por tiempo o por ticket, los nuevos pedidos aparecen al final de la lista, y lógicamente todos se desplazan cuando se borran los más antiguos.
Resulta que al borrar una orden del principio de la lista se puede tener en cuenta una de las listas dos veces. Parece fácil de solucionar: basta con recordar el billete de la pasada anterior y comparar (pero todavía no hay garantía).
Cómo conseguir un pase en el pase de vuelta - no se ha descubierto
Si asumimos una ordenación por defecto por tiempo o por ticket, los nuevos pedidos aparecen al final de la lista, y lógicamente todos se desplazan cuando se borran los más antiguos.
Resulta que al borrar una orden del principio de la lista se puede tener en cuenta una de las listas dos veces. Parece fácil de solucionar: basta con recordar el billete de la pasada anterior y comparar (pero todavía no hay garantía).
Cómo conseguir un pase en el pase de vuelta - no lo he resuelto
Gracias por la detallada respuesta. Así que ahora me pregunto cómo pasar por TODOS los pedidos de una sola vez.