Galerie d'interfaces utilisateur écrites en MQL - page 53
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
Rether, pourriez-vous envisager de modifier le catalogue en anglais dans les prochaines versions ? Les fichiers du code source contenant les noms des catalogues sont remplacés par du texte.
Oui, bien sûr. J'y ai déjà pensé. Je ferai une version spéciale avec les noms de catalogue en anglais.
Je n'ai pas vérifié les fichiers, mais seulement les commentaires ici. Mais ce décalage ne semble pas être lié à la vitesse, mais à l'utilisation de ChartRedraw avant de créer complètement la nouvelle ressource. En effet, il se bloque avec un canevas vierge et affiche ensuite le nouveau canevas.
Bien sûr. J'y ai réfléchi. Je ferai une sortie spéciale qui inclura le nom du catalogue anglais.
Je suggérerais de ne pas faire une version spéciale avec des catalogues en anglais, mais de ne faire qu'une seule version en anglais, en changeant simplement le nom du catalogue en anglais, et l'étape suivante consisterait à changer le nom du fichier en anglais, tout en continuant à écrire le code source en russe.
Je suis d'accord. Je vais progressivement passer à des noms de répertoires en anglais. Ce sera plus rationnel.
Je n'ai pas vérifié les fichiers, mais seulement les commentaires ici. Mais ce "décalage" ne semble pas être lié à la vitesse, mais à l'utilisation de ChartRedraw avant que la nouvelle ressource ne soit entièrement créée. En effet, il fait clignoter un canevas vierge puis affiche le nouveau canevas.
C'est une idée intéressante, je vais essayer de la tester. Merci de votre compréhension.
Et donc, une mise à jour...
Il s'agit d'une mise à jour provisoire. Je publierai la prochaine version dans quelques jours. Il y aura de nouvelles fonctionnalités pour l'interaction des programmes avec les contrôles.
Je dois dire que je travaille sur deux versions - la 2470 et la nouvelle. La plupart des développements sont effectués sur l'ancienne version. La compilation y est plus rapide - 4 secondes contre 26 à 32 secondes. La nouvelle version fonctionne un peu différemment et c'est visuellement perceptible. Elle est parfois plus rapide, parfois plus lente. Peut-être que c'est juste une impression. Il est difficile de trouver une différence, mais il me semble qu'elle existe. L'interface de l'ancienne version vole. Sur la nouvelle version. Elle vole presque. Je pense peut-être que c'est parce que j'y suis habitué.
Cependant, il y a des nuances. Par exemple, il y a un problème lors du passage d'un graphique à l'autre, lorsque des valeurs incorrectes de hauteur et de largeur de graphique sont renvoyées. Cela fait sauter la barre des tâches. J'ai réussi à contourner ce problème, mais la barre des tâches ne réagit pas aux autres événements de redimensionnement des graphiques. Finalement, j'ai décidé de laisser les choses en l'état. La barre des tâches sautera lors du changement de graphique (tant qu'il y a un problème de retour de valeurs incorrectes), mais elle s'adaptera normalement aux autres événements.
Mais ce n'est pas tout. Il s'avère que les événements de redimensionnement des graphiques ne se produisent pas instantanément et qu'il y a une pause d'une demi-seconde. Ce délai se superpose au temps de redessin de la barre des tâches et on obtient un décalage décent. Ici, je suis impuissant.
Je dirai ceci : bien sûr, j'ai considérablement accéléré les graphiques, mais il y a encore d'autres solutions non optimisées dans le code. J'y travaille dur. Il s'agit principalement de la transition du focus de la fenêtre et de la file d'attente de redessin. Certains appels inutiles se produisent. La barre des tâches traîne. J'ai corrigé ce que j'avais le temps de corriger, mais pas tout. Mais le reste est l'affaire des prochains jours. Sinon, il n'y a pas grand chose à améliorer... peut-être seulement peigner et parfumer le code pour le rendre odorant)).
En général, si nous déboguons toutes les solutions non optimisées restantes, cela va voler... enfin, dans les limites des vitesses disponibles pour un programme MQL, bien sûr.
Prenez la version.
Et donc, une mise à jour...
...
Permettez-moi de dire que les graphismes se sont bien sûr considérablement accélérés, mais qu'il y a encore d'autres solutions non optimisées dans le code. Je travaille d'arrache-pied sur ces solutions. Il s'agit principalement de la transition du focus de la fenêtre et de la file d'attente de redessin. Certains appels inutiles se produisent. La barre des tâches traîne. J'ai corrigé ce que j'avais le temps de corriger, mais pas tout. Mais le reste est l'affaire des prochains jours. Sinon, il n'y a pas grand chose à améliorer... peut-être juste peigner et parfumer le code pour le rendre odorant)).
En général, si nous déboguons toutes les solutions non optimisées restantes, le système volera... enfin, dans les limites des vitesses disponibles pour un programme MQL, bien sûr.
Prenons l'exemple de la version.
Permettez-moi d'être clair : nous parlons ici de vitesse. Si vous corrigez les défauts de redéfinition de la fenêtre lors du changement de focus, la vitesse de l'interface sera à la limite supérieure d'un programme MQL. Les retards de la barre des tâches peuvent être partiellement corrigés. J'ai trouvé une bonne solution - appliquer à la mécanique de la barre des tâches le principe d'une fenêtre dynamique - elle ne ralentit pas lorsqu'elle est redimensionnée, lorsqu'elle est tirée par le cadre. Elle s'ajustera plus rapidement et plus imperceptiblement. Et bien sûr, nous devons annuler les redessins inutiles. C'est obligatoire. Mais si les événements CHARTEVENT_CHART_CHANGE eux-mêmes arrivent au programme avec un certain retard, le décalage visible des réactions de la barre des tâches est inévitable, bien qu'il n'ait rien à voir avec cela.
Par ailleurs, il existe de nombreuses possibilités de développement et d'amélioration de l'interface.
Quelques mots encore sur la vitesse de l'interface.
J'ai passé beaucoup de temps à vérifier les délais et à chercher des freins au rendu. Le bloc responsable de la mise en page du kanvas est construit de telle manière qu'avant d'initialiser le tableau qui va créer une ressource dans la fonction ResourceCreate(), il définit les limites de la boucle sur les détails de la fenêtre. Cela se fait à l'aide de filtres conditionnels configurés pour vérifier les événements entrants. Chaque événement appelant le bloc se voit attribuer des limites de dessin. Par exemple, en cas de réaction de l'élément au survol du curseur, le filtre avec les limites de la boucle uniquement sur les détails d'un élément particulier est activé. Le bloc ne sélectionne que ses détails sur l'image prise. Et pendant le cycle sur les détails, il ne dessine sélectivement que ceux-ci parmi le reste de l'image. Il trouve avec précision les endroits où initialiser et dessiner le détail correct de l 'élément correct. En même temps, il contourne correctement le reste de l'espace de l'image.
Mais l'accélération ne se limite pas à cela. Le bloc n'initialise pas les points de la toile si leur couleur correspond à la valeur requise. De même, il ne "parcourt" pas le tableau, mais "saute", en franchissant les distances. Cela permet de réduire les cycles de centaines de milliers d'itérations.
Mais ce n'est pas tout. Comme le tableau d'images est global (déclaré au niveau global), il conserve toujours en mémoire la modification de la dernière image. Et si des changements continuent à se produire sur la même toile, au lieu de vider son tableau à chaque fois, c'est l'image stockée qui est utilisée. Si le nom de la ressource ne change pas lors de l'événement suivant, il n'est pas nécessaire d'appeler ResourceReadImage(), ni d'envoyer à nouveau le tableau de canevas pour qu'il soit rempli. Le bloc continue à travailler avec les données restantes sans appeler ResourceReadImage(), et met à jour l'image avec ResourceCreate() après le changement.
Cela permet de gagner beaucoup de temps sur les appels à ResourceReadImage(). ainsi que sur l'effacement et le remplissage du tableau. C'est une bonne utilisation de la mémoire globale, n'est-ce pas ?
Lorsque l'on redessine des fenêtres, le bloc n'est pas appelé du tout. Les composants de la fenêtre sont effacés et créés et les ressources précédemment sauvegardées leur sont attachées. Il n'y a pas de rendu.
Malgré tout cela, il y a toujours des décalages, et ils sont inévitables. Permettez-moi d'expliquer ce qui se passe.
À la première ouverture d'une fenêtre, ou à la première ouverture d'un onglet, ou à l'événement d'une liste d'arbres, ou à la minimisation/démodélisation de grands espaces, il y a un redessin complet obligatoire des toiles. Jusqu'au moment où l'on crée des ressources d'images qui peuvent être efficacement liées/modifiées plusieurs fois par la suite, il faut TOUJOURS dessiner une image complète à partir de zéro. Le premier dessin est TOUJOURS le plus long. Il n'y a rien à sauvegarder, il n'y a pas d'image sauvegardée. C'est lorsque vous l'ouvrez pour la première fois que vous pouvez toujours constater des décalages. C'est inévitable.
Cependant, il y a une bonne solution ici aussi : déplacer les délais d'ouverture des fenêtres vers l'événement de chargement. Ce que je veux dire : à l'étape du chargement, le constructeur en arrière-plan dessine toutes les images et les enregistre dans les ressources à l'avance, de sorte que tout soit prêt au moment de l'ouverture. Ainsi, l'utilisateur ne verra aucun retard lors de l'ouverture des fenêtres pour la première fois. C'est bien sûr formidable, mais il y a un inconvénient. Le délai de la première ouverture se transformera en un délai de chargement et sa durée augmentera. Il est difficile de dire de combien. Je pense qu'en moyenne, il faut compter une seconde. Cela dépend de l'interface spécifique.
Je pense que cette option est préférable. Je préfère laisser l'interface concepteur/utilisateur se charger un peu plus longtemps, mais il n'y aura plus de décalage visuel à l'ouverture.
Je suis curieux d'entendre vos opinions à ce sujet.
Ajouté :
Il y a eu une idée pour sauvegarder les ressources de l'interface après le premier chargement dans un fichier. Leschargements suivants seront alors beaucoup plus rapides, car les ressources nécessaires sont déjà à la disposition du concepteur/moteur. Il faut y réfléchir.