Aprender y escribir juntos en MQL5 - página 18

Nuevo comentario
 
Yedelkin:

Bueno, ya lo has entendido. Te lo digo meticulosamente, puedes comprobarlo: la función OrderSend() devuelve un valor booleano. En este caso, si la solicitud se comprueba con éxito, el ticket del pedido se escribe en la variable de la estructura MqlResult. Yo lo llamo "retorno de la función del ticket de pedido" para mí. Aquí está el enlace a la fuente:"Cuando se envía una solicitud de compra mediante la función OrderSend(), se puede averiguar inmediatamente el ticket de la orden que se ha creado si la solicitud se comprueba con éxito.

Y si vas a desviarte del tema por iniciativa del moderador, tienes una respuesta similar: no hay ni habrá nunca un tutorial de MQL5, así que no está claro, qué tutorial estás buscando. ... Tal vez, podemos discutir el fondo de la discusión, o nada en absoluto? :)

Gracias por la respuesta sobre la "prohibición", lo tengo.

No se entiende del todo bien lo que ocurrirá al recibir una respuesta del servidor.

OrderSend() realmente devuelve un valor booleano, pero no es lo más importante - lo principal es la estructura, que se rellena al recibir una respuesta del servidor.

Sí, escribimos una entrada en la estructura (no sólo los pedidos, sino también las operaciones), pero ¿es más importante que el resto de la información de la estructura?

Analicemos la estructura de la respuesta. En mi opinión, el panorama es aproximadamente el siguiente

struct MqlTradeResult
{
//Очень важная информация
uint     retcode;          // Код результата операции
//Важная информация (важна при успешном запросе)
ulong    deal;          // Тикет сделки, если она совершена
ulong    order;         // Тикет ордера, если он выставлен
//Малосущественная информация (важна при успешном запросе, а также в случае реквоты)
double   volume;        // Объем сделки, подтверждённый брокером
double   price;         // Цена в сделке, подтверждённая брокером
//Малосущественная информация (важна при реквоте)
double   bid;           // Текущая рыночная цена предложения (цены реквота)
double   ask;           // Текущая рыночная цена спроса (цены реквота)
//Не существенная информация
string   comment;       // Комментарий брокера к операции (по умолчанию заполняется расшифровкой)
};

PS

El nombre correcto para una estructura es MqlTradeResult y no MqlResult (aunque no importa mucho en mi opinión).

Si la solicitud es correcta y se ejecuta, entonces el volumen y el precio son importantes en caso de que el servidor "tuviera derecho" a reducir los parámetros de datos de la transacción y puede requerir una reacción del Asesor Experto sobre las acciones del servidor.

 
sergeev:

Por desgracia, sigo sin entenderlo.

por alguna razón necesita tener un campo "tiempo" en la estructura de retorno. utilice el tiempo en el orden que aparece. Esto es suficiente para controlar una pequeña historia.

"Cuando se envía una solicitud de compra mediante la función OrderSend(), se puede conocer inmediatamente el ticket de la orden que se creó cuando la solicitud se verificó con éxito. Pero al mismo tiempo, la orden en sí puede no aparecer todavía en el terminal del cliente y un intento de seleccionarla usando la función OrderSelect fallará. De la segunda frase se deduce que no siempre es posible trabajar con las propiedades de la orden (tiempo de la orden), aunque se conozca su entrada. Por lo tanto, "utilizar el tiempo en el orden que ha aparecido" no es una solución ideal. Además, la orden puede "no abrirse" en absoluto. Mi planteamiento resolvería el "problema del control de la historia pequeña" independientemente de lo que ocurriera con la orden antes de que pasara a la historia.
 
Interesting:

La estructura debería llamarse MqlTradeResult , no MqlResult (aunque realmente no importa en mi opinión).

He escrito "de memoria", en respuesta al consejo de estudiar un libro de texto
Interesante:

No es exactamente una comprensión correcta de lo que sucede cuando se recibe una respuesta del servidor.

OrderSend() devuelve efectivamente un valor booleano, pero no es lo más importante. Lo principal es la estructura que se rellena al recibir una respuesta del servidor.

Sí, efectivamente, se escribe un ticket en la estructura (no sólo órdenes, sino también tratos), pero ¿es más importante que el resto de la información de la estructura?

Bueno, no discutamos quién lo entiende mejor :) Véase mi respuesta a Sergeev. Y aquí repito: según la lógica de la estrategia sólo necesito el ticket y la hora de aceptación del pedido de producción. Lo que ha subrayado no es ninguna de las dos cosas. "Información muy importante", como el retcode, no ayuda en absoluto a optimizar la carga del historial, que es a lo que me refiero en general.
 
Yedelkin:
"Al enviar una solicitud de compra mediante la función OrderSend(), podemos conocer inmediatamente el ticket de la orden que se ha creado cuando la solicitud se ha comprobado con éxito. Pero al mismo tiempo, la orden en sí puede no aparecer todavía en el terminal del cliente y un intento de seleccionarla usando la función OrderSelect fallará. De la segunda frase se deduce que no siempre es posible trabajar con las propiedades de la orden (tiempo de la orden), aunque se conozca su entrada. Por lo tanto, "utilizar el tiempo en el orden que ha aparecido" no es una solución ideal. Además, el pedido podría "no abrirse" en absoluto. Mi planteamiento resolvería el problema de controlar un pequeño historial independientemente de lo que ocurriera con la orden antes de entrar en el historial.

