Réaliser un projet de crowdsourcing sur Canvas - page 36
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
Tout élément d'un dialogue (formulaire, contrôle (bouton, liste, image)) possède certaines propriétés. La programmation procédurale ne définit pas le concept de "propriété" ou de "champ". En programmation procédurale, nous avons des fonctions et des variables (globales ou locales). Mais les variables sont communes, elles ne peuvent donc pas être utilisées pour décrire les propriétés de chaque contrôle individuel. Alors quelle est la solution ? Un simple : les structures !
Oui, une structure peut contenir une description des propriétés nécessaires d'un contrôle, ainsi qu'un tableau de contrôles imbriqués (jusqu'à l'infini).
Tous ces éléments sont stockés dans un tableau de boîtes de dialogue.
Nous pouvons la rendre plus universelle : la structure de description du contrôle est constituée de deux tableaux : le tableau des propriétés et le tableau des éléments esclaves. Un tableau de propriétés est un tableau de structures d'une paire propriété-valeur. Avec cette approche, chaque nouveau contrôle peut avoir n'importe quel ensemble arbitraire de propriétés. Mais ce n'est pas pratique pour le traitement. Il serait plus logique de spécifier les propriétés spécifiques du contrôle dans la structure : dimensions, emplacement, couleur, cadre, et ainsi de suite - tout ce dont un contrôle a besoin.
Et la structure contiendra également un tableau de pixels du contrôle.
Lorsqu'un événement souris est reçu, tous les tableaux sont parcourus en boucle pour vérifier si le curseur touche un contrôle particulier. La vérification s'effectue du dernier contrôle au premier.
Une fois qu'il est déterminé quel contrôle a le curseur, l'élément du tableau donné est envoyé à la fonction repaint, puis le tableau de ressources est mis à jour et l'image sur le graphique est mise à jour.
Je ne sais pas ce qu'il a publié et ce qu'il a fait en matière d'interface graphique, mais dans mes fils de discussion, il n'a fait aucune suggestion technique, aucune solution et aucune discussion sur le sujet. Seulement des trolls vides, signalant des solutions tierces et invitant à ne pas réinventer la roue.
Revenons au sujet qui nous occupe.
D'après ce que je sais de la bibliothèque standard (très peu en fait), les éléments et les fenêtres sont composés d'objets MT. C'est-à-dire, dans notre contexte - ils ne sont pas dessinés sur la toile. Bien sûr, ils sont dessinés, mais pas sur notre toile, ce qui nous empêche de contrôler les couleurs des pixels, de créer des gradients de surface, etc.
En théorie, nous pourrions prendre la structure de la bibliothèque, la copier et en faire un analogue sur le kanvas. En théorie...
Le problème est que CCanvas lui-même n'est pas adapté à la création d'une interface graphique. Pourquoi ? Parce que le système kanvas est utilisé principalement pour les primitives graphiques. Donc, en substance, cette classe ne fournit rien d'autre que des primitives. L'archétype de l'interface graphique doit être construit par vous-même. Et dans ce cas, le cours n'est pas nécessaire. Il est plus pratique de se débrouiller avec ses propres solutions. Après tout, vous pouvez dessiner un marqueur rectangulaire sans la classe. Tout comme vous pouvez créer ou charger un canevas. C'est très simple. Par conséquent, j'ai préféré ma propre solution.
Mais on ne peut pas se passer de CCanvas. C'est pourquoi je n'insiste pas.
Le problème avec CCanvas est que son interface graphique est strictement liée à la fenêtre du graphique.
En d'autres termes, vous ne pouvez pas créer une fenêtre à part entière en tant que module d'interface de terminal.
Et il serait très cool d'écrire vos propres modules d'interface.
légèrement faux bien sûr :-)
J'ai posté une interface à la DLL Tcl (qui est le langage commun des outils), qui a des graphiques Tk qui sont partagés comme une interface graphique dans Python/Ruby/etc.
le but n'était pas d'obtenir une interface graphique, mais un joli sous-produit :-)
tcl.Eval("button .pressme -text {Hello Peter}; pack .pressme") ;
à mon avis, pratique et surtout concis :-)
Je n'agite personne - je connais tcl/tk, je l'utilise, je partage mon expérience (voir sourceforge atcl).
Oui Max, c'est exactement ce dont je parle à propos de TCL et de votre prototype dont nous discutions à l'époque. Il y avait une restriction selon laquelle l'utilisateur devait avoir la bibliothèque appropriée installée sur son ordinateur. Cela n'a pas semblé être difficile, mais il y a quand même une certaine limitation.
Laissons cela dans le passé. Max, rejoignez-nous dans la discussion. Roman, rejoignez-nous aussi !))).
De ce qui précède, on peut comprendre qu'un élément de structure est un contrôle de dialogue spécifique, il contient ses propres propriétés et peut contenir des contrôles imbriqués. L'ensemble des propriétés d'un tel contrôle universel n'est limité que par l'imagination du développeur.
Bien sûr, nous pouvons éviter la structure et décrire les propriétés des contrôles dans un tableau multidimensionnel, mais ce n'est pas rentable au départ car nous devons nous rappeler clairement quel index du contrôle stocke une propriété quelconque. Et le tableau ne peut pas contenir des types de données hétérogènes. Il s'avère que la description de l'élément de contrôle dans la programmation procédurale n'est possible que par le biais des structures. Autrement dit, l'élément de structure est un contrôle concret, c'est-à-dire l'objet concret du dialogue avec ses propriétés.
Le problème avec CCanvas est que son interface graphique est strictement liée à la fenêtre du graphique.
En d'autres termes, vous ne pouvez pas créer une fenêtre à part entière en tant que module d'interface de terminal.
Et il serait très cool d'écrire vos propres modules d'interface.
Ensuite, il y aura l'inverse - relier l'interface au graphique. Par exemple, pour réaliser un bouton strictement lié à l'heure et au prix.
Une interface graphique distincte peut être écrite en un rien de temps - avec tous les tableaux, onglets, menus et sifflets. En C# ou même en BASIC. Et l'intérieur du graphique est un problème important pour les applications externes.
Tout élément d'un dialogue (formulaire, contrôle (bouton, liste, image)) possède certaines propriétés. La programmation procédurale ne définit pas le concept de "propriété" ou de "champ". En programmation procédurale, nous avons des fonctions et des variables (globales ou locales). Mais les variables sont communes, elles ne peuvent donc pas être utilisées pour décrire les propriétés de chaque contrôle individuel. Alors quelle est la solution ? Un simple : les structures !
Oui, une structure peut contenir une description des propriétés nécessaires d'un contrôle, ainsi qu'un tableau de contrôles imbriqués (jusqu'à l'infini).
Tous ces éléments sont stockés dans un tableau de boîtes de dialogue.
Nous pouvons la rendre plus universelle : la structure de description du contrôle est constituée de deux tableaux : le tableau des propriétés et le tableau des éléments esclaves. Un tableau de propriétés est un tableau de structures d'une paire propriété-valeur. Avec cette approche, chaque nouveau contrôle peut avoir n'importe quel ensemble arbitraire de propriétés. Mais ce n'est pas pratique pour le traitement. Il serait plus logique de spécifier les propriétés spécifiques du contrôle dans la structure : dimensions, emplacement, couleur, cadre, et ainsi de suite - tout ce dont un contrôle a besoin.
Et la structure contiendra également un tableau de pixels du contrôle.
Lorsqu'un événement souris est reçu, tous les tableaux sont parcourus en boucle pour vérifier si le curseur touche un contrôle particulier. La vérification s'effectue du dernier contrôle au premier.
Une fois qu'il est déterminé quel contrôle a le curseur, l'élément du tableau est envoyé à la fonction repaint, qui met à jour le tableau de ressources et l'image sur le graphique.
1. Supposons que vous ayez conçu une structure simple de contrôles de base - une fenêtre, un bouton, une case à cocher. Chacun d'entre eux est constitué d'un ensemble de composants - les objets. Case à cocher - base, texte, icône. Bouton - base, texte, icône, etc. Chaque objet de chaque élément doit avoir son propre ensemble de propriétés. Vous pouvez les écrire dans une structure ou une classe, mais à mon avis, ce n'est pas pratique. Pourquoi ? - Parce que lorsque vous les mettez dans une fenêtre, vous devez les trouver sur la toile avec le curseur. Lorsque vous déplacez le curseur, ils doivent être mis au point. Pour cela, leurs coordonnées actuelles doivent être dans un tableau. Et c'est plus pratique si toutes leurs propriétés (y compris les coordonnées actuelles) sont dans le même tableau. De cette façon, vous pouvez accéder immédiatement à n'importe quelle propriété de n'importe quel élément du canevas qui est le point de mire du curseur. Il est également plus facile de parcourir en boucle un tableau d'éléments.
En effet, il est plus facile de parcourir UN tableau dans une boucle pour trouver l'élément que le curseur a atteint. C'est encore plus pratique si ce tableau est global. Ensuite, dans n'importe quelle fonction, vous pouvez en tirer les informations nécessaires et modifier les valeurs des propriétés nécessaires, des éléments nécessaires.
C'est l'accès le plus court et le plus efficace aux éléments et leur traitement le plus rapide. C'est mon "noyau".
2. cependant, connaissant les caprices des professionnels qui cherchent à imiter au maximum la POO standard, je ne propose pas cette technologie.
3. un tableau de pixels n'a pas besoin d'être stocké quelque part. Il est construit au moment de la nécessité, en fonction des paramètres des éléments du tableau. Par exemple : vous devez redessiner la fenêtre. Nous appelons la fonction repaint. La fonction appelle le tableau d'éléments, voit toutes ses propriétés, déclare le tableau de pixels, calcule sa taille, dessine ses objets successivement dans la boucle, appelle ResourceCreate(). C'est tout.
Un élément pris sous le curseur est envoyé à la même fonction pour être repeint. Il reçoit une notification (drapeau de repeinte) et son numéro dans le tableau des éléments. Ensuite, la fonction appelle la ressource requise via ResourceReadImage(), la place dans le tableau de pixels et ensuite, à l'intérieur du tableau de pixels, trouve la zone de l'élément requis et repeint tous ses objets. C'est tout.
1. Supposons que vous ayez conçu une structure simple de contrôles de base - une fenêtre, un bouton, une case à cocher. Chacune est constituée d'un ensemble de parties constitutives - les objets. Case à cocher - base, texte, icône. Bouton - base, texte, icône, etc. Chaque objet de chaque élément doit avoir son propre ensemble de propriétés. Vous pouvez les écrire dans une structure ou une classe, mais à mon avis, ce n'est pas pratique. Pourquoi ? - Parce que lorsque vous les mettez dans une fenêtre, vous devez les trouver sur la toile avec le curseur. Lorsque vous déplacez le curseur, ils doivent être mis au point. Pour cela, leurs coordonnées actuelles doivent être dans un tableau. Et c'est plus pratique si toutes leurs propriétés (y compris les coordonnées actuelles) sont dans le même tableau. De cette façon, vous pouvez accéder immédiatement à n'importe quelle propriété de n'importe quel élément du canevas qui est le point de mire du curseur. Il est également plus facile de parcourir en boucle un tableau d'éléments.
En effet, il est plus facile de parcourir UN tableau dans une boucle pour trouver l'élément que le curseur a atteint. C'est encore plus pratique si ce tableau est global. Ensuite, dans n'importe quelle fonction, vous pouvez en tirer les informations nécessaires et modifier les valeurs des propriétés nécessaires, des éléments nécessaires.
C'est l'accès le plus court et le plus efficace aux éléments et leur traitement le plus rapide. C'est mon "noyau".
2) Cependant, connaissant les caprices des professionnels qui cherchent à imiter au maximum la POO standard, je ne propose pas cette technologie.
3. un tableau de pixels n'a pas besoin d'être stocké quelque part. Il est construit au moment de la nécessité, en fonction des paramètres des éléments du tableau. Par exemple : vous devez redessiner la fenêtre. Nous appelons la fonction repaint. La fonction appelle le tableau d'éléments, voit toutes ses propriétés, déclare le tableau de pixels, calcule sa taille, dessine ses objets successivement dans la boucle, appelle ResourceCreate(). C'est tout.
Un élément pris sous le curseur est envoyé à la même fonction pour être redessiné. Il reçoit une notification (drapeau de repeinte) et son numéro dans le tableau des éléments. Ensuite, la fonction appelle la ressource requise via ResourceReadImage(), la place dans le tableau de pixels et ensuite, à l'intérieur du tableau de pixels, trouve la zone de l'élément requis et repeint tous ses objets. C'est tout.
En fait, cela devrait fonctionner quelle que soit la technologie de construction. Mais elle peut être perçue différemment. Dans votre cas, vous passez un tableau dans la boucle et déterminez quel contrôle a le curseur à ce moment-là. Ainsi, lorsque vous définissez l'index, vous voyez immédiatement les propriétés de l'élément trouvé. Mais comment stocker différents types de données dans un seul grand tableau ?
En fait, cela devrait se produire indépendamment de la technologie de construction. Vous pouvez seulement le percevoir de différentes manières. Dans votre cas, vous bouclez à travers le tableau et déterminez quelle commande a le curseur en ce moment. Ainsi, lorsque vous définissez l'index, vous voyez immédiatement les propriétés de l'élément trouvé. Mais comment stocker différents types de données dans un seul grand tableau ?
En principe, il est possible de généraliser les types. J'en suis arrivé à la conclusion que rien de grave ne se produira si la grande majorité des propriétés des objets sont de type int. Tous les autres types abrégés (le double est pratiquement absent des propriétés des objets graphiques) ont été ignorés pour des raisons de simplification. Le "dépassement" de mémoire est si insignifiant qu'il est inutile d'y penser. Bien sûr, nous ne pouvons pas accepter un tel sacrilège au nom du professionnalisme))). Mais nous sommes au 21e siècle et je ne suis pas menacé par les feux de joie).
J'ai fait des noms des objets des nombres, et je les ai mis dans la série générale des propriétés des objets.
Le seul endroit où j'avais besoin d'un type de données différent était les paramètres de contrôle. J'ai créé un deuxième noyau, qui stocke les propriétés des paramètres et les valeurs elles-mêmes dans le type chaîne, que je peux facilement convertir en n'importe quoi (ou plutôt, en ce qui est prescrit dans les propriétés des paramètres).
ASTUCE : Par "paramètre de l'élément de commande", vous entendez le PARAMÈTRE GÉRÉ PAR L'ÉQUIPEMENT.1. Supposons que vous ayez conçu une structure simple de contrôles de base - une fenêtre, un bouton, une case à cocher. Chacune est constituée d'un ensemble de parties constitutives - les objets. Case à cocher - base, texte, icône. Bouton - base, texte, icône, etc. Chaque objet de chaque élément doit avoir son propre ensemble de propriétés. Vous pouvez les écrire dans une structure ou une classe, mais à mon avis, ce n'est pas pratique. Pourquoi ? - Parce que lorsque vous les mettez dans une fenêtre, vous devez les trouver sur la toile avec le curseur. Lorsque vous déplacez le curseur, ils doivent être mis au point. Pour cela, leurs coordonnées actuelles doivent être dans un tableau. Et c'est plus pratique si toutes leurs propriétés (y compris les coordonnées actuelles) sont dans le même tableau. De cette façon, vous pouvez accéder immédiatement à n'importe quelle propriété de n'importe quel élément du canevas qui est le point de mire du curseur. Il est également plus facile de parcourir en boucle un tableau d'éléments.
En effet, il est plus facile de parcourir UN tableau dans une boucle pour trouver l'élément que le curseur a atteint. C'est encore plus pratique si ce tableau est global. Ensuite, dans n'importe quelle fonction, vous pouvez en tirer les informations nécessaires et modifier les valeurs des propriétés nécessaires, des éléments nécessaires.
C'est l'accès le plus court et le plus efficace aux éléments et leur traitement le plus rapide. C'est mon "noyau".
2) Cependant, connaissant les caprices des professionnels qui cherchent à imiter au maximum la POO standard, je ne propose pas cette technologie.
3. un tableau de pixels n'a pas besoin d'être stocké quelque part. Il est construit au moment de la nécessité, en fonction des paramètres des éléments du tableau. Par exemple : vous devez redessiner la fenêtre. Nous appelons la fonction repaint. La fonction appelle le tableau d'éléments, voit toutes ses propriétés, déclare le tableau de pixels, calcule sa taille, dessine ses objets successivement dans la boucle, appelle ResourceCreate(). C'est tout.
Un élément pris sous le curseur est envoyé à la même fonction pour être repeint. Il reçoit une notification (drapeau de repeinte) et son numéro dans le tableau des éléments. Ensuite, la fonction appelle la ressource requise via ResourceReadImage(), la place dans le tableau de pixels, puis trouve la zone d'élément requise dans le tableau de pixels et repeint tous ses objets. C'est tout.
ugh cette négativité éternelle à oop, juste à travers la ligne
Vous êtes-vous déjà demandé comment il est apparu ? Le fait est que de nombreuses personnes qui écrivent dans un style procédural et ne connaissent pas la POO sont confrontées au désir de regrouper des fonctions, puis ce désir se développe en un désir de combiner ces fonctions dans une zone de mémoire et de s'y référer, c'est-à-dire de se référer physiquement à la zone avec des fonctions qui est stockée dans une variable. Ensuite, nous voulons changer notre groupe de fonctions sélectionnées sans dupliquer le code (nous obtenons l'héritage). Ainsi, une personne qui n'est initialement familiarisée qu'avec le style procédural demande quelque temps plus tard pourquoi il y a tant de restrictions dans un mql (référence à l'héritage multiple).
En général, on pense qu'il est plus facile d'enseigner la POO en une seule fois, car si une personne se familiarise avec le style procédural, il sera très difficile de se recycler (pour la plupart des gens), mais il y en a d'autres, car au départ il n'y avait que le style procédural... décrite ci-dessus.
ZS Il y a une variation sur la POO en général, une sorte de familiarité avec la POO au niveau du code procédural, et l'utilisation de la POO à son maximum.
Une classe est une référence à une mémoire (tableau) de fonctions, qui peuvent être réécrites et étendues tout en conservant le tableau principal + la référence aux variables. et j'oublie quoi d'autre..... (comme 32 octets)
Avec le problème de la recherche éternelle, j'ai récemment comparé la fonction de tri intégrée avec Red sort (un des modèles), perte de vitesse de 3 à 6 fois dans certaines conditions (intégrée perdue =).
En ce qui concerne l'interface graphique, je pense qu'il existe des méthodes standard.
,
Ugh, cette négativité perpétuelle envers l'OOP, à travers les lignes.
Vous êtes-vous déjà demandé comment il est apparu ? Le problème est que de nombreuses personnes qui écrivent dans un style procédural et qui ne connaissent pas la POO sont confrontées au désir de regrouper des fonctions, puis ce désir se transforme en un désir de combiner ces fonctions dans une zone de mémoire et d'y faire référence, c'est-à-dire de faire physiquement référence à une zone avec des fonctions qui est stockée dans une variable. Ensuite, nous voulons changer notre groupe de fonctions sélectionnées sans dupliquer le code (nous obtenons l'héritage). Ainsi, une personne qui n'est initialement familiarisée qu'avec le style procédural demande quelque temps plus tard pourquoi il y a tant de restrictions dans un mql (référence à l'héritage multiple).
En général, on pense qu'il est plus facile d'enseigner la POO en une seule fois, car si une personne se familiarise avec le style procédural, il sera très difficile de se recycler (pour la plupart des gens), mais il y en a d'autres, car au départ il n'y avait que le style procédural... décrite ci-dessus.
ZS Il y a une variation sur la POO en général, une sorte de familiarité avec la POO au niveau du code procédural, et une utilisation vraiment complète de la POO.
Une classe est une référence à une mémoire (tableau) de fonctions, qui peuvent être réécrites et étendues tout en conservant le tableau principal + la référence aux variables. et j'oublie quoi d'autre..... (comme 32 octets)
Avec le problème de la recherche éternelle, j'ai récemment comparé la fonction de tri intégrée avec Red sort (un des modèles), perte de vitesse de 3-6 fois dans certaines conditions (intégrée perdue =)
En ce qui concerne l'interface graphique, je pense qu'il existe des méthodes standard.
,
Je n'ai rien à redire sur le concept de la POO. J'en suis moi-même un adepte. J'ai un point négatif par rapport aux normes. Pour être plus précis, de les suivre sans réfléchir).
En dehors de ça, je suis pour l'OOP. Mais je suis pour un fonctionnement simplifié.