Réaliser un projet de crowdsourcing sur Canvas - page 8

Nouveau commentaire
 
o_O:

OK.

le CFrame est clair.

---

J'ai remarqué que vous avez emprunté la voie où les blocs gui sont chacun représentés par leur propre bitmap.

un point important pour ceux qui lisent ceci et qui ont déjà commencé à y penser :
ne devrait travailler que sur un seul bitmap, avec tous les éléments du gui rendus sur celui-ci. Y compris l'ordre z.
Dans ce cas, il y aura plus de possibilités de rendu. (ombres, dégradés, etc.)
Et le contrôle est simplifié (nous n'irons pas jusqu'au niveau des objets MT)

À mon avis, chaque fenêtre d'application individuelle (dialogue) devrait avoir son propre bitmap et son propre objet sur le graphique (n'envisagez même pas le cas où plusieurs EA ou indicateurs "violeront" une seule ressource bitmap).
Dans ce cas, l'ombre d'une fenêtre peut être implémentée en tant que bitmap à canal alpha et ainsi supprimer la charge de calcul de cette ombre.
Tous les éléments de l'interface graphique d'une seule fenêtre sont dessinés sur son bitmap en tenant compte de l'ordre Z et de l'imbrication (je ne sais pas comment appeler correctement l'imbrication des objets de l'interface graphique)

Surveiller les événements de la souris par CHARTEVENT_MOUSE_MOVE, je l'ai fait dans mes projets, aucun décalage n'a été trouvé.
Il n'était pas possible d'utiliser d'autres événements sans perdre la qualité de la saisie de la souris.
 
Pour mes projets MQL, je veux amener la bibliothèque GUI à l'analogue de WPF, où le balisage et les événements sont décrits dans un fichier texte (par exemple XML).

Il ne me reste plus qu'à implémenter les événements que le moteur GUI appellera selon la description du fichier texte.
 
Zorro:
À mon avis, chaque fenêtre d'application individuelle (dialogue) devrait avoir son propre bitmap et son propre objet sur le graphique (n'envisagez même pas le cas où plusieurs EA ou indicateurs "abuseront" d'une ressource bitmap).
Dans ce cas, l'ombre d'une fenêtre peut être implémentée en tant que bitmap à canal alpha et ainsi supprimer la charge de calcul de cette ombre.
Tous les éléments de l'interface graphique d'une seule fenêtre sont dessinés sur son bitmap en tenant compte de l'ordre Z et de l'imbrication (je ne sais pas comment appeler l'imbrication des objets de l'interface graphique).

c'est correct.

J'ajouterais que ce n'est pas seulement "chaque dialogue", mais spécifiquement un bitmap par expert/indicateur. Plus est possible, mais c'est à la discrétion du codeur.

Je pense que lorsque vous avez un dialogue fonctionnel sur un bitmap, puis ajoutez des fenêtres modales sur le même bitmap ou un autre dialogue sur le même bitmap - une question de technique et non de principe maintenant.

Tout d'abord, nous faisons un modèle abstrait sans spécificités, par exemple quelles fenêtres sont situées où, etc.

Vous serez alors en mesure de couvrir toutes les différentes caractéristiques et comportements

 
o_O:

Salutations aux codeurs.

Il y a une tâche intéressante à accomplir pour faire quelque chose de vraiment utile, et je pense que le crowdsourcing serait une bonne option.
Tout d'abord, les résultats seront accessibles à tous dès les premiers stades. Deuxièmement, nous allons créer quelque chose de nouveau en utilisant MQL. Et peut-être même que nous demanderons aux développeurs de MT de nous fournir de nouveaux goodies.

----

Voici donc la première tâche de base.

1. Nous devons créer une classe de bouton (disons GButton, préfixé par G pour ne pas confondre avec les boutons existants).
- Jusqu'à présent, le bouton est simple avec du texte (pas d'images supplémentaires)
- le bouton est dessiné sur une certaine zone du canevas
- le bouton a un événement de clic.



---
Dans le temps nous ferons les codes sur le bitbucket.