No sé, si es tan importante pedir a los desarrolladores para hacer adiciones a la estructura MqlTradeResult (en forma de tiempo para el que se ejecuta un comercio o una orden se establece).

Aunque no entiendo por qué es necesario, prefiero añadir parámetros a OnTrade().


 
Interesting:

No sé, si es tan importante, pedir a los desarrolladores para hacer adiciones en la estructura MqlTradeResult(como el tiempo de acuerdo ejecutado o la orden colocada).

Bueno, eso es lo que preguntaba desde el principio :) ¿Había un precedente, por así decirlo? :)

Además, si alguien hiciera esta pregunta hace medio año, podríamos esperar una aparición relativamente rápida de esta función, mientras esperamos al año siguiente - es más fácil introducir una variable para la fecha. Aunque no será completamente precisa, pero aún así.

Interesante:

Aunque no entiendo por qué es necesario, prefiero añadir parámetros a OnTrade().

Personalmente no puedo esperar más a que aparezca la estructura/parámetros de Comercio. Llevo ya 9 meses esperándolo. Tendré que conformarme con lo que tengo.

 
Yedelkin:
Escribí "de memoria", en respuesta al consejo de estudiar un libro de texto Bueno, no discutamos, quién tiene una mejor comprensión :) Mira mi respuesta a Sergeev. Y aquí repito: según la lógica de la estrategia sólo necesito un ticket y el tiempo de llevar el pedido a producción. Lo que ha subrayado no es ninguna de las dos cosas. "Información muy importante" como el retcode no ayuda para nada a optimizar la carga del historial, que es a lo que me refiero en general.

1. OrderSend() y la carga del historial, y a partir de aquí, por favor, explíquese (no entiendo de qué estamos hablando, y creo que nos quedamos sin hierba).

2. Lógicamente, si el análisis se basa únicamente en el resultado de OrderSend(), la secuencia de acciones es la siguiente

a) Revisa el retcódigo, necesitamos saber qué pasó realmente;

b) Si el resultado es satisfactorio, obtener el ticket, el volumen y el precio. Si se trata de una recotización, obtenemos los nuevos precios (y comprobamos si nos satisfacen).

c) Si la respuesta es satisfactoria y no tenemos errores, obtener un billete y la hora. Puedes utilizar la hora del servidor o intentar sacarla del historial (para el cálculo aproximado de momento, es mejor conocer la hora del servidor);

d) Si no estamos satisfechos con la respuesta (o lo estamos sólo parcialmente) - no coincidimos con el volumen o tenemos una recotización, decidimos los siguientes pasos.

PS

En definitiva, se mire como se mire, el retconeo hay que mirarlo.

 
Interesting:

No sé de qué hablas, y creo que nos quedamos sin hierba).

Mira la discusión desde el principio. ...Nadie niega la importancia del retconeo, pero para soluciones sencillas se puede prescindir de él.
 
Yedelkin:
Mira la discusión desde el principio. ...Nadie niega la importancia del retconeo, pero para soluciones sencillas se puede prescindir de él.

¿Qué importancia tiene esta opción para usted?

c) Si la respuesta es satisfactoria y no hay errores, obtenemos un ticket. Puede utilizar la hora actual;

 
sergeev:

¿Qué importancia tiene esta opción para usted?


Se trata de la variante estándar (que tiene sus desventajas mencionadas anteriormente) + el ahorro de tiempo independiente. Dado que no necesito la comprobación de retcodes, sólo hay una cuestión de ahorro de tiempo: ya sea de forma independiente o estética con MqlTradeResult. En realidad, este es el motivo de la pregunta :)
 
Yedelkin:
Esta es la opción estándar (que tiene sus desventajas, mencionadas anteriormente) + el tiempo de autoguardado. Como no necesito la comprobación de retcodes, la única pregunta que queda es sobre el ahorro de tiempo: ya sea por sí mismo, o estéticamente con MqlTradeResult. En realidad, este es el motivo de mi pregunta :)

Si la solicitud tiene éxito, tarde o temprano la operación estará en el historial y la orden aparecerá en la lista. De este modo, podrá saber exactamente qué ha pasado y cómo ha sucedido.

Y la variante sugerida es, por así decirlo, "a corto plazo", para aquellos que quieren obtener todos los datos necesarios de una vez y no molestarse con acciones innecesarias.

Por supuesto, tal vez añadir algo más en el servidor de respuesta, pero hay una serie de características y razones por las que los desarrolladores pueden no estar de acuerdo con esta opción (y la solicitud, lo siento poco justificada y confirmada por argumentos convincentes).

PS

Aunque quizá me haya perdido algo y los desarrolladores hayan decidido que es bastante razonable.

1...111213141516171819202122232425...46
Nuevo comentario