Galerie d'interfaces utilisateur écrites en MQL - page 55
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 aussi le canevas plein écran qui se redessine complètement à chaque changement, mais cela ne prend pas plus de 50ms...
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.
Oui, TextOut est utilisé. Je vais réfléchir à ce que l'on peut en faire.
L'arithmétique simple fonctionne ici : la somme des surfaces de 10 à 17 fenêtres est beaucoup plus grande que le plein écran. D'accord. Plus les dessins secondaires nécessaires pour créer les ombres, les icônes, les cadres....
En ce qui concerne TextOut, je vérifierai et écrirai. Idée intéressante.
Je ne comprends pas votre arithmétique simple :). Dans mon arithmétique, il n'est pas nécessaire de dessiner les pixels qui ne sont pas visibles par l'utilisateur, et la taille maximale de la toile pour le dessin est limitée par la taille de l'affichage en pixels.
Je dessine par couches, quel que soit le nombre de fenêtres, dans un seul bitmap. Il peut y avoir jusqu'à une centaine de fenêtres. Les primitives simples sont dessinées en un temps minuscule. Le plus long, comme je l'ai écrit plus haut, ce sont les textes. Mais ils sont créés avec l'aide de TextOut lors de la première utilisation, et plus loin déjà à partir de tableaux prêts à l'emploi.
Un plan pour les travaux futurs doit être approuvé.
Je publierai une mise à jour chaque semaine. Samedi ou dimanche.
1. Dans la prochaine version, je publierai une version complète du moteur. Je corrigerai les bugs et accélérerai le rendu.
2. La deuxième version sera dédiée aux tables. Je restaurerai les fonctionnalités de base.
3. la troisième version - je ferai des tableaux dynamiques. J'espère les mettre en place dans une semaine. Je vais essayer.
4. Quatrième version - fenêtre dynamique. J'essaierai de poster la version finie.
A ce stade, les versions de base du constructeur, du moteur et du langage de balisage peuvent être considérées comme complètes.
Je vais certainement ouvrir une branche de modèles écrits en code KIB, où je posterai des fenêtres et des groupes d'éléments finis. Avec des illustrations pour faciliter la tâche de ceux qui veulent construire l'interface.
Et j'essaierai d'écrire des articles tutoriels pour que les gens puissent utiliser tout l'éventail des possibilités.
Dans ce fil de discussion, je continuerai à poster du code, des images et du matériel explicatif dès que je le pourrai. Je serai très occupé par le travail mentionné ci-dessus.
Je ne comprends pas votre arithmétique simple :). Dans mon arithmétique, il n'est pas nécessaire de rendre les pixels qui ne sont pas visibles par l'utilisateur, et la taille maximale de la toile pour le rendu est limitée par la taille de l'affichage en pixels.
Je dessine en couches, quel que soit le nombre de fenêtres, dans un seul bitmap. Il peut y avoir jusqu'à une centaine de fenêtres. Les primitives simples sont dessinées en un temps minuscule. Le plus long, comme je l'ai écrit plus haut, ce sont les textes. Mais ils sont créés avec l'aide de TextOut lors de la première utilisation, et plus loin déjà à partir de tableaux prêts à l'emploi.
Travailler avec un seul grand canevas a beaucoup de limitations. J'ai déjà pensé à cette option et j'en ai même discuté avec Nikolay.
Je m'explique : vous le faites parce que vous utilisez la classe standard Ccanvas. Il existe des solutions toutes faites dans le cadre desquelles vous travaillez. Mais je n'utilise pas la classe Ccanvas. Tous les codes de rendu relèvent du développement personnel. C'est pourquoi je ne m'en tiens pas au concept - un seul canevas pour TOUT. À mon avis, c'est une solution techniquement peu pratique et inefficace dans un environnement graphique. Il est plus facile d'utiliser des ensembles d'objets bitmap et d'y attacher des ressources prêtes à l'emploi que d'avoir un bitmap et de construire par programme l'interaction des images sur ce bitmap. C'est même difficile à imaginer. Mais ce n'est pas l'essentiel.
Imaginez combien il est difficile de réaliser le concept d'une interface graphique multifenêtre si vous n'avez qu'un seul canevas. Je ne m'attellerais pas à une telle tâche.
Mais même cela n'est pas décisif. La principale raison de rejeter l'idée d'un seul canevas pour toutes les images : lorsqu'il n'y a qu'un seul canevas, le déplacement des fenêtres de l'interface nécessite un nouveau dessin dans l'environnement MQL. En revanche, si chaque fenêtre occupe son propre objet bitmap et est déplacée par la fonction ObjectSetInteger(), le redessin des objets déplacés relève de fonctions standard qui fonctionnent en dehors de l'environnement MQL. C'est donc beaucoup plus rapide.
Vous avez simplement une direction de développement différente dans laquelle d'autres solutions sont plus efficaces.
Merci beaucoup pour l'astuce concernant TextOut. Je vais étudier ce point.
Les branches du modèle sont écritesdans le code KIB qui
Oui, pour le débogage, je vais mettre en œuvre la déconnexion du programme utilisateur du moteur, si c'est ce que vous vouliez dire. J'ai probablement mal compris.
Travailler avec une seule grande toile présente de nombreuses limites. J'ai déjà pensé à une telle option et j'en ai même discuté avec Nikolay.
Je m'explique : vous le faites parce que vous utilisez la classe standard Ccanvas. Il existe des solutions toutes faites dans le cadre desquelles vous travaillez. Mais je n'utilise pas la classe Ccanvas. Tous les codes de rendu sont écrits par développement personnel. Je ne m'en tiens donc pas au concept - un seul canevas pour TOUT. À mon avis, c'est une solution techniquement peu pratique et inefficace dans un environnement graphique. Il est plus facile d'utiliser des ensembles d'objets bitmap et d'y attacher des ressources prêtes à l'emploi, que d'avoir un bitmap et de construire par programme l'interaction des images sur ce bitmap. C'est même difficile à imaginer. Mais ce n'est pas l'essentiel.
Imaginez combien il est difficile de réaliser le concept d'une interface graphique multifenêtre si vous n'avez qu'UN canevas. Je ne m'attellerais pas à une telle tâche.
Mais même cela n'est pas décisif. La principale raison de rejeter l'idée d'un seul canevas pour toutes les images : lorsqu'il n'y a qu'un seul canevas, le déplacement des fenêtres de l'interface nécessite un nouveau dessin dans l'environnement MQL. En revanche, si chaque fenêtre occupe son propre objet bitmap et est déplacée par ObjectSetInteger(), le nouveau dessin lors du déplacement est pris en charge par des fonctions standard qui fonctionnent en dehors de l'environnement MQL. Il est donc beaucoup plus rapide.
Vous avez simplement une direction de développement légèrement différente dans laquelle d'autres solutions fonctionnent plus efficacement.
Merci beaucoup pour le conseil sur TextOut. Je vais étudier ce point.
Je n' utilise pas le kanvas standard :).
Et j'ai trouvé plus facile d'implémenter une interface multi-fenêtres sur une seule bitmap. Mais chacun ses goûts !
Et en pratique, il semble plus rapide de redessiner tout le canevas que d'utiliser ObjectSetInteger, etc....