Je suis cette affaire avec intérêt et je voudrais intervenir un peu : je pense qu'un développeur (comme moi) investirait dans une interface graphique surchargée, si cette interface peut être dessinée non seulement au moyen d'un terminal. Je m'explique : une belle interface graphique, c'est bien, c'est un plus pour les ventes... mais tant qu'elle ne consomme pas de ressources. L'idéal serait d'avoir une bibliothèque GUI qui puisse commuter le back-end. Par exemple, tant que je ne suis pas trop regardant sur les ressources, laissez-les être dessinées par le terminal sur la toile (démos/marché), mais dès qu'il s'agit de quelque chose de sérieux, dessinez-les via des outils rapides sur un bitmap. Il existe toutes sortes de cairo (sans parler d'OpenGL) qui gèrent plus facilement le dessin.

L'interface graphique idéale est conçue dans une application distincte et importée en XML par exemple. Ce n'est pas une bonne idée de décrire l'emplacement des boutons et des formulaires de dialogue dans un EA.
 
Exemple, schéma :

Mise en page :
<sample>
   <window
     name='Sample'
     caption='Sample'
     x=0
     y=0
     width=320
     height=240
     OnClose='CloseApp'>

     <button caption='Exit' x y width height OnClick='ButtonExitClick'/>    

   </window>

</sample>
Mise en œuvre des événements :
class SampleCloseAction : public CloseAction
  {
public:
               SampleCloseAction() { SetActionName("CloseApp"); }
   virtual int Execute() { Print('Bye'); return(0); }
  };

class ButtonExitAction : public ButtonClickAction
  {
public:
               ButtonExitAction() { SetActionName("ButtonExitClick"); }
   virtual int Execute() { GUI::WindowClose('Sample'); return(0); }
  };

BaseAction *actions[];

actions[0]=new SampleCloseAction;
actions[1]=new ButtonExitAction;

GUI::WindowCreate('Sample',actions);
 
Maxim Kuznetsov:

En général, l'idéal serait d'avoir une interface graphique conçue dans une application distincte et importée en XML par exemple. Ce n'est pas une bonne idée d'écrire la disposition des boutons et des formulaires de dialogue dans le conseiller expert.

Là-bas)

vous arrivez à notre première tâche, que nous ferons après avoir créé les éléments.

 
Maxim Kuznetsov:
En général, l'idéal serait d'avoir une interface graphique conçue dans une application distincte et importée en XML par exemple. Ce n'est pas une bonne idée d'écrire des dispositions de boutons et des formulaires de dialogue dans un EA.
Dans ce cas, vous devez tout d'abord écrire un analyseur XML rapide et efficace. C'est une bonne chose à avoir à la maison. J'utilise moi-même une version de CodeBase, elle est trop lente pour certaines tâches, notamment pour les nouvelles constructions. J'ai déjà tous ces patchs et béquilles dedans. En général, écrivez un bon analyseur syntaxique, camarades ! Facilitez la tâche à tout le monde.
 
Vasiliy Sokolov:
Dans ce cas, vous devez commencer par écrire un analyseur XML rapide et efficace. C'est une chose bien pratique à avoir à la maison. J'utilise moi-même une version de CodeBase, mais elle est vraiment lente pour certaines tâches, surtout dans les nouvelles constructions. J'ai déjà tous ces patchs et béquilles dedans. En général, écrivez un bon analyseur syntaxique, camarades ! Facilitez la tâche à tout le monde.
Peut-être savez-vous comment réaliser un curseur entièrement fonctionnel et entièrement dessiné ? En termes généraux, du moins... J'aimerais saisir le concept général.
 
Реter Konow:
Peut-être savez-vous comment créer un curseur fonctionnel et entièrement dessiné ? En termes généraux, du moins... J'aimerais apprendre le concept général.
Malheureusement, je ne peux pas. C'est un élément plutôt compliqué, même si vous le créez sur la base de primitives normales.
 
Реter Konow:
Peut-être savez-vous comment réaliser un curseur entièrement fonctionnel et entièrement dessiné ? En termes généraux, du moins... J'aimerais apprendre le concept général.

Regardez la classe CCanvas. Toutes les primitives de rendu sont disponibles.

deuxièmement, vous pouvez charger des bmp pour vos vides et les mélanger à la BitBlt sur le canevas.

123456789101112131415...45
Nouveau commentaire