Galerie d'interfaces utilisateur écrites en MQL - page 54
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
J'ai également un canevas plein écran qui se redessine complètement à chaque changement, mais cela ne prend pas plus de 50 ms....
Le plus coûteux est de dessiner du texte. C'est pourquoi, afin de ne pas utiliser TextOut à chaque fois, je les stocke dans des tableaux. Cela s'avère beaucoup plus rapide.
Le principal défi consiste maintenant à donner à l'utilisateur un contrôle programmatique sur les commandes de l'interface.
Techniquement, la tâche n'est pas difficile, car dans l'union symbiotique du programme utilisateur et du moteur, le noyau graphique est visible à un niveau global par les algorithmes des deux parties. Le problème est que l'utilisateur ne sait pas comment travailler avec le noyau. Il ne connaît pas et ne comprend pas les principes de gestion des éléments. Il est donc nécessaire de lui donner des "wrappers" familiers, c'est-à-dire des fonctions qui lui permettent d'accéder au noyau et d'en modifier les valeurs.
Mais il y a une nuance. Les noms des fonctions sont trop longs. Après tout, chaque enveloppe fonctionnelle d'un élément interactif devrait inclure les noms de l'élément et de la fenêtre. Cela est nécessaire pour s'orienter parmi les noms. Sinon, l'utilisateur sera facilement désorienté et ne comprendra pas ses enveloppes fonctionnelles. De plus, les noms peuvent coïncider, ce qui n'est pas bon du tout. Il faut donc générer des noms à partir de deux composants : le nom de l'élément et le nom de la fenêtre. Il n'y a alors pas de confusion, mais les noms des wrappers deviennent trop longs. Surtout si l'on tient compte des paramètres passés. En outre, vous devez ajouter des préfixes aux fonctions pour les retrouver rapidement via l'intellisense. Cela permet de filtrer efficacement l'échantillon de la fenêtre pop-up. Pratique. MAIS LONG !
Mais ce n'est pas tout. Le problème réside dans les paramètres transmis. Le choix est soit d'écrire des wrappers pour chaque preset get/set-properties des éléments et des fenêtres, soit que chaque wrapper accepte la liste complète des paramètres d'un appel utilisateur. C'est terriblement gênant. Et surtout, c'est difficile à expliquer.
Il existe une solution, et elle est simple. Voici ce que c'est : un groupe de propriétés abstraites. Des variables globales visibles simultanément du côté du programme de l'utilisateur et du moteur.
Comment cela fonctionnera-t-il ?
1. Tous les wrappers d'éléments et de fenêtres s'adresseront à la fonction centrale et lui transmettront leurs indices. Elle les utilisera pour déterminer l'élément/fenêtre cible de l'appel.
2. Après cet appel, l'utilisateur définira l'ensemble sélectionné de propriétés abstraites aux valeurs requises.
3. Appeler la fonction centrale et lui transmettre le c.word "Set".
4. Central définira les valeurs des propriétés abstraites à partir de leurs variables globales vers les propriétés cibles de l'élément ou de la fenêtre en question.
5. Il mettra à jour l'élément/la fenêtre et remettra les propriétés abstraites à zéro.
C'est tout.
À mon avis, il s'agit d'une solution simple et efficace qui offre les avantages suivants
a) un accès facile aux propriétés de n'importe quel élément ou fenêtre, sans passer de paramètres à une fonction qui exige une cohérence stricte. (Plus - limitation du nombre de paramètres passés. Et l'appel s'avère long et illisible).
c) Combinaison libre d'un ensemble de propriétés d'éléments et de fenêtres lors de la définition/réception de valeurs n'importe où dans le programme.
Si quelqu'un voit des inconvénients, qu'il le dise. Il serait bon de coordonner cette question avant la publication.
Nicholas, il faut tenir compte du fait que nous parlons de plusieurs fenêtres d'interface graphique. Dans la dernière version, il y en avait 17, chacune comportant des centaines d'éléments. Et chaque élément est complexe. Il se compose d'un ensemble de parties. Chaque détail est une section de la toile qu'il faut traverser et remplir au bon endroit avec les valeurs nécessaires.
Si nous prenons le nombre moyen de 10 fenêtres (Papkov, je m'en souviens, a commandé une interface de 11 fenêtres), et que nous imaginons que chacune d'entre elles possède un ensemble d'éléments ou un tableau, on comprend alors pourquoi le rendu complet de l'ensemble de l'interface prend autant de temps. Je rappelle que dans l'interface il y a des icônes, des ombres, des dégradés de surface, des cadres divers.... au total, le dessin complet de TOUTE l'interface prend au moins 500 ms. Vous ne pouvez rien y faire.
Il est possible d'aller plus vite en réduisant le nombre de fenêtres ou en simplifiant les graphiques.
En ce qui concerne le redécoupage, je n'ai pratiquement aucun appel à ChartRedraw(). L'indicateur _ChartRedraw est utilisé partout. Lorsque ce drapeau est activé, la fonction ChartRedraw() est appelée à la prochaine itération du timer, après 25 ms. C'est-à-dire une seule fois. De cette façon, j'évite les redessins inutiles. Ce n'est que dans de rares cas que je fais un appel direct à ChartRedraw().
J'ai également le canevas plein écran qui se redessine complètement à chaque changement, mais cela ne prend pas plus de 50 ms...
Le plus coûteux est de dessiner du texte. Par conséquent, pour ne pas utiliser TextOut à chaque fois, je les stocke dans des tableaux. Cela s'avère beaucoup plus rapide.
L'arithmétique simple fonctionne ici : la somme des surfaces de 10 à 17 fenêtres est beaucoup plus grande que le plein écran. Je suis d'accord. Plus le dessin secondaire nécessaire pour créer les ombres, les icônes, les cadres....
Pour ce qui est de TextOut, je vérifierai et écrirai. Idée intéressante.
J'ai effectué un test :
Je suis allé dans le fichier 1.mqh du projet de démonstration et j'ai réglé toutes les fenêtres sur le drapeau OOI (ouverture à l'initialisation). (ouverture à l'initialisation).
Au total, 15 fenêtres de tailles et de contenus différents. 2 fenêtres avec des barres de défilement et des tableaux (leur toile est donc partiellement cachée et est en fait 2 à 3 fois plus longue. La longueur totale peut être évaluée par le rapport entre le curseur et la barre de défilement). Surface totale de dessin(minimum) 2000*1000 pixels. Mais je pense que c'est plus que cela. Le nombre total de pièces dessinées est de 1158 (vérifié après l'impression du noyau). Temps de dessin complet de toutes les toiles à partir de zéro de 1600 à 1900 ms.
Encore une fois, faites attention à la quantité de détails qui ont dû être dessinés. Ombres, icônes, dégradés, cadres, textes.
Le temps de dessin est indiqué sur la capture d'écran :
Puis-je dessiner certaines fenêtres uniquement lorsqu'elles sont ouvertes ? Il est rare d'avoir des dizaines de fenêtres ouvertes en même temps. Ce n'est pas nécessaire.
C'est la seule chose qui arrive, croyez-moi. Je ne parle que du premier dessin de toutes les fenêtres de l'interface en même temps. C'est le premier dessin qui prend le plus de temps. Ensuite, toutes les images sont déjà sauvegardées et extraites de la mémoire si nécessaire. En un seul appel, elles sont attachées à leur toile en quelques millisecondes. Ce n'est pas un problème. Vous souhaitez simplement réduire la durée du premier dessin.
Il existe peut-être un moyen d'accélérer le dessin. Enlevez la base inférieure des plates-formes des fenêtres. Il s'agit de grandes toiles situées derrière la face avant où se trouvent les éléments. Si vous les enlevez, le dessin sera deux fois plus rapide. Il faudra que j'y réfléchisse.
Voici les toiles dont je parle :
1. la face avant où se trouvent les éléments :
2. la face arrière où se trouvent les boutons de la fenêtre (croix, minimiseur), l'icône et le texte du nom. Cependant, la fenêtre entière est colorée en vert et du temps y a été consacré. Mais l'utilisateur ne voit que les cadres et l'en-tête de la fenêtre. Il s'avère qu'à cet endroit, le dessin est fait en vain :