Demande non valide - je viens de commencer et je n'arrive pas à comprendre... - page 8

[---]

papaklass:

Je l'ai implémenté de la même manière, mais par le biais de fonctions.

Je vois. Votre code est similaire à celui de MK - entre OrderCheck et OrderSend il y a une couche de gestion des erreurs par l'utilisateur.

[Renat Fatkhullin]

papaklass:

Je l'ai implémenté de cette façon, uniquement par le biais de fonctions.

OrderCheck est implicite et nécessairement vérifié dans OrderSend.

Ainsi, si la commande n'est pas remplie correctement, la réponse sera renvoyée immédiatement sans être renvoyée au serveur.

[Renat Fatkhullin]

papaklass:

Voyez ce que dit le manuel à ce sujet :

Première sélection : nous constatons que la fonction concerne les transactions commerciales et qu'il n'est pas question de chèques.

Eh bien, si je dis qu'il y a des contrôles, alors c'est vrai.

Aucune commande ne quitte le terminal sans contrôles rigoureux.

Deuxième mise en évidence : nous voyons que les contrôles sont effectués sur le serveur et les développeurs recommandent d'utiliser OrderCheck() pour vérifier la requête avant de l'envoyer au serveur. Encore une fois, il n'est pas mentionné que OrderSend() effectue une quelconque validation.

Nous recommandons spécifiquement aux traders d'avoir la possibilité de savoir à l'avance si l'ordre est correctement exécuté, et de prendre les mesures appropriées.

Celui qui le veut peut le pré-vérifier. Ceux qui ne veulent pas le faire, nous vérifierons et renverrons des réponses similaires pour eux de toute façon.

Le seul endroit où il est mentionné que la vérification avant l'envoi de la demande est "En cas de réussite de la vérification de base des structures (vérification des pointeurs) ....". Mais la vérification des pointeurs et la vérification des valeurs des champs de la structure de la demande pour les erreurs ne sont pas la même chose. Et la recommandation des développeurs d'utiliser la fonction OrderCheck() est une preuve indirecte que OrderSend() n'effectue pas de véritable vérification des erreurs avant d'envoyer une requête au serveur. Sinon, pourquoi devrions-nous faire "huilé" : OrderSend() vérifie d'abord, et ensuite le même contrôle doit être effectué par OrderCheck() à nouveau ?

Il ressort donc sans ambiguïté de la référence que la vérification est effectuée uniquement sur le serveur !

Personne ne manquera un flux erroné ou excessif de demandes au serveur.

La logique de base suffit pour comprendre cela. Et nous allons élargir la documentation.

[[Supprimé]]

sergeev:

Vous ne l'avez pas. Toutes les erreurs sont gérées par la logique métier.

J'en ai un. La logique commerciale gère les événements liés à la logique commerciale (par exemple, l'échec de la passation de commande), mais tout le reste (par exemple, le délai de réponse du serveur) - un modèle universel, sur la base duquel absolument n'importe quel expert peut être mis en œuvre.

Mais MT5 est beaucoup plus compliqué en termes de gestion des codes de retour + asynchronie.

C'est de cela qu'il s'agit, comme je l'ai déjà écrit de manière similaire, et il n'existe aucune information à ce sujet. Et pendant des années, les MK ont essayé par tous les moyens de se dissocier de sa fourniture. C'est ce que j'ai écrit - les concessionnaires bénéficient d'un produit où il y a des points qui entraînent des fuites, c'est-à-dire que pour MQ, c'est un facteur d'augmentation des ventes. Hélas, nous sommes dans un marché où les concurrents (nous et MQ), ne sont pas des camarades.

Vous demandez l'impossible à une enveloppe. La bibliothèque standard n'est pas une logique d'entreprise. Il s'agit d'une enveloppe "par-dessus" les fonctions du terminal. Un emballage qui recouvre la farce du bonbon.

Dans ce cas, une telle structuration n'a guère de sens.

Mais l'enveloppe ne peut rien garantir, car c'est vous qui vous portez garant. Votre logique d'entreprise. :)

