MetaEditor build 1490 - 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
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
Desde hace algún tiempo, cuando se invierte una posición se cambia su ID de posición. Esto se muestra en la ayuda. De ahí las incoherencias.
Ese no es el problema.
El servicio de atención al cliente ha dicho que lo van a arreglar, y que la solución estará disponible en la versión de hoy.
El servicio de atención al cliente ha respondido que la solución estará disponible en la versión de hoy.
1491 - no se ha arreglado.
Por desgracia, no.
Por cierto, no está nada claro cómo el actual sistema de contabilidad de posiciones separará la parte de la posición que cerró la posición anterior y la parte restante de la nueva posición (esta división no existe en la actualidad). Parece que el problema es más profundo de lo que parece a primera vista.
Por desgracia, no.
Por cierto, no está nada claro cómo el actual sistema de contabilidad de posiciones separará la parte de la posición que cerró la posición anterior y la parte restante de la nueva posición (esta división no existe en la actualidad). Parece que el problema es más profundo de lo que parece a primera vista.
Foro sobre comercio, sistemas de comercio automatizados y pruebas de estrategias
MetaEditor build 1490
fxsaber, 2016.12.05 11:32
Sí, aunqueDEAL_ENTRY_INOUT esté incluido en el número de operaciones de la posición, no servirá de nada a menos que se amplíe ENUM_DEAL_PROPERTY_*.Más o menos lo mismo
En mi opinión, por el contrario, la enumeración no debería ampliarse, sino acortarse. Así queDEAL_ENTRY_INOUT es una entidad innecesaria que no hace nada.
Este es un ejemplo de cómo se ve ahora
IN; +1.0; ID 0
IN; +0,2; ID 0
IN/OUT; -2.0; ID 1 // se ha creado una nueva posición con un nuevo ID pero no hay operaciones en ella; todas las operaciones se refieren a la posición anterior; por lo tanto la comisión y los swaps son 0.0
IN; +0.2; ID 1 // el primer comercio apareció en la lista y es el único
por lo tanto, una parte del volumen no se trasladó a una nueva posición y no se muestra en ninguna parte, por lo que los swaps y las comisiones no se tendrán en cuenta para esta parte del volumen en la posición ID 1 (listas de operaciones correspondientes en azul y verde)
Ahora como lo veo yo, y como debería ser lógica e históricamente (la decisión que tome MQ no la sabe nadie):
IN; +1.0; ID 0
IN; +0,2; ID 0
OUT; -1.2; ID 0 // la parte del volumen de la operación que ha ido a la posición que se cierra
IN; -0.8; ID 1 // ha aparecido una nueva posición con el nuevo ID, la operación está presente como resto, la operación está en la lista, y es la primera
IN; +0.2; ID 1 // la segunda operación de la lista
Por lo tanto, el tipo de acuerdo IN/Out no es necesario en absoluto. De este modo, si todo se considera correctamente y se completan las listas de operaciones en posición, podemos obtener adecuadamente los valores de las comisiones y los swaps de las operaciones correspondientes. Y si hay necesidad de determinar qué operaciones (una parte fue al cierre y la otra a la apertura de una nueva posición) son parte de una orden, será muy fácil hacerlo - las operaciones de salida y entrada tienen el mismo tiempo (marcado en negrita).
En mi opinión, por el contrario, la enumeración no debería ampliarse, sino acortarse. Así queDEAL_ENTRY_INOUT es una entidad superflua que no hace nada.
Una transacción es una entidad de ejecución que no depende de la plataforma. Y las banderas de ENTRADA son una tontería de MQ.
Si hubiera una operación en el mercado, no se puede representar como dos, aunque sería conveniente.
MQ se ha esforzado por añadir la virtualización: el modo Hedge. Hacer incluso una simple virtualización para un intercambio es una mala decisión.
Pero la ampliación de las propiedades de las transacciones proporciona comodidad sin las posibles muletas.
Una transacción es una entidad de ejecución que no depende en absoluto de la plataforma. Y las banderas de ENTRADA son un artificio de MQ.
Si hubiera una operación en el mercado, no se puede representar como dos, aunque sería conveniente.
MQ se ha esforzado por añadir la virtualización: el modo Hedge. Hacer incluso una simple virtualización para un intercambio es una mala decisión.
Pero la ampliación de las propiedades de la transacción ofrece comodidad sin posibles muletas.
Bueno, sólo estaba exponiendo mi opinión.
¿Y qué tipo de extensión salvaría el día? Todavía hay que determinar de alguna manera qué parte de la transacción se refiere a la posición antigua y cuál a la nueva.
¿Y qué tipo de ampliación salvaría la situación? Todavía hay que determinar qué parte del acuerdo es para el antiguo puesto y cuál es para el nuevo.
1491 - Alpari-MT5-Demo. Las capturas de pantalla muestran el mismo lugar
Terminal
Probador de garrapatas real
Los candelabros no se corresponden entre sí: en el probador están borrosos. Además, el tiempo histórico del probador y del terminal difiere en una hora.
CopyTicks en el terminal devuelve los mismos datos que en el probador - una hora de diferencia. Por lo tanto, los ticks no coinciden completamente con las barras.
Entonces, ¿cómo confiar en MT5, el probador, cuando hay un completo autodescrédito? ¿Por qué los desarrolladores no tienen EAs de referencia para ejecutar en el probador y saber con seguridad que funciona claramente? Es un completo desastre.