Apprendre et écrire ensemble en MQL5 - page 18

Nouveau commentaire
 
Yedelkin:

Eh bien, vous comprenez. Je vous le dis méticuleusement, vous pouvez vérifier : la fonction OrderSend() renvoie une valeur booléenne. Dans ce cas, si la demande est vérifiée avec succès, le ticket de commande est écrit dans une variable de la structure MqlResult. Pour ma part, je l'appelle "retour de la fonction ticket de commande". Voici le lien vers la source :"Lorsque vous envoyez une demande d'achat à l'aide de la fonction OrderSend(), vous pouvez immédiatement connaître le ticket de l'ordre qui a été créé si la demande est vérifiée avec succès.

Et si vous vous écartez du sujet à l'initiative du modérateur, vous avez une réponse similaire : il n'y a pas et il n'y aura jamais de tutoriel MQL5, donc il n'est pas clair, quel tutoriel vous regardez. ... Peut-être, nous pouvons soit discuter du fond de la discussion, ou rien du tout ? :)

Merci pour la réponse concernant l'interdiction, j'ai compris.

Pas tout à fait une compréhension correcte de ce qui se passera lors de la réception d'une réponse du serveur.

OrderSend() renvoie réellement une valeur booléenne, mais ce n'est pas le plus important - l'essentiel est la structure, qui est remplie lors de la réception d'une réponse du serveur.

Oui, nous inscrivons un ticket dans la structure (pas seulement les commandes, mais aussi les transactions), mais est-il plus important que le reste des informations de la structure ?

Analysons la structure de la réponse. A mon avis, le tableau est approximativement le suivant

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

PS

Le nom correct pour une structure est MqlTradeResult et non MqlResult (bien que cela n'ait pas beaucoup d'importance à mon avis).

Si la requête est correcte et exécutée, alors le volume et le prix sont importants au cas où le serveur "avait le droit" de réduire les paramètres de données de la transaction et cela peut nécessiter une réaction de l'Expert Advisor sur les actions du serveur.

 
sergeev:

Malheureusement, je ne comprends toujours pas.

vous devez avoir un champ "heure" dans la structure de retour pour une raison quelconque. utilisez l'heure dans l'ordre où elle apparaît. C'est suffisant pour contrôler une petite histoire.

"Lorsque vous envoyez une demande d'achat à l'aide de la fonction OrderSend(), vous pouvez immédiatement connaître le ticket de l'ordre qui a été créé lorsque la demande a été vérifiée avec succès. Mais en même temps, l'ordre lui-même peut ne pas encore apparaître dans le terminal du client et une tentative de le sélectionner à l'aide de la fonction OrderSelect échouera. Il découle de la deuxième phrase qu'il n'est pas toujours possible de travailler avec les propriétés de la commande (temps de commande), même si son ticket est connu. Par conséquent, "utiliser le temps dans l'ordre où il est apparu" n'est pas une solution idéale. Il se peut également que la commande ne soit pas ouverte du tout. Mon approche résoudrait le "petit problème de contrôle de l'historique" indépendamment de ce qui est arrivé à l'ordre avant qu'il n'entre dans l'historique.
 
Interesting:

La structure devrait s'appeler MqlTradeResult , et non MqlResult (bien que cela n'ait pas vraiment d'importance à mon avis).

J'ai écrit "de mémoire", en réponse au conseil d'étudier un manuel.
Intéressant:

Ce n'est pas exactement une compréhension correcte de ce qui se passe lorsque vous recevez une réponse du serveur.

OrderSend() renvoie effectivement une valeur booléenne, mais ce n'est pas le plus important. L'essentiel est la structure qui est remplie par la réception d'une réponse du serveur.

Oui, en effet, un ticket est écrit dans la structure (pas seulement les commandes, mais aussi les transactions), mais est-il plus important que le reste des informations de la structure ?

Eh bien, ne nous disputons pas pour savoir qui a la meilleure compréhension :) Voir ma réponse à Sergeev. Et je le répète : selon la logique de la stratégie, je n'ai besoin que du ticket et du moment de l'acceptation de l'ordre de production. Ce que vous avez souligné n'est ni l'un ni l'autre. "Des informations très importantes", comme le retcode, n'aident pas du tout à optimiser le téléchargement de l'historique, ce dont je parle en général.
 
Yedelkin:
"Lorsque l'on envoie une demande d'achat à l'aide de la fonction OrderSend(), on peut immédiatement connaître le ticket de l'ordre qui a été créé lorsque la demande a été vérifiée avec succès. Mais en même temps, l'ordre lui-même peut ne pas encore apparaître dans le terminal du client et une tentative de le sélectionner à l'aide de la fonction OrderSelect échouera. Il découle de la deuxième phrase qu'il n'est pas toujours possible de travailler avec les propriétés de la commande (temps de commande), même si son ticket est connu. Par conséquent, "utiliser le temps dans l'ordre où il est apparu" n'est pas une solution idéale. Il se peut également que la commande ne soit pas ouverte du tout. Mon approche résoudrait le problème du contrôle d'un petit historique, indépendamment de ce qui est arrivé à l'ordre avant qu'il n'entre dans l'historique.