Tout comme la fonction d'impression ne peut pas garantir l'espace libre sur le disque. et les erreurs de journalisation. Vous devez utiliser d'autres fonctions pour la gestion des erreurs et elles sont spécifiques à chaque cas.

Même le bon wrapper ne peut pas tout garantir, mais il peut beaucoup de choses relatives à des fonctions connexes.

-Alexey-, parlons de défauts spécifiques et vous exprimez des défauts spécifiques que vous aimeriez corriger.

Il a déjà été écrit plus d'une fois sur le sujet spécifique. Si MQ n'est pas en mesure de fournir une solution toute faite, qu'il rédige au moins un manuel sur le traitement des erreurs et les codes de retour. Déverrouillé de toutes les manières possibles. Dans la documentation de 4, cela était en partie présent (par exemple, attendre 30 secondes dans un tel cas), en partie les utilisateurs ont identifié par expérience le traitement des situations non documentées. Pour 5, il n'y a rien du tout. Et puisqu'il existe, personne ne l'utilisera.

Eh bien, si MQ réagit ainsi parce que l'infrastructure commerciale qui vient d'être créée ne le permet pas en principe, alors que puis-je dire - c'est un échec total de tout le projet MT5, étant donné qu'il y a une masse incroyable d'autres écueils également.

Si vous le souhaitez, vous pouvez passer en revue chaque code de retour et examiner les principales situations possibles.

Je le ferais volontiers avec un conseiller expert MQL5 aussi expérimenté que vous. Nous attendrons le temps et la nécessité. Dieu merci, j'ai encore le 4 qui est beaucoup plus confortable à bien des égards.

[---]

-Alexey-:

une solution toute faite, au moins un guide pour le traitement des erreurs et les codes de retour

quel code provoque des problèmes de traitement ?

Code	Identifiant	Description
10004	COMMERCE_RETCODE_REQUÊTE	Demander
10006	COMMERCE_RETCODE_REJET	Demande rejetée
10007	COMMERCE_RETCODE_ANNULATION	Demande annulée par l'opérateur
10008	COMMERCE_RETCODE_PLACÉ	Commande passée
10009	TRADE_RETCODE_DONE	Ordre exécuté
10010	COMMERCE_RETCODE_DONE_PARTIAL	Réquisition partiellement exécutée
10011	ERREUR_RETCODE_COMMERCIAL	Erreur de traitement de la demande
10012	DÉLAI D'ATTENTE POUR LE CODE DE RETOUR	Demande annulée en raison de l'expiration du délai
10013	TRADE_RETCODE_INVALID	Demande incorrecte
10014	TRADE_RETCODE_INVALID_VOLUME	Volume incorrect dans la demande
10015	PRIX_RETCODE_INVALIDE DU COMMERCE	Prix incorrect dans la demande
10016	TRADE_RETCODE_INVALID_STOPS	Arrêts incorrects dans la demande
10017	COMMERCE_RETCODE_TRADE_DÉSACTIVÉ	Commerce interdit
10018	COMMERCE_RETCODE_MARCHÉ_FERMÉ	Le marché est fermé
10019	COMMERCE_RETCODE_NO_MONEY	Fonds insuffisants pour l'exécution de la demande
10020	COMMERCE_RETCODE_PRIX_CHANGÉ	Les prix ont changé
10021	RABAIS SUR LE PRIX DU CODE DU COMMERCE	Pas de devis pour traiter la demande
10022	TRADE_RETCODE_INVALID_EXPIRATION	Date d'expiration non valide dans la demande
10023	TRADE_RETCODE_ORDER_CHANGED	Le statut de la commande a été modifié
10024	COMMERCE_RETCODE_TROP_DE_DEMANDES	Des demandes trop fréquentes
10025	TRADE_RETCODE_NO_CHANGES	Pas de changement dans la demande
10026	TRADE_RETCODE_SERVER_DISABLES_AT	Auto-trading refusé par le serveur
10027	TRADE_RETCODE_CLIENT_DISABLE_AT	Autotrading interdit par le terminal du client
10028	TRADE_RETCODE_LOCKED	Demande bloquée pour traitement
10029	TRADE_RETCODE_FROZEN	Ordre ou position gelée
10030	TRADE_RETCODE_INVALID_FILL	Le type d'exécution de l'ordre de solde n'est pas supporté.
10031	CONNEXION_RETCODE_COMMERCIAL	Pas de connexion au serveur commercial
10032	COMMERCE_RETCODE_SEULEMENT_RÉEL	L'opération n'est autorisée que pour les comptes réels
10033	COMMANDES_RETCODES_LIMITES_COMMERCIALES	Limite du nombre d'ordres en attente atteint
10034	VOLUME_LIMITE_RETCODE_COMMERCIAL ATTEINT	Limite sur le nombre d'ordres et de positions pour ce symbole atteinte.

