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
Parler d'intuition. Je veux vous donner un exemple intéressant. Mon message, imprimé dans ce fil https://www.mql5.com/ru/forum/95632/page12il y a plus de deux ans:
1. Le concept d'un moteur graphique.
2. Concept du cœur graphique.
3. les étapes de la création du studio visuel pour la plateforme MT.
4. la description du mécanisme de création de l'interface EA.
Lemoteur graphique est un programme conçu comme un indicateur. Ce programme est conçu uniquement pour la gestion de l'interface utilisateur. Il exécute un ensemble de fonctions de base :
Le moteur graphique est ajouté à un graphique comme tout autre indicateur . Il comprend l'ensemble des fenêtres suivantes :
C'est, en principe, la fin du concept de moteur graphique. L'important est que sans elle, le fonctionnement de l'interface est impossible.
Un moteur graphique est un bloc d'informations contenant les données de tous les objets et fenêtres d'une interface, qui est enregistré dans un tableau et sauvegardé dans un fichier.
Ce bloc est une représentation numérique de l'interface graphique. Il est chargé par le moteur graphique à la demande de l'utilisateur. Le moteur graphique lui-même possède son propre noyau graphique interne qui assure le fonctionnement de ses propres fenêtres, et un espace libre est prévu à l'intérieur de ce noyau pour y intégrer l'interface utilisateur (sous la forme numérique). L'intégration est effectuée au cours du processus de chargement du noyau graphique à partir d'un fichier.
3. La création d'un studio visuel sur la plateforme MT, si j'ai bien compris, se divise en deux étapes :
4. Je voudrais présenter le mécanisme du processus de création d'une interface et lever légèrement le voile sur sa technologie. Expliquez d'où vient la facilité de créer une interface via un fichier.
C'est le cas : le moteur dispose d'une fonction spéciale qui crée un noyau graphique complet à partir d'un seul fichier avec un minimum d'informations de chargement. Les informations de démarrage contenues dans ce fichier sont explicites et lisibles par l'homme. Il est facile à écrire et à modifier. Par exemple, vous devez écrire "_CREATE_NEW_WINDOW" pour créer une fenêtre, et "_CHECKBOX" et le nom de la case à cocher, (le moteur reconnaît automatiquement le nom de l'élément, comme le nom de l'élément lui-même et comme le nom de son paramètre).
Cette fonction est appelée "G_CORE_BUILDER()" et elle construit le noyau graphique en prenant des données de deux sources principales : un fichier de démarrage créé par l'utilisateur et le tableau "CONTENT[]" contenant tous les groupes d'objets standards inclus dans les plateformes de fenêtres et de contrôles. "CONTENT[]" contient également des états et des scripts d'objets. Tout dans un seul tableau. En général, le matériel source de "CONTENT[]" + le fichier de chargement créé par l'utilisateur est utilisé par "G_CORE_BUILDER()" pour construire le noyau graphique avec lequel le moteur fonctionne.
C'est étonnant de voir à quel point les termes et les concepts n'ont PAS changé en deux ans de travail acharné. Et les fonctions, les tableaux et les mots-clés sont comme il est dit ici. Tout a été mis en œuvre en fonction de ce scénario. Et cette technologie fonctionne et évolue, malgré lefait qu'il y a deux ans, je n'avais AUCUNE expérience dans le développement d'un langage de balisage.
Je n'ai pas atteint une impasse, je n'ai pas changé le concept, je n'ai pas changé la direction. J'ai continué à créer le moteur, le noyau et le langage de balisage exactement comme je l'avais prévu à l'origine. Et la pratique confirme que la voie que j'ai choisie était la bonne.
Si ce n'est pas une intuition prophétique, alors qu'est-ce que c'est ?
Chers opposants.
Voici le code du script qui :
Résultat :
Ma solution est plus de 10 fois plus rapide.
Ajoutez à votre solution, le temps de sauvegarder la ressource et le temps de récupérer la ressource dans le tableau en utilisant ResourceReadImage();
Dans ma solution, ni la première ni la seconde ne sont nécessaires.
Ma solution est plus de 10 fois plus rapide.
Peter, si vous travaillez avec des cordes, vous perdrez en performance dans tous les cas. Il est donc surprenant de vous entendre courir après une performance mythique, même si vous avez choisi à l'origine une solution inadaptée pour cela : faire passer des messages par une chaîne de caractères, puis analyser ce message.
Peter, si vous travaillez avec des cordes, vous perdrez en performance dans tous les cas. Il est donc surprenant de vous entendre courir après des performances mythiques, même si vous avez choisi à l'origine une solution inadaptée pour cela : faire passer des messages par une chaîne de caractères, puis analyser ce message.
Vasily, comment faire autrement pour transférer des données de tous types entre programmes ?
OnChartEvent() est partiellement adapté.
Et d'ailleurs, mesurer moins de 20 millisecondes n'est, à strictement parler, pas valable du tout, du moins dans les systèmes avec multithreading préemptif. Mais même si vous acceptez votre résultat (en général, je l'admets), il ne vous dit toujours rien, car ce sont les coûts du cycle complet qui comptent. Et ce que vous avez mesuré n'en est qu'une partie.
J'ai besoin d'un moyen universel et le plus rapide. Pour travailler dans le testeur et contourner la file d'attente des événements OnChartEvent() ;
Le test montre que le transfert est 10 fois plus lent à travers les ressources. (sans mesurer le temps nécessaire à la sauvegarde de la ressource et à l'obtention de données à partir de celle-cià l'aide de ResourceReadImage()) .
Ma solution est la meilleure option dans les conditions initiales.
...Mais même si vous acceptez votre résultat (en général, je l'admets), il ne vous dit toujours rien, car ce sont les coûts du cycle complet qui comptent. Et ce que vous avez mesuré n'en est qu'une partie.
C'est vrai, mais si vous extrapolez à plus de lignes et d'engrenages, mon option l'emporte toujours.
Vasiliy, comment faire autrement pour transférer des données de tous types entre programmes ?
Mappage direct des structures via une union vers un tableau d'octets, partagé pour un accès global. Je ne sais pas si c'est techniquement faisable, mais si c'est le cas, la vitesse sera cosmique, car vous n'aurez pas à copier quoi que ce soit.