Je ne sais pas, si c'est si important, demandez aux développeurs de faire des ajouts à la structure de MqlTradeResult (sous la forme du temps pour lequel une transaction est exécutée ou un ordre est fixé).

Bien que je ne comprenne pas pourquoi c'est nécessaire, je préférerais ajouter des paramètres à OnTrade().


 
Interesting:

Je ne sais pas, si c'est si important, demandez aux développeurs de faire des ajouts dans la structure MqlTradeResult(comme l'heure de la transaction exécutée ou de l'ordre passé).

Eh bien, c'est ce que je demandais depuis le début :) Y avait-il un précédent, pour ainsi dire :)

Ajoutons que si quelqu'un posait cette question il y a six mois, nous pourrions espérer une apparition relativement rapide de cette fonctionnalité, en attendant l'année suivante - il est plus facile d'entrer une variable pour la date. Certes, ce ne sera pas tout à fait exact, mais quand même.

Intéressant:

Bien que je ne comprenne pas pourquoi c'est nécessaire, je préférerais ajouter des paramètres à OnTrade().

Personnellement, je ne peux pas attendre plus longtemps l'apparition de la structure/des paramètres du commerce. Je l'attends depuis 9 mois déjà. Je vais devoir faire avec ce que j'ai.

 
Yedelkin:
J'ai écrit "de mémoire", en réponse au conseil d'étudier un manuel. Ne nous disputons pas, qui a une meilleure compréhension :) Regardez ma réponse à Sergeev. Et je le répète : selon la logique de la stratégie, je n'ai besoin que d'un ticket et du temps d'acheminement de la commande à la production. Ce que vous avez souligné n'est ni l'un ni l'autre. Les "informations très importantes" telles que le retcode n'aident pas du tout à optimiser le téléchargement de l'historique, ce dont je parle en général.

1. OrderSend() et le téléchargement de l'historique, et à partir de là, veuillez élaborer (je ne sais pas de quoi il s'agit, et je pense que nous sommes hors de portée).

2. Logiquement, si l'analyse est basée uniquement sur le résultat de OrderSend(), la séquence d'actions est la suivante

a) Vérifiez le retcode, nous devons savoir ce qui s'est réellement passé ;

b) Si le résultat est positif, obtenir le ticket, le volume et le prix. En cas de requalification, nous obtenons les nouveaux prix (et vérifions s'ils nous satisfont).

c) Si la réponse est satisfaisante et que nous n'avons pas d'erreurs, obtenez un ticket et une heure. Vous pouvez utiliser l'heure du serveur ou essayer de la tirer de l'historique (pour un calcul approximatif à l'heure actuelle, il est préférable de connaître l'heure du serveur) ;

d) Si nous ne sommes pas satisfaits de la réponse (ou si nous ne sommes que partiellement satisfaits) - ne correspondent pas au volume ou nous avons une requote, décider des prochaines étapes.

PS

En bref, quelle que soit la façon dont vous le regardez, le retcode doit être regardé.

 
Interesting:

Je ne sais pas de quoi vous parlez, et je pense que nous n'avons plus d'herbe).

Regardez la discussion depuis le début. ...Personne ne nie l'importance du retcode, mais pour les solutions simples, vous pouvez vous en passer.
 
Yedelkin:
Regardez la discussion depuis le début. ...Personne ne nie l'importance du retcode, mais pour les solutions simples, vous pouvez vous en passer.

Dans quelle mesure cette option est-elle essentielle pour vous ?

c) Si la réponse est satisfaisante et qu'il n'y a pas d'erreurs, on obtient un ticket. Vous pouvez utiliser l'heure actuelle ;

 
sergeev:

Dans quelle mesure cette option est-elle essentielle pour vous ?


Il s'agit de la variante standard (qui a ses inconvénients mentionnés ci-dessus) + le gain de temps indépendant. Puisque je n'ai pas besoin de la vérification du retcode, il y a seulement une question sur le gain de temps : soit indépendamment, soit esthétiquement avec MqlTradeResult. En fait, c'est la raison de la question :)
 
Yedelkin:
Il s'agit de l'option standard (qui a ses inconvénients, mentionnés ci-dessus) + le temps d'auto-sauvetage. Puisque je n'ai pas besoin de vérifier le retcode, il n'y a qu'une question de gain de temps : soit indépendamment, soit esthétiquement avec MqlTradeResult. En fait, c'est la raison de ma question :)

Si la demande aboutit, tôt ou tard, la transaction sera dans l'historique et l'ordre apparaîtra dans la liste. Par conséquent, vous serez en mesure de savoir exactement ce qui s'est passé et comment cela s'est passé.

Et la variante proposée est pour ainsi dire "à court terme", pour ceux qui veulent obtenir toutes les données dont ils ont besoin et ne pas s'embêter avec des actions inutiles.

Bien sûr, peut-être ajouter quelque chose d'autre dans le serveur de réponse, mais il ya un certain nombre de fonctionnalités et de raisons pour lesquelles les développeurs peuvent ne pas être d'accord avec cette option (et la demande, désolé peu justifiée et confirmée par des arguments convaincants).

PS

Mais peut-être ai-je raté quelque chose et les développeurs ont-ils décidé que c'était tout à fait raisonnable.

1...111213141516171819202122232425...46
Nouveau commentaire