Mon approche. Le noyau est le moteur. - page 145
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 suppose que chaque flux vers et depuis le moteur doit avoir une sorte de trait de flux, une sorte de nombre magique, et un trait de flux qui fonctionne avec le testeur (il est invariablement unique). Le moteur réagit au flux et aux conseillers actuellement définis, les indicateurs réagissent à leur attribut (numéro pseudo-magique) du flux d'informations.
Tout fonctionne bien dans le testeur maintenant, je contrôle le conseiller expert dans le testeur à partir d'une autre fenêtre. Il est en mode simulateur.
Actuellement, les messages entre l'EA et le moteur ne sont pas liés à un certain mage ou nom de l'EA. Cela signifie que si le moteur écrit des informations dans une ressource, elles seront lues par tout conseiller expert qui a été configuré pour la communication. Afin de séparer les flux de communication, chaque EA doit définir une étiquette spéciale dans l'en-tête du message. Et ensuite, soit vous lisez et suivez les instructions, soit vous les ignorez. Il devrait y avoir une étiquette séparée pour les conseillers experts dans le testeur.
Mais nous voyons ici le besoin d'une interface graphique universelle pour le moteur à travers laquelle nous pouvons configurer et commuter les communications. Pour recevoir également des informations sur les conseillers experts.
Nous devons donc changer le concept des EA. Pour être plus précis, nous devons le mettre à niveau.
Voilà le hic.
Nous devons avoir soit une interface graphique personnalisée pour chaque EA, soit une interface graphique commune pour toutes les EA. Si elle est commune, alors elle devrait être invariante. Il faut que ce soit bien pensé à l'avance. Chaque Expert Advisor (même sans l'interface graphique), doit avoir des leviers internes qu'il fournira au moteur.
Quelque chose à penser...
Mais nous en arrivons à la nécessité d'une interface graphique universelle pour le moteur, par laquelle configurer et commuter la communication. Aussi, pour recevoir des informations sur les EA.
Il faut simplement qu'il y ait dans le moteur une partie administrative nécessaire et suffisante, conçue et configurée de façon permanente, qui s'occupe de l'administration du contrôle, et la partie personnalisée la plus variée, construite selon le projet du client.
Il suffit d'avoir dans le moteur une partie administrative nécessaire et suffisante, conçue et configurée de façon permanente, qui s'occupe de l'administration de la gestion et d'une grande variété de parties personnalisées, construites selon le projet du client.
Cette partie administrative n'est pas compréhensible. Qu'est-ce que c'est censé être ?
Si le moteur fonctionne avec un seul conseiller expert, c'est une chose. Et si cela fonctionne avec plusieurs autres, c'est autre chose.
Il manque encore un cadre conceptuel...
C'est la partie administrative qui n'est pas claire. Qu'est-ce que ça devrait être ?
Si le moteur fonctionne avec un seul EA, c'est une chose. S'il fonctionne avec plusieurs autres, c'en est un autre.
Jusqu'à présent, il y a un manque de cadre conceptuel...
Disons quelque chose comme ça.
Et dans le conseiller expert ou l'indicateur, dans les paramètres de départ, le même champ "Objet 1", etc.
Supposons quelque chose comme ça.
Et dans l'EA ou l'indicateur, dans les paramètres de départ, le même champ "Objet 1", etc.
Je me demande. Voulez-vous dire que nous devons changer la connexion avec ces boutons ? Mais, dans ce cas, tous les Expert Advisors doivent être des copies d'un EA fonctionnant sur différentes paires.
Et si les Expert Advisors sont différents ?
Disons quelque chose comme ça.
Et dans l'EA ou l'indicateur, dans les paramètres de départ, le même champ "Objet 1", etc.
Je vais d'abord le mettre en œuvre. Avec un seul EA sur différentes paires. Et ensuite, je découvrirai comment gérer les différentes EA.
Au fait, voici une bonne démonstration de l'utilisation du constructeur. Dynamique, sans paroles, et en musique. :)
CRÉATION D'UN STUDIO VISUEL
https://www.mql5.com/ru/blogs/post/712102
Au fait, voici une bonne démonstration de l'utilisation du constructeur. Dynamique, sans paroles, et en musique. :)
STUDIO VISUEL
Original.
Disons quelque chose comme ça.
Et dans l'EA ou l'indicateur, dans les paramètres de départ, le même champ "Objet 1", etc.
Ceux-ci sont marqués comme étant connectés à la commande. Et il n'y a qu'un seul objet qui est contrôlé. Il y a donc un interrupteur à bascule quelque part avec une grande indication.
Ceux-ci sont marqués comme étant connectés à la commande. Mais il y a un contrôle qui est spécifiquement contrôlé. Il y a donc un interrupteur à bascule quelque part avec une grande indication.
Chaque EA possède sa propre copie du noyau de paramètres. Il peut être temporairement déconnecté de l'interface graphique commune et connecté au moteur par un autre EA. Il est important qu'il s'agisse de copies de la même EE.
Cependant, il y a ici quelques difficultés que je ne comprends pas encore complètement.
En théorie, la question ressemble à ceci :
Pourquoi avons-nous besoin d'ajouter un moteur avec une interface graphique pour chaque graphique d'une copie de l'EA si nous pouvons faire un moteur avec l'interface graphique commune et le connecter à toutes les copies de l'EA ?
En pratique, nous rencontrerons quelques difficultés techniques.
La copie du conseiller expert peut écrire de nouvelles valeurs dans sa copie du noyau de paramètres. Si l'une des copies n'est pas connectée au moteur, le noyau ne changera que du côté de la copie. Ainsi, lors de la reconnexion, nous devons passer le noyau entier au moteur et le moteur redessinera tous les éléments dans toutes les fenêtres où cela est nécessaire. Cela est possible en principe.
Ou refaire le noyau des paramètres lui-même en en faisant une ressource. Dans ce cas, le moteur recevra tous les changements en même temps et redessinera simplement les éléments. Ce n'est pas une mauvaise idée.
Mais, qu'est-ce que ça nous apporte ?
Nous pouvons peut-être réduire la charge du processeur et libérer des fils. Si nous avons 10 copies d'EA fonctionnant sur 10 paires et que nous chargeons chaque moteur avec une interface graphique, la charge totale du CPU peut être trop importante. En effet, chaque interface graphique nécessite de redessiner les éléments, ce qui représente une charge importante pour le processeur. Mais en fait, nous ne pouvons voir qu'une seule interface graphique concrète d'une copie. Les autres sont cachés.
Donc c'est probablement la bonne façon de faire. Faire un moteur commun.