Histoire d'un tic-tac - page 8
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
OK, on va couper.
Dernier prix de la transaction tel que rapporté par la bourse ou la passerelle trade/date.
En général, je recommande de demander le mode COPY_TICKS_INFO, où l'offre et la demande inter viendront.
Hier, je n'ai pas fait attention, en utilisant le mode COPY_TICKS_INFO, les prix d'achat et de vente se rejoignent-ils ? Est-ce que c'est essentiellement le mode pour le forex ?
Maintenant, le comportement est le même qu'en mode COPY_TICKS_ALL (c'est-à-dire qu'il peut venir séparément bid (asc = 0), séparément asc (bid = 0)) après avoir demandé <5000 (environ) ticks et les deux prix si plus.
Le nombre de ticks renvoyés est également inférieur à celui demandé (mode COPY_TICKS_INFO, COPY_TICKS_ALL - autant que demandé - autant est renvoyé).
Je pense que quelque chose ne va pas...
Je n'ai pas fait attention hier, en utilisant le mode COPY_TICKS_INFO les prix d'achat et de vente se rejoignent-ils nécessairement ? C'est-à-dire qu'il s'agit essentiellement d'un mode pour le forex ?
Il est possible de ne pas couper :) et de faire une structure étendue séparée pour les CopyTicks.
Il n'y aura certainement pas de structure séparée.
Nous allons donc nous étendre avec un nouveau champ à la fin.
Coupez-la comme ça, s'il vous plaît :
Nous avons ces données.
Nous sommes toujours en train de réfléchir sérieusement à la question de savoir si nous avons le droit d'étendre la structure de MqlTick. Ceux qui fonctionnent avec la taille de cette structure peuvent en souffrir. En fait, pour le bien de l'avenir, nous pouvons faire une coupure nette et élargir la structure.
D'ici la sortie de vendredi prochain, nous prendrons une décision.
Ceux qui ont utilisé MqlTick auparavant, ont fait sizeof(MqlTick) et ceux qui ne l'ont pas fait trouveront cette situation une bonne leçon pour une programmation correcte.
En général :"coupez en deux".
Les informations sur les OI, le nombre actuel d'ordres d' achat et de vente, etc. sont spécifiques à la salle des marchés de FORTS, elles ne sont pas disponibles dans les autres salles (forex et bourses). Par conséquent, l'inclusion de ces informations dans l'interface unifiée de MqlTick semble douteuse. Et que dire des champs action et time_count, leur présence serait en effet utile.
La structure qui sera incluse ne fait aucune différence. Nous pourrions l'inclure dans une structure distincte, ce qui ne se produira probablement pas dans les prochaines années.
J'ai déjà commencé à me souvenir de l'ancien protocole DDE - je vais devoir utiliser QuickBooks pour obtenir ces informations à partir de là.
Sans le décompte exact du temps (jusqu'à ms), la nécessité des ticks est douteuse.
La structure incluse ne fait aucune différence. Il pourrait être dans une structure séparée - ce qui apparemment n'arrivera pas dans les prochaines années.
J'ai déjà commencé à me souvenir de l'ancien protocole DDE - je vais devoir obtenir ces informations de là à Quick.
Sans le décompte exact du temps (jusqu'à ms), la nécessité des ticks est douteuse.
En fait, cette information est disponible dans MT5 et diffusée depuis longtemps. Elle est disponible via les fonctions SymbolInfoGet*. Personne n'interdit de faire une demande de ces informations au moment de la réception d'une coche et de les combiner dans ses propres types de données.
Un autre problème est que le stockage centralisé des serveurs est toujours plus fiable que le vôtre. Vous n'avez pas à penser à stocker les devis - tout est très pratique. Mais encore une fois, il n'est pas irremplaçable d'un point de vue critique.
Sans un décompte précis du temps (jusqu'à msec), l'utilité des ticks est discutable.