Preguntas de un "tonto" - página 12
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
POR FAVOR, AVISE SOBRE EL TERMINAL DE TELEFONÍA MÓVIL.
CUÁNDO Y CUÁNDO SE REALIZARÁ CUALQUIER APOYO A LOS INDICADORES DE USO (NO ESTÁNDAR) O CONSULTA SOBRE mql4 O mql5?????????????????????????????
EN QUÉ PLATAFORMAS (ANDROID POR EJEMPLO) SE IMPLEMENTARÁ????????????????? Y CUAN PRONTO?????????????
a la espera de la respuesta, gracias por el aviso
Interesting:
Pues yo no estoy de acuerdo con esa conclusión. OCO == "uno anula al otro". Bueno, no existe tal cosa en MT5 donde una orden cancela a la otra. Llevo un año arrepintiéndome.Funciones como el SL y el TP realmente cierran una posición abierta, pero el tema de la "cancelación" de órdenes pendientes no tiene nada que ver.
Lo hacen, pero estas órdenes se implementan en el servidor. Y son las únicas realmente integradas en el esquema OCO hasta ahora (y no se nos ocurriría implementar las órdenes "If Done" directamente en el terminal y en el servidor).
Al abrir una posición y establecer el TP y el SL en MT5 utilizamos esencialmente la misma forma (pero el resultado aquí es posición + 2 órdenes canceladas).
Después de su mensaje, ya he comentado esta situación teniendo en cuenta los detalles del SL y el TP cancelados indistintamente. Sin embargo, aquí me gustaría añadir lo siguiente.
Si a los autores de las órdenes OCO se les hubiera dicho que en el siglo XXI su invento sólo se aplicaría a los niveles SL y TP, se habrían sorprendido mucho al ver tanta limitación del ámbito de aplicación de su ocurrencia :) .De hecho, todo está al revés: todos los materiales que se leen se refieren a lo mismo: las órdenes CCA son órdenes intercambiables cuyos tipos se especifican ahora en la enumeración MQL5 ENUM_ORDER_TYPE. Nunca he encontrado ninguna mención a la conexión entre las órdenes CCA y los niveles SL-TP. Por lo tanto, el mecanismo de ejecución puede ser el mismo pero son las órdenes ENUM_ORDER_TYPE las que ejecuta el cliente pero no los niveles SL-TP (según MQ).
Así que cuando escribo sobre órdenes pendientes me refiero a órdenes de la lista ENUM_ORDER_TYPE y no a órdenes "derivadas" basadas en los niveles SL-TP.
______________
* El "derivado" porque cada una de las órdenes OCO puede tener diferentes niveles de SL-TP.
Señores, la raíz del entendimiento está en la simplicidad de la plataforma. Simplicidad para el 99% de los usuarios y un rechazo consciente de las complicaciones que el porcentaje restante de usuarios puede entender.
Hágase la pregunta "¿qué haría falta para atraer a X millones de usuarios a los mercados financieros? Con la suficiente experiencia, la respuesta se acercará a "hacer un sistema sencillo, eliminando la complejidad y uniendo a los comerciantes en un único ecosistema".
En lugar de amontonar los ajustes de las órdenes OCO (el panel no es realmente para la mente promedio) hemos ofrecido un esquema de gestión de órdenes muy simple y directo con SL/TP integrado. La gran mayoría de las órdenes OCO son sólo SL/TP para las posiciones actuales. Al poner SL/TP en el interior, hemos minimizado el número de órdenes adicionales y hemos simplificado enormemente la gestión de las operaciones.
ps: el problema del sistema de pedidos está cerrado
ps: el problema del sistema de pedidos está cerrado
ps: el problema del sistema de pedidos está cerrado.
Es una pena que no sea posible hacer SLs/TPs normales (fiables) para operaciones individuales (no posiciones totales).
Esto corta inmediatamente la capacidad de negociar (de forma fiable) múltiples estrategias en el mismo instrumento/cuenta.
Hali-vor no debe reanudarse, recuerdo la opinión de los desarrolladores (un instrumento = una posición = un SL y un TP)...
¿A qué tipo (long o ulong) pertenece realmente ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Identificador del Asesor Experto que ha colocado la orden (destinado a que cada experto coloque su propio número único)
largo
¿A qué tipo (long o ulong) pertenece realmente ORDER_MAGIC?
ENUM_ORDER_PROPERTY_INTEGER
ORDER_MAGIC
Identificador del Asesor Experto que ha colocado la orden (destinado a que cada experto coloque su propio número único)
largo
Creo que, el resultado debe ser convertido al tipo declarado en el código (puede haber un error de imprenta en la documentación).
Si hablamos de MqlTradeRequest, en este caso lo más probable es que sea (ulong).
En mi opinión, el resultado debería convertirse al tipo declarado en el código (puede haber una errata en la documentación).
En cuanto a MqlTradeRequest, en este caso lo más probable es que sea (ulong), pero probablemente long servirá sin problemas.
En general, la respuesta no está en el fondo. La pregunta era muy clara: "¿a qué tipo (long o ulong) pertenece realmente ORDER_MAGIC?"
Intentemos ser sustantivos:
1. Ambos tipos pueden declararse sin transformaciones.
2. Si sólo utilizas valores positivos de magik, es más rentable especificar su valor como ulong (porque hay un rango de valores posibles de 0 a 18 446 744 073 709 551 615).
3. Por otro lado, la clase CExpert de la Biblioteca Estándar aplica el valor largo en la inicialización (que permite especificar valores negativos, pero desplaza el rango de valores posibles). Así, al inicializar esta clase, el valor de magik puede ser ya de -9 22 3 372 036 854 775 80 8 a 9 223 372 036 854 775 808.
Esta declaración debe ser comprobada.
4. Pero ya en la clase CTrade (de la misma biblioteca estándar) el mago tiene un valor ulong, como debe ser en base a la estructura de la consulta.
Hagamos algunas conclusiones preliminares:
a) El trabajo con magik en las clases CExpert y CTrade no es consistente, ya que en el primer caso se especifica long, mientras que en el otro ulong;
b) Las clases en cuestión fueron desarrolladas por diferentes personas, o el conjunto y la estructura de los parámetros de ciertas funciones en CExpert fueron escritos pensando en CTrade (que puede o no haber existido todavía).
c) El trabajo de los expertos asociados al desarrollo y la documentación de la biblioteca estándar no es del todo coherente (aunque en su mayoría se observa un estudio bastante bueno de los temas clave).
d) Si he entendido bien, la interacción de estas dos clases limita el valor del mago a un rango de 0 a 9 223 372 036 854 775 808. Esta declaración debe ser verificada.
5. La estructura MqlTradeRequest tiene el tipo ulong para trabajar con magik. Todo es totalmente coherente con la clase CTrade, por eso es más lógico especificar el rango de valores posibles de mago de 0 a 18 446 744 073 709 551 615 si utilizamos sólo esta clase. Esta declaración debe sercomprobada.
PS
Creo que los desarrolladores han "sujetado" intencionadamente los posibles valores de un mago en el rango de 0 a 9 223 372 036 854 775 808.
Los desarrolladores parecen haber "atiborrado" deliberadamente los posibles valores de un magik en un rango de 0 a 9 223 372 036 854 775 808.
En realidad, hay hasta 8 bytes de información dados a la magia, que pueden ser interpretados como se quiera. Puede ser datetime, double, 4 short, 8 char, o 64 bits bit a bit.
Con los cuatros, 4 bytes de magia eran suficientes para codificar cualquier cosa, pero ahora tenemos 8. Todo lo que se necesita es la voluntad.