Réaliser un projet de crowdsourcing sur Canvas - page 39
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
...
Peter, vous avez fait un excellent travail en créant une bibliothèque d'interfaces graphiques dans votre style. Mais si vous avez l'intention de le publier, il vaut la peine de le remanier en fonction d'une technologie différente. Je suis prêt à vous aider dans cette démarche et à transférer, étape par étape, toute la puissance de votre bibliothèque d'une nouvelle manière.
Alexey, disons que je voudrais l'essayer. Comment proposez-vous de le faire ? C'est un travail impossible.
Peter, je ne peux probablement pas imaginer ne serait-ce qu'une petite fraction de la quantité de travail que vous avez accompli, et je suis plus que certain que je sous-estime simplement l'ampleur des objets créés. MAIS !
Comme toujours, il y a un MAIS !
Tout projet, même pas nécessairement en programmation.
Pour commencer, nous faisons abstraction des objets qui ont été créés. C'est-à-dire que nous ne les représenterons pas comme une matrice, des structures ou des classes. Nous accepterons simplement la notion d'OBJET (alias élément de contrôle, alias formulaire, alias interface dans son ensemble, et ainsi de suite). Vous essayez d'organiser l'interaction des objets de manière structurelle. Lorsque nous découvrirons ensemble ce qui est construit, nous essaierons de faire apparaître les régularités sur cette base. En principe, vous n'aurez pas à les identifier car vous les avez identifiés depuis longtemps et en avez fait un traitement unifié, vous vous contenterez d'expliquer le principe de fonctionnement et la finalité. Ensuite, nous allons simplement remplacer un objet par un autre dans votre projet. Bien sûr, ce sera beaucoup plus difficile que d'écrire à partir de zéro. Mais nous avons un objectif légèrement différent dans notre cas, donc dans l'ensemble il n'y a pas d'urgence. Mais des publications sur la traduction de l'algorithme matriciel en algorithme objet seraient probablement intéressantes non seulement pour les débutants. Je suis convaincu qu'au cours de ce travail, d'autres participants se joindront à nous pour partager leurs idées ou proposer une mise en œuvre plus pratique de tel ou tel algorithme.
D'une manière ou d'une autre, l'idée elle-même doit d'abord être représentée par un organigramme de l'algorithme.
J'ai fait ma suggestion. Mais vous pouvez faire autrement, tout dépend de votre désir et de votre vision de la question (travail en commun).
Peter, je ne peux probablement pas imaginer ne serait-ce qu'une petite fraction de la quantité de travail que vous avez accompli, et je suis plus que certain que je sous-estime tout simplement l'ampleur des objets créés. MAIS !
Comme toujours, il y a un MAIS !
Tout projet, même pas nécessairement en programmation.
Pour commencer, nous faisons abstraction des objets qui ont été créés. C'est-à-dire que nous ne les représenterons pas comme une matrice, des structures ou des classes. Nous accepterons simplement la notion d'OBJET (alias élément de contrôle, alias formulaire, alias interface dans son ensemble, et ainsi de suite). Vous essayez d'organiser l'interaction des objets de manière structurelle. Lorsque nous découvrirons ensemble ce qui est construit, nous essaierons de faire apparaître les régularités sur cette base. En principe, vous n'aurez pas à les identifier, car vous les avez identifiés il y a longtemps et vous en avez fait un traitement unifié, vous vous contenterez d'expliquer le principe de fonctionnement et la finalité. Ensuite, nous allons simplement remplacer un objet par un autre dans votre projet. Bien sûr, ce sera beaucoup plus difficile que d'écrire à partir de zéro. Mais nous avons un objectif légèrement différent dans notre cas, donc dans l'ensemble il n'y a pas d'urgence. Mais des publications sur la traduction de l'algorithme matriciel en algorithme objet seraient probablement intéressantes non seulement pour les débutants. Je suis convaincu qu'au cours de ce travail, d'autres participants se joindront à nous pour partager leurs idées ou proposer une mise en œuvre plus pratique de tel ou tel algorithme.
D'une manière ou d'une autre, l'idée elle-même doit d'abord être représentée par un organigramme de l'algorithme.
J'ai fait ma suggestion. Mais vous pouvez faire autrement, tout dépend de votre désir et de votre vision de la question (travailler ensemble).
Très bien. Je ferai ce que je peux. Je vais vous expliquer les solutions et l'architecture. Mais je ne sais pas si je vais réussir à la fin.
Les objets sont maintenant disposés dans le noyau. Ils doivent être sortis du noyau et mis dans des classes.
1. Je créerais probablement trois classes de base : "Rectangle_label", qui accueillerait toutes les propriétés de base des étiquettes rectangulaires, "Icon" et "Text". Ces objets font partie de presque tous les contrôles.
2. Ensuite, créez un groupe de classes descendantes. Ils seraient divisés selon les critères suivants : a) les éléments qui contrôlent un paramètre. b) les éléments qui sont contrôlés par le paramètre.
3. Les classes décriraient les propriétés spécifiques de chaque élément.
Ce ne sont que les premières idées. Ils peuvent avoir tort.
Avec ce schéma, l'héritage se révèle immédiatement multiple - les classes d'éléments (héritiers) doivent inclure les propriétés de trois classes de base à la fois.
Très bien. Je ferai de mon mieux. Je vais vous expliquer les solutions et l'architecture. Mais je ne sais pas si je vais réussir à la fin.
Actuellement, les objets sont organisés dans le noyau. Ils doivent être sortis du noyau et mis dans des classes.
1. Je créerais probablement trois classes de base : "Rectangle_label", qui accueillerait toutes les propriétés de base des étiquettes rectangulaires, "Icon" et "Text". Ces objets font partie de presque tous les contrôles.
2. Ensuite, créez un groupe de classes descendantes. Ils seraient divisés selon les critères suivants : a) les éléments qui contrôlent un paramètre. b) les éléments qui sont contrôlés par le paramètre.
3. Les classes décriraient les propriétés spécifiques de chaque élément.
Ce ne sont que les premières idées. Ils peuvent avoir tort.
Avec ce schéma, l'héritage se révèle être pluriel à la fois - les classes d'éléments (descendants) doivent inclure les propriétés de trois classes de base à la fois.
Voici donc un raisonnement.
"Je créerais trois classes de base : "Rectangle_label", qui contiendrait toutes les propriétés de base des étiquettes rectangulaires, "Icône", et "Texte"." - Classiquement, le premier objet s'appelle simplement Rectangle ou Rect, le second image généralisée, enfin, le troisième peut soit être décrit par des propriétés distinctes, soit constituer un objet distinct. Pour indiquer que le type de données créé est une classe en c++ et en mql, il est habituel d'indiquer C devant le nom du type, c'est-à-dire CRectangle, CImage, CText. Mais les types simples qui ne contiennent que des données hétérogènes sont plus pratiques à créer en tant que structures.
La première chose à prendre en compte est l'ensemble des propriétés de base des commandes LARGE. Plus loin, vous pouvez ajouter n'importe quelle propriété, ce ne sera pas un problème.
"a) les éléments qui contrôlent un paramètre. b) les éléments qui sont contrôlés par un paramètre." - un déchiffrage est nécessaire ici. Je ne comprends pas ce que signifient ces descriptions.
"y aura-t-il du succès à la fin" - il est encore mieux d'être sûr qu'il y aura du succès. Sinon, il est préférable de ne pas commencer.Eh bien, voici un raisonnement.
1. " Je créerais trois classes de base : " Rectangle_label ", qui contiendrait toutes les propriétés de base des étiquettes rectangulaires, " Icon " et " Text ". - Classiquement, le premier objet s'appelle simplement Rectangle ou Rect, le second image généralisée, enfin, le troisième peut soit être décrit par des propriétés distinctes, soit faire un objet blanc. Pour indiquer un type de données créé comme une classe en c++ et en mql, il est d'usage d'indiquer C devant le nom du type, c'est-à-dire CRectangle, CImage, CText
2. "a) les éléments qui contrôlent le paramètre. b) les éléments qui sont contrôlés par le paramètre." - un déchiffrage est nécessaire ici. Je ne comprends pas ce que signifient ces descriptions.
"Y aura-t-il du succès à la fin" - il est encore mieux d'être sûr qu'il y aura du succès. Sinon, il est préférable de ne pas commencer.1. La classe la plus élémentaire est GHObjest (objet graphique de base). Il devrait y avoir des propriétés x, y, x_size, y_sixe et différents types de liaison de coordonnées. Ce sont des propriétés communes à TOUS les objets.
2. ses descendants sont CRec, CImage, CText. Ils n'ont que des propriétés spécifiques et inhérentes.
3. Ensuite, il y a les classes de plate-forme de fenêtre. Il en existe plusieurs : fenêtre de menu, fenêtre d'options, fenêtre de dialogue, fenêtre dynamique. Il y a là un ensemble de propriétés spécifiques.
3. Ensuite, il y a les classes d'éléments. Il peut y en avoir jusqu'à 50. Ils sont divisés en catégories : 1) par méthode de traitement des paramètres, 2) par méthode ornementale.
C'est un bon point de départ. Nous devons créer un langage de balisage, pas une bibliothèque. A quoi bon sinon ?
ZS La plupart des commandes fonctionnent avec le paramètre qui leur est donné. L'essentiel de leur objectif est de contrôler un paramètre utilisateur. Mais, chaque contrôle le fait d'une manière différente.
ZSY. J'ai oublié d'ajouter - vous avez besoin d'une classe de base de paramètre avec ses propriétés. CParam par exemple.
1. La classe la plus élémentaire est le GOBijest (basic graphical object). Il devrait y avoir des propriétés x, y, x_size, y_sixe et différents types de liaison de coordonnées. Ce sont des propriétés communes à TOUS les objets.
2. ses descendants sont CRec, CImage, CText. Ils n'ont que des propriétés spécifiques et inhérentes.
3. Ensuite, il y a les classes de plate-forme de fenêtre. Il en existe plusieurs : fenêtre de menu, fenêtre d'options, fenêtre de dialogue, fenêtre dynamique. Il y a là un ensemble de propriétés spécifiques.
3. Ensuite, il y a les classes d'éléments. Il peut y en avoir jusqu'à 50. Ils sont divisés en catégories : 1) par méthode de traitement des paramètres, 2) par méthode ornementale.
C'est un bon point de départ. Nous devons créer un langage de balisage, pas une bibliothèque. A quoi bon sinon ?
ZS La plupart des commandes fonctionnent avec le paramètre qui leur est donné. L'essentiel de leur objectif est de contrôler un paramètre utilisateur. Mais, chaque élément le fait différemment.
J'ai une petite explosion de cerveau... )) Tout doit être dessiné, sinon vous ne pouvez pas le digérer. )
J'ai une petite explosion de cerveau... )) Tout doit être dessiné, sinon vous ne pouvez pas le digérer. )
)) Rien...
La classe de base du paramètre CParam a plusieurs descendants. Le fait est qu'il existe des propriétés générales des paramètres des articles contrôlés, et des propriétés spécifiques. Par exemple : un bouton a un paramètre contrôlé de type bool, tandis qu'une liste déroulante a un type "menu". En d'autres termes, un bouton permet de basculer entre 1 et 0, tandis qu'une liste offre une sélection limitée. Le curseur, par exemple, a un type de paramètre de "plage" - c'est-à-dire une plage. Il en existe plusieurs autres types et tous ont des propriétés uniques.
Par conséquent, les classes qui descendent de la classe de paramètres de base devraient l'être également. Quelque chose comme "CBool", "CRange", "CMenu".
)) Rien...
La classe de base du paramètre CParam a plusieurs descendants. Le fait est qu'il existe des propriétés communes pour les paramètres des articles contrôlés, et des propriétés spécifiques. Par exemple : un bouton a un paramètre contrôlé de type bool, tandis qu'une liste déroulante a un type "menu". En d'autres termes, un bouton permet de basculer entre 1 et 0, tandis qu'une liste offre une sélection limitée. Le curseur, par exemple, a un type de paramètre de "plage" - c'est-à-dire une plage. Il en existe plusieurs autres types et tous ont des propriétés uniques.
Par conséquent, les classes qui descendent de la classe de paramètres de base devraient l'être également. Quelque chose comme "CBool", "CRange", "CMenu".
Attendez. Essayons maintenant de l'envisager de manière un peu abstraite.
Peter, de votre point de vue, qu'est-ce que des contrôles comme les boutons, les étiquettes de texte, les boîtes de saisie et les boîtes à images ont en commun ?
Attendez. Essayons maintenant de l'envisager de manière un peu abstraite.
Peter, de votre point de vue, qu'est-ce que des contrôles tels que le bouton, l'étiquette de texte, la boîte de saisie, la boîte à images ont en commun ?
1. Coordonnées, dimensions.
2. Coordonner les dépendances, dimensionner les dépendances.
3. un tas d'autres choses en fonction du nombre total de propriétés dans la fonctionnalité du contrôle. J'ai 270 propriétés dans mon noyau. La plupart d'entre eux sont communs. Mais je dispose d'une fonctionnalité développée qui prend en charge de nombreuses fonctions. D'où un tel nombre de propriétés. Nous devons commencer par les propriétés les plus simples.
1. Coordonnées.
2. Coordonner les dépendances.
3. un tas d'autres choses en fonction du nombre total de propriétés dans la fonction de contrôle. J'ai 270 propriétés dans mon noyau. La plupart d'entre eux sont communs. Mais, j'ai une fonctionnalité avancée qui prend en charge de nombreuses fonctions. D'où un tel nombre de propriétés. Nous devons commencer par les propriétés les plus simples.
Oui, bien sûr, avec les propriétés les plus simples. Quels sont les objets primitifs qui pourraient constituer la même étiquette de texte ? Ou encore, de quels objets primitifs pourrait se composer un simple bouton ?