Mon approche. Le noyau est le moteur. - page 77
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
Cette fonction peut être utilisée pour ajuster automatiquement la taille des éléments de texte.
Au niveau du constructeur (le générateur d'interface graphique qui analyse le code de balisage), voici comment cela fonctionne. Il calcule tout correctement. Si une police est définie dans la langue, la position du texte sera définie correctement.
Dans le code de balisage, la police par défaut a été définie comme"Microsoft JhengHei Light" et les positions des textes dans les éléments ont été calculées. Un noyau numérique a ensuite été généré et chargé dans le moteur en tant que coordonnées correctes pour la police installée.
Si l'ordinateur de l'utilisateur ne possède pas la police pour laquelle les calculs ont été effectués et qu'une autre police est installée, les valeurs des coordonnées du texte calculées dans le noyau ne sont pas correctes. Parce qu'ils ont été conçus pour une police différente.
Par conséquent, le texte n'est pas positionné correctement. Vous devez définir la bonne police de caractères et tout ira bien.
Vasily, pourquoi écrire des bêtises ?
Est-ce que c'est juste un troll ?
Il y a déjà un espace dans le nom du fichier.
Fill permet de prescrire les appels de vos fonctions sur l'événement checkbox.
Vous devez mettre l'EA sur la carte, puis le moteur.
Les fichiers doivent être enregistrés exactement dans le dossier Incloud.
Vous n'avez pas besoin de mettre quoi que ce soit n'importe où. Ce n'est pas un tour.
Vasily l'a écrit correctement.
Tout a été correctement écrit par Vassily.
Le malentendu a déjà été dissipé.
Au niveau du constructeur (le générateur d'interface graphique qui analyse le code de balisage), voici comment cela fonctionne. Il calcule tout correctement. Si une police est définie dans la langue, la position du texte est définie correctement.
Dans le code de balisage, la police par défaut a été définie comme"Microsoft JhengHei Light" et les positions des textes dans les éléments ont été calculées. Un noyau numérique a ensuite été généré et chargé dans le moteur en tant que coordonnées correctes pour la police installée.
Si l'ordinateur de l'utilisateur ne possède pas la police pour laquelle les calculs ont été effectués et qu'une autre police est installée, les valeurs des coordonnées du texte calculées dans le noyau ne sont pas correctes. Parce qu'ils ont été conçus pour une police différente.
Par conséquent, le texte n'est pas positionné correctement. Vous devez définir la bonne police de caractères et tout ira bien.
Je vois.
Peut-être... Mais ça aurait été différent.
Peut-être... Mais il y en aurait d'autres.
Le principal (peut-être le seul) avantage de l'utilisation d'un moteur d'indicateur distinct pour la mise en œuvre de l'interface de l'EA est que l'indicateur s'exécute dans un thread différent de celui de l'EA et, comme l'interface est une tâche assez gourmande en ressources, l'interface mise en œuvre de cette manière ne ralentira généralement pas le travail de l'EA elle-même, ce qui est une bonne chose.
Mais je n'ai pas une connaissance suffisante et une compréhension complète du mécanisme, de la manière dont les ressources du processeur et du co-processeur sont allouées entre les threads, et le concept de thread lui-même n'est pas tout à fait clair pour moi.
Quelqu'un dans le domaine peut-il clarifier ces points ?
Est-il raisonnable d'utiliser l'approche de Peter pour un fonctionnement plus efficace de l'Expert Advisor en raison de la réduction de la charge sur le thread de l'EA ?
Organisation de l'échange entre le thread de l'EA et le thread de l'interface de l'indicateur à travers le système d'interruptions personnalisées, comment cela affecte-t-il la charge du thread de l'EA ?
Retag, débarrassez-vous dès que possible des fichiers présentant des problèmes de dénomination, ce n'est pas une chose comique à faire, surtout ceux distribués publiquement. Les espaces sont une source de tracas dans les scripts shell.
Le principal (peut-être le seul) avantage de l'utilisation d'un moteur d'indicateur distinct pour la mise en œuvre de l'interface de l'EA est que l'indicateur s'exécute dans un thread différent de l'EA, et comme l'interface est une tâche assez gourmande en ressources, l'interface mise en œuvre de cette manière ne ralentira pas le fonctionnement de l'EA lui-même, ce qui est une bonne chose.
Mais je n'ai pas une connaissance suffisante et une compréhension complète du mécanisme, de la manière dont les ressources du processeur et du co-processeur sont allouées entre les threads, et le concept de thread lui-même n'est pas tout à fait clair pour moi.
Quelqu'un dans le domaine peut-il clarifier ces points ?
Est-il raisonnable d'utiliser l'approche de Peter pour un fonctionnement plus efficace de l'Expert Advisor en raison de la réduction de la charge sur le thread de l'EA ?
Organisation de l'échange entre le thread de l'EA et le thread de l'interface de l'indicateur à travers le système d'interruptions personnalisées, comment cela affecte-t-il la charge du thread de l'EA ?
Je ne connais pas cette question moi-même (d'autres sont sûrement mieux informés), mais l'indicateur ne fonctionne pas dans un fil séparé de l'EA. Ou du moins, cela n'aide pas à résoudre le problème des performances.
Le défilement dans l'indicateur est lent. Lorsque j'ai connecté le code moteur à l'EA, le défilement n'est pas très lent. Mais dans l'indicateur, ça colle.
En bref, on peut profiter de l'avantage d'un fil séparé. Mais dans ce cas, nous devons le mettre sur un graphique séparé.
Il crée un ensemble de tâches qui peuvent être rentables du point de vue de la commodité (le gui peut être déplacé entre les graphiques) et du point de vue de la vitesse (thread séparé).
Retag, débarrassez-vous dès que possible des fichiers ayant des problèmes de dénomination, ce n'est pas comique, surtout ceux distribués publiquement. Les espaces sont une douleur dans les scripts de shelters.
Eh bien, j'ai mis un tiret dans le nom. Que suggérez-vous ?
Je n'y connais pas grand chose moi-même (d'autres en savent probablement plus), mais l'indicateur ne fonctionne pas dans un fil séparé de l'EA. Ou du moins, cela n'aide pas à résoudre le problème des performances.
Le défilement dans l'indicateur est lent. Lorsque j'ai connecté le code moteur à l'EA, le défilement n'est pas très lent. Mais dans l'indicateur, ça colle.
En bref, nous devons faire en sorte que le moteur de l'Expert Advisor tire parti de son thread séparé. Et pour cela, nous devons le mettre sur un graphique séparé.
Cela crée un ensemble de tâches qui peuvent être rentables du point de vue de la commodité (le gui peut être déplacé entre les graphiques) et du point de vue de la vitesse (thread séparé).