Questions OrderSend() - page 6
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Je me creuse la tête... l'arrêt ne se met pas en place... et beaucoup d'erreurs. voici ce qu'il reste de l'expérience, et ça ne marche plus.
Si vous faites cela, il n'y a pas d'erreur, mais le stop-loss n'est toujours pas défini.
Apparemment, je n'ai pas expliqué très clairement le problème précédent. Laissez-moi essayer à nouveau.
Au cours de l'année dernière, la description de la liste de valeurs de l'énumérationENUM_ORDER_TYPE_FILLING a été modifiée au moins trois fois. La description précédente se présentait comme suit
ENUM_ORDER_TYPE_FILLING
Identifiant
Description
COMMANDE_REMPLISSAGE_FOK
Une transaction ne peut être exécutée que dans le volume spécifié et à un prix égal ou supérieur à celui spécifié dans l'ordre. S'il n'y a pas assez d'offre sur le marché à ce moment-là pour le symbole de l'ordre, l'ordre ne sera pas exécuté. Ce type de remplissage est utilisé dans le mode d'exécution SYMBOL_TRADE_EXECUTION_INSTANT ouSYMBOL_TRADE_EXECUTION_REQUEST.
COMMANDE_REMPLISSAGE_IOC
Un accord pour exécuter une transaction au volume maximum disponible sur le marché dans le volume spécifié dans l'ordre et à un prix égal ou supérieur à celui spécifié dans l'ordre. Dans ce cas, aucune commande supplémentaire ne sera passée pour le volume manquant. Ce type de remplissage peut être disponible uniquement dans les modes d'exécution SYMBOL_TRADE_EXECUTION_MARKET etSYMBOL_TRADE_EXECUTION_EXCHANGE selon les paramètres du serveur de négociation.
RETOUR_REMPLISSAGE_ORDRE
Accord pour effectuer une transaction au volume maximum disponible sur le marché dans le volume spécifié dans l'ordre et à un prix égal ou supérieur à celui spécifié dans l'ordre. Dans ce cas, une commande supplémentaire sera passée pour le volume manquant au prix spécifié dans cette commande. Ce type de remplissage est utilisé uniquement pour les ordres en attente (TRADE_ACTION_PENDING).
Comme nous pouvons facilement le constater, il existe une correspondance biunivoque entre ORDER_FILLING_RETURN et les ordres en attente, à savoir : ORDER_FILLING_RETURN ne pouvait être appliqué qu'aux ordres en attente et le champ type_filling de tous les ordres en attente ne pouvait être rempli qu'avec la valeur de ORDER_FILLING_RETURN.
Pour les ordres de marché(action==TRADE_ACTION_DEAL), le champ type_filling aurait dû être rempli en fonction des modes d'exécution définis côté serveur.
Nous avions donc un certain paradigme : s'il y avait un ordre en attente,ORDER_FILLING_RETURN ; s'il y avait un ordre au marché, ORDER_FILLING_FOK ou ORDER_FILLING_IOC (selon le mode).
Maintenant, nous avons un peu chamboulé les choses, à savoir :
ENUM_ORDER_TYPE_FILLING
Identifiant
Description
COMMANDE_REMPLISSAGE_FOK
Cette politique d'exécution des ordres signifie que l'ordre ne peut être exécuté qu'à hauteur du volume spécifié. S'il n'y a pas assez de volume de l'instrument financier sur le marché à ce moment-là, l'ordre ne sera pas exécuté. Le volume requis peut être compilé à partir de plusieurs offres actuellement disponibles sur le marché.
COMMANDE_REMPLISSAGE_IOC
Indique l'accord pour exécuter une transaction au volume maximum disponible sur le marché dans le cadre du volume spécifié dans l'ordre. Si l'exécution complète n'est pas possible, l'ordre sera exécuté à hauteur du volume disponible, et le volume non exécuté sera annulé.
RETOUR_REMPLISSAGE_ORDRE
Ce mode est uniquement utilisé pour les commandes ORDER_TYPE_BUY_LIMIT et ORDER_TYPE_SELL_LIMIT. En cas d'exécution partielle, l'ordre limité avec le volume restant n'est pas supprimé mais reste en vigueur.
Pour les ordres ORDER_TYPE_BUY_STOP_LIMIT et ORDER_TYPE_SELL_STOP_LIMIT, l'ordre à cours limité ORDER_TYPE_BUY_LIMIT/ORDER_TYPE_SELL_LIMIT correspondant avec le type d'exécution ORDER_FILLING_RETURN sera créé lors de l'activation.
La restriction d'utiliser ORDER_FILLING_FOK et ORDER_FILLING_IOC uniquement avec les ordres au marché est supprimée. Il n'y a pas non plus de restriction sur l'utilisation de ORDER_FILLING_FOK et ORDER_FILLING_IOC avec les ordres au marché selon le mode d'exécution défini sur le serveur. Il existe une restriction concernant l'utilisation de ORDER_FILLING_RETURN uniquement avec les ordres à cours limité et stop_limit .
Ma question est donc la suivante : est-il acceptable d'utiliser ORDER_FILLING_FOK et ORDER_FILLING_IOC pour tous les ordres (au marché et en attente), y compris les ordres à cours limité et stop_limit ? Quelqu'un a-t-il compris les changements ?
Oui, c'est un peu flou sur cette question.
S'il y a une correspondance complète entre ENUM_SYMBOL_TRADE_EXECUTION et ENUM_ORDER_TYPE_FILLING , le second est évidemment inutile.
Il n'y a donc pas de moralité, et très probablement différentes valeurs deENUM_ORDER_TYPE_FILLINGsont acceptables avec une seule et mêmevaleur de ENUM_SYMBOL_TRADE_EXECUTION . MQ décrirait ici un tableau des possibilités, mais il est fort probable que ces données dépendent des paramètres du serveur de négociation.
D'où la deuxième morale, ce qui est nécessaire après tout :
ilfaut une fonction qui renvoie une liste d'options valables (ENUM_ORDER_TYPE_FILLING), pour le type d'ordre demandé (immédiat ou en attente).
Il n'y a pas beaucoup d'options ici, donc vous pouvez insérer un int via "|".
Si je me trompe, donnez-moi un pendule magique, où chercher cette question.
Pour résoudre cette question, je suis allé voir la bibliothèque standard (par habitude, si ce n'est pas clair pour voir comment les autres font).
La fonction pour un héritage pratique y a été donnée, alors que dans la classe CTrade SetTypeFilling() n'est pas utilisée, le champ type_filling est initialisé par défaut à zéro ce qui correspond à ORDER_FILLING_FOK selon l'énumération.
C'est tout, plus de travail. Et j'ai pensé que puisque ce champ n'est pas présent dans l'interface, cela signifie que le remplissage est automatisé dans la classe.
SZY en général, en attendant une réponse, comment le réparer :)Pour l'instant, je ne vois qu'une seule solution : taper sur le serveur jusqu'à ce que vous obteniez la réponse que vous voulez.
Une bonne soirée de divertissement, qui m'a fait rire à gorge déployée.
Les Chinois ont piraté le serveur principal du Pentagone.
Chaque Chinois a essayé une fois de taper le mot de passe.
Toutes les autres personnes ont tapé "Mao Tse Tung".
Après 5*10^7 essais, le serveur dit que le mot de passe est "Mao Tse Tung".
Pour l'instant, je ne vois qu'une seule solution : taper sur le serveur jusqu'à ce que vous obteniez la bonne réponse.
une sortie stupide.
Vous devriez d'abord vous adresser à votre DC pour savoir quels types d'exécution ils prennent en charge et quels types de listes de métaquotes correspondent à ces types d'exécution.
parce que ce n'est pas parce que metaquotes a inventé - 3 types de remplissage et 3 types de temps - qu'ils reflètent la réalité du remplissage des ordres sur un vrai courtier.
une sortie stupide.
Vous devez d'abord vous adresser à votre DC pour savoir quels types d'exécution il prend en charge et quels types de listes de méta-cotes correspondent à ces types d'exécution.
parce que ce n'est pas parce que metaquotes a trouvé - 3 types de remplissage et 3 types de temps - qu'ils sont le reflet de la réalité lors du remplissage des ordres sur un vrai courtier.
C'est ce que je dis, tout dépend des paramètres du serveur,
Mais frapper à toutes les sociétés de courtage est aussi un problème,
Par exemple, dans une société de courtage, vous pouvez recevoir un ordre pour un courtage réel,
mais tout contourner et écrire des interrupteurs dans votre code est exagéré.
Si vous estimez que vous vous êtes déjà inscrit chez nous, vous pouvez commencer à zéro avec un vrai courtier ou vous pouvez les ouvrir à partir de zéro,
PS vous êtes d'accord pour dire que le code normal est écrit de manière unifiée, pour toute transaction, des exceptions sont possibles mais dans un premier temps les exceptions confirment les règles, et dans un second temps s'il y a des exceptions vous devez écrire les exceptions.
Ici, une telle tautologie s'avère.
C'est ce que je veux dire, tout dépend des paramètres du serveur,
Mais il serait problématique de frapper à chaque société de courtage,
Si vous ne connaissez pas la différence entre les deux, vous pouvez penser que la commande sera copiée sur la bonne,
mais tout contourner et écrire des interrupteurs dans votre code est exagéré.
PS : vous devriez convenir que le code normal est écrit d'une manière unifiée, pour tout type de transaction,
PS vous êtes d'accord pour dire que le code normal est écrit de manière unifiée, pour toute transaction, des exceptions sont possibles mais premièrement les exceptions ne font que confirmer les règles, et deuxièmement s'il y a des exceptions vous devez écrire les exceptions. Ici, une telle tautologie s'avère.
voilà le truc.
les méta-citations sont confuses avec les types d'exécution et les temps d'exécution. elles sont non standard dans le sens où, en réalité, les ordres IOC et FOK sont liés aux temps d'exécution.
Le type d'exécution de l'ordre portait auparavant le nom adéquat de AON. mais il a ensuite été supprimé.
Regardez la spécification FIX que le FC utilise et exécute les ordres.
J'ai marqué les types qui ont pris des méta quotas à eux-mêmes. Mais comme vous pouvez le voir ils sont tous dans un groupe de la balise TimeInForce <59>.
Et maintenant, dites-moi comment le courtier qui place les offres sur le marché va traiter le type de put IOC et le temps GTD dans l'ordre MT. Parce qu'il s'agit d'un seul champ, et non de deux champs différents.
Par conséquent, chaque courtier réfléchira lui-même à ce qu'il convient de faire du remplissage, au type d'ordre à utiliser et à la manière de retirer l'ordre.
Le seul élément salvateur est la différence entre l'ordre au marché et l'ordre en suspens, c'est-à-dire que certains types d'exécution d'ordres ne sont utilisés que pour les ordres en suspens et d'autres pour les ordres au marché. En règle générale, nous devrions examiner ce point et en discuter.
Le nom All-Or-Nothing se trouve dans une autre balise, ExecInst <18>, qui n'est en aucun cas transmise à MetaTrader. Il est implicitement supposé (probablement) pour le type FOK
...
Alex reprend ce sujet, s'il te plaît. Je suis malheureusement un flotteur sur ces questions.
Faites des suggestions au SD, parlez-leur.
Nous devons mettre le sujet dans un certain ordre.
Ce que nous avons maintenant n'est pas du tout utilisable pour la programmation professionnelle.
Alex, reprends ce sujet s'il te plaît. Je suis malheureusement un peu un nageur sur ces questions.
Faites des suggestions au directeur de l'établissement, parlez-lui.
Nous devons mettre de l'ordre dans le sujet.
Je ne suis pas sûr que ce dont nous disposons actuellement soit adapté à la programmation professionnelle.
Ha. Soit je suis stupide, soit mes skis ne bougent pas.
Vous voyez vous-même que chaque mois, methaquotes établit une connexion avec une nouvelle bourse ou un nouveau marché.
J'en conclus que dans cet état de fait, leurs programmeurs accostent MT et FIX sans problème (ou avec une certaine tension avec la limitation de l'un d'eux).
Ils peuvent donc combiner les types de temps FOK et GTC, ce qui signifie qu'il est peu probable qu'ils changent quoi que ce soit dans un avenir proche, puisque les travaux sont en cours.
En même temps (je comprends), que pour l'échange, le pont de MT ne peut définir que deux types - AON ou partiel. Et inventé dans le retour MT - va probablement au partiel.
En général, les questions de l'interaction FIX courtier et MT serveur se trouvent dans le plan de compétence et de compréhension progeries au courtier, qui font des ponts de MT à leurs fournisseurs. Et je ne pense pas que metaquotes va changer quoi que ce soit, parce qu'ils ont longtemps et activement promouvoir la plate-forme aux marchés, et donc la structure interne du serveur MT tout à fait compatible avec les réalités.