Galerie d'interfaces utilisateur écrites en MQL - page 56
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 n' utilise tout simplement pas le canevas de base :).
Et j'ai trouvé qu'il était plus facile d'implémenter une interface multi-fenêtres sur une seule bitmap. Mais chacun ses goûts !
Hélas, pas dans tous les cas. Pour mes tâches, il est techniquement plus facile de travailler avec un ensemble limité de bitmaps. Et 100 % plus rapide. Beaucoup plus rapide.
Mais, pour d'autres développements, d'autres solutions fonctionnent mieux, et donc oui - à chacun son métier. :)
Non Perth, c'est encore trop. Votre interface avec tout le texte, les ombres, etc. ne dépasse pas 50 ms sur un processeur faible.
Oui, je vais tout vérifier à nouveau. Mais ce n'est pas la question. Le bloc de dessin ne fait pas que dessiner. Il contient des labyrinthes logiques qui traitent les événements entrants. Ils sont nécessaires pour déterminer ce qu'il faut dessiner et ce qu'il ne faut pas dessiner. Ils choisissent où prendre les images, où et comment les superposer. S'il s'agissait d'une simple fonction de dessin de 100 lignes, il n'y aurait rien à dire. Mais il s'agit d'un mécanisme massif qui permet de s'assurer que TOUT est dessiné.
Cela vaut la peine d'être pris en considération.))
Je n' utilise tout simplement pas le canevas de base :).
...
Et ça, c'est une agréable surprise. :) L'auto-développement est toujours cool. Même s'il est imparfait.
La classe Ccanvas ne me dérange pas (j'ai même inclus sa fonctionnalité dans les fichiers constructeurs), mais je ne l'utilise pas encore. Le mot clé est "encore". J'ai de grands projets pour elle. Dans le futur.
Oui, je vais tout revérifier. Mais là n'est pas la question. Le bloc de dessin ne fait pas que dessiner. Il contient des labyrinthes logiques qui traitent les événements entrants. Ils sont nécessaires pour déterminer ce qu'il faut dessiner et ce qu'il ne faut pas dessiner. Ils choisissent où prendre les images, où et comment les superposer. S'il s'agissait d'une simple fonction de dessin de 100 lignes, il n'y aurait rien à dire. Mais il s'agit d'un mécanisme massif qui permet de s'assurer que TOUT est dessiné.
Cela vaut la peine d'être pris en considération.))
Non, lorsqu'il est correctement mis en œuvre, le modèle d'événement ne prend pas plus d'une microseconde (un millionième de seconde), même s'il y a des milliers de vérifications.
Je ne suis pas sur la défensive))) Ha ha. J'explique simplement. ))
D'accord. Je vais commencer par un test simple. Je remplirai une toile plein écran avec une couleur et je mesurerai le temps. Faites des mesures de votre fonction de rendu et vous verrez alors plus clairement si j'ai des freins dans mon code. C'est peut-être le cas. Je n'en discute pas. Je dois le vérifier.
Je ne suis pas sur la défensive.) Ha ha. J'explique juste. ))
D'accord. Je vais commencer par un test simple. Je remplirai une toile plein écran avec une couleur et je mesurerai le temps. Faites des mesures de votre fonction de rendu et vous verrez alors plus clairement si j'ai des freins dans mon code. C'est peut-être le cas. Je n'en discute pas. Je dois le vérifier.
J'ai pensé que vous n'aviez peut-être jamais travaillé avec le profilage. Vous ne travaillez pas non plus avec le débogage.
Je me suis dit que vous n'aviez peut-être jamais travaillé avec le profilage. Vous ne travaillez pas non plus avec le débogage.
La vitesse peut probablement être reléguée au second plan, et l'optimisation de la vitesse n'est pas quelque chose qui peut être fait rapidement, il est préférable d'améliorer la fonctionnalité pour l'instant.