Mise à jour : 2012.11.14

[[Supprimé]]

Par exemple 10004. Où est-il écrit ce qu'il faut faire ? Et il y avait au moins quelque chose dans la documentation quadruple :

Можно без задержки обновить данные при помощи функции RefreshRates и повторить попытку. Если ошибка не исчезает, необходимо прекратить все попытки торговых операций и изменить логику программы.

[A100]

sergeev:

quel code soulève des problèmes de traitement ?

10006 (quelle est la raison du rejet, quelles autres raisons pourraient exister qui ne sont pas répertoriées dans les autres codes ?)

10011, 10013, 10028

[[Supprimé]]

A100:

10006 (quelle raison est rejetée, quelles autres raisons pourraient exister qui ne sont pas mentionnées dans les autres codes ?)

10011, 10013, 10028

Je soutiens la question. MQ, une forte demande à vous. Veuillez commenter ces 4 codes de la manière la plus détaillée possible.

[combat.trader]

Des collègues, déjà fatigués de chercher la vérité. Le sujet est similaire à ce dont j'ai besoin, alors j'écris ici, s'il vous plaît aidez-nous !

Je place l'ordre avec exécution immédiate, pendant qu'il est suspendu je vérifie le prix chaque tick et si c'est possible je l'exécute. Mais pour une raison quelconque je reçois toujours l'erreur 10013. J'ai cherché dans tous les forums possibles et ajouté presque toutes les lignes de l'ordre initial (bien que la description indique que seuls le symbole, l'action et les sl et tp sont suffisants pour ce type d'action. Rien ne marche ! Voici le code.

// проверяем условие на открытую сделку
if (f_IsDealOpened()>0)
{  
   // здесь надо написать условия для коррекции ордеров
 MqlTradeRequest chrequest={0};
    if (1)//(is_Str2)
   {
    PositionSelect(NULL);
    if(PositionGetInteger(POSITION_TYPE)==0)
    {
        chrequest.symbol=PositionGetSymbol(0);
        chrequest.order=PositionGetInteger(POSITION_IDENTIFIER);
        chrequest.volume=PositionGetDouble(POSITION_VOLUME);
        chrequest.action=TRADE_ACTION_SLTP;
        chrequest.sl = latest_price.bid - TrailingStop;
        chrequest.tp = PositionGetDouble(POSITION_TP);

     }
     else
     {
        chrequest.symbol=PositionGetSymbol(0);
        chrequest.order=PositionGetInteger(POSITION_IDENTIFIER);
        chrequest.volume=PositionGetDouble(POSITION_VOLUME);
        chrequest.action=TRADE_ACTION_SLTP;
        chrequest.sl = latest_price.ask + TrailingStop;
        chrequest.tp = PositionGetDouble(POSITION_TP);
        Alert(PositionSelect(NULL));
     
     }    
    }
     MqlTradeResult chresult;
     if (OrderSend(chrequest,chresult)==0) 
         {
             Alert("Ошибка расчета функции OrderSend!");
             return;
         }    
         // анализируем код возврата торгового сервера
         if(mresult.retcode==10009 || mresult.retcode==10008) //запрос выполнен или ордер успешно помещен
           {
            Alert("Ордер по изменению SL успешно помещен, тикет ордера #: ",mresult.order,"!!");
            open_order_ticket = mresult.order;
            open_order_price = mresult.price;
            return;
           }
         else
           {
            Alert("Запрос на измнение ордера не выполнен - код ошибки: ",GetLastError());
            return;
           }
   
   
   return;
}