Créer une bibliothèque graphique à partir de zéro - page 2
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 suis sûr que ça ne vaut pas la peine de tout recommencer.
Des personnes très intelligentes ont consacré beaucoup de temps et de connaissances pour créer la même bibliothèque standard ou la bibliothèque Anatoli.
Les gens ont investi du temps et des connaissances et il serait stupide de ne pas les utiliser.
Nous devrions simplement prendre le meilleur, de notre point de vue, dans les deux et en construire un nouveau.
Nous devons apprendre des erreurs des autres. Nous ferons le nôtre).
Seulement pour !
L'objectif final de la bibliothèque n'est pas clair.
Et c'est un problème commun à toutes les bibliothèques graphiques, d'après ce que je peux voir.
Tous les projets proposés sur le forum doivent résoudre l'un des deux problèmes suivants : soit augmenter le revenu de l'utilisateur, soit accroître l'efficacité de l'obtention de ce même revenu.
Je ne me souviens pas qu'un seul auteur de projet ait pris la peine de montrer des exemples illustrant la manière de résoudre l'un de ces problèmes.
L'exemple le plus frappant, dont je me souviens dans le fil de discussion "Canvas is cool", était la présentation de graphiques d'une beauté tout simplement hypnotique... Cependant, je n'ai jamais compris comment cela pouvait augmenter les revenus de l'utilisateur (du moins de l'auteur) ou comment cela pouvait augmenter l'efficacité de l'obtention de ces revenus.
Il en va de même pour la bibliothèque d'Anatoly. Grande structure, bien pensée, mais... Je suis sûr que l'auteur lui-même n'utilise pas toutes les fonctionnalités de cette bibliothèque. Quant aux utilisateurs, je pense que nous pouvons les oublier.
Un autre exemple est le projet de Peter Konov. Pour les personnes qui ne peuvent pas (ne veulent pas) comprendre la POO, c'est une solution tout à fait fonctionnelle avec de bonnes fonctionnalités, mais... Encore une fois - pas un seul exemple montrant une augmentation de l'efficacité à générer des revenus.
À mon sens, la plupart de ces projets sont davantage nécessaires pour nourrir la vanité de leurs auteurs. En général, c'est une chose nécessaire. Mais il ne faut pas s'attendre à des "objectifs finaux". C'est comme si j'attendais de ma ligue TS (qui n'est qu'une collection de toutes sortes de simples experts) qu'elle surveille, profite, graille... Bien qu'il ne s'agisse que d'un indicateur de divers principes TS fonctionnant sur différents symboles.
Et c'est un problème commun à toutes les bibliothèques graphiques, d'après ce que je peux voir.
Tous les projets proposés sur le forum doivent résoudre l'un des deux problèmes suivants : soit augmenter le revenu de l'utilisateur, soit accroître l'efficacité de l'obtention de ce même revenu.
Je ne me souviens pas qu'au moins un auteur de projet ait pris la peine de montrer des exemples illustrant la manière de résoudre l'une de ces tâches.
En fait, il s'agit d'une section du forum des programmeurs ...... Vous ne devez pas chercher le sens financier ici)))) Pour ma part, je préfère résoudre ces questions séparément de ce forum.
L'objectif final de la bibliothèque n'est pas clair.
J'ai commencé avec votre bibliothèque, grâce à vous, puis je l'ai un peu affinée, puis un peu plus)))) finalement tout changé, y compris les fonctions réécrites des lignes, également la fonction de ligne large du canevas source, supprimé les fausses fonctions, mis un stub sur l'événement. Je n'ai pas encore complètement abandonné la structure W, bien qu'il en reste peu là aussi. J'ai ajouté le calcul de la barre à gauche et à droite par recherche binaire parmi d'autres éléments et j'ai également ajouté la recherche binaire elle-même avec la possibilité de choisir une valeur plus grande ou plus petite. Nous avons également ajouté la possibilité de construire à partir de tableaux de toutes sortes (séries temporelles/communes) et nous sommes arrivés à la conclusion qu'il est nécessaire de modifier la construction)))))).
Je boucle la boucle.
Je comprends la hiérarchie.
Je dois refaire le contrôle, mais il y a encore quelques coordonnées que je voudrais mettre séparément. Je voudrais les mettre dans un cercle. Je pense que le kotrol va partir des coordonnées, ainsi il sera plus vrai et simplifiera grandement le système. Bien sûr, je peux me tromper dans mes arguments - mais jusqu'à présent, cela semble une solution naïve.
Et le kotrol - ce n'est rien d'autre qu'un élément de base des styles - qui en théorie devrait se trouver après les coordonnées.
Logique - on peut avoir un élément sans styles, mais pas sans coordonnées
Il s'agit en fait d'une section du forum des programmeurs ...... Vous ne devez pas chercher le sens financier ici)))) Je préfère moi-même traiter ces questions séparément de ce forum.
Très drôle.
Il y a un fil à côté où il y a des batailles passionnées que "personne ne travaillera gratuitement" - vous dites, "ce n'est pas la peine de chercher le sens financier" ? ???
Très drôle.
A côté du sujet dans lequel il y a des batailles passionnées que "personne ne travaillera gratuitement" - vous dites, "ne cherchez pas le sens financier" ?
Je ne revendique même pas la paternité de la bibliothèque que j'ai reçue..... Sans parler de sa composante financière.
Je voulais juste savoir comment il fallait faire - correctement.
S'il y a un petit besoin, vous pouvez même récupérer le code au rebut.
Même si, idéalement, j'aimerais faire une version miniature de cette version correcte. Pour un code minimal et une utilité maximale.
L' objectif final de la bibliothèque n'est pas clair .
Nikolaï, bienvenue.
L'objectif ultime est de tenter de remédier aux lacunes des outils déjà en place à l'heure actuelle.
Je suppose que le plus probable sera la poursuite du développement de la bibliothèque standard afin d'améliorer la facilité de la connecter aux projets et d'améliorer le composant graphique, en quittant les objets graphiques et en passant au canvas.
Mais dans l'ensemble, ne spéculons pas sur ce que sera l'issue.
Nikolaï, bienvenue.
L'objectif ultime est de tenter de remédier aux lacunes des outils déjà en place à l'heure actuelle.
Je suppose que le plus probable sera la poursuite du développement de la bibliothèque standard afin d'améliorer la facilité de la connecter aux projets et d'améliorer le composant graphique, en laissant les objets graphiques et la transition vers le canvas.
Mais en général, ne nous attardons pas sur ce qui va se passer.
En bref, à propos de l'ingénierie :
Si vous avez envie d'améliorer un certain "A" en le redessinant, vous devez préciser ses défauts critiques. Il suffit de les énumérer et d'expliquer pourquoi il est impossible de les éliminer dans le processus de développement évolutif de A.
En revanche, personne ne l'interdit. Si vous aimez écrire du code, écrivez-le... Vous réécrivez "A", mais à votre façon, mais ce sera nouveau.
Je boucle la boucle.
Je comprends la hiérarchie.
Je dois refaire le contrôle, mais il y a encore quelques coordonnées que je voudrais mettre séparément. Je voudrais les mettre dans un cercle. Je pense que le kotrol va partir des coordonnées, ainsi il sera plus vrai et simplifiera grandement le système. Bien sûr, je peux me tromper dans mes arguments - mais jusqu'à présent, cela semble une solution naïve.
Et le kotrol - ce n'est rien d'autre qu'un élément de base des styles - qui en théorie devrait se trouver après les coordonnées.
Logique - on peut avoir un élément sans styles, mais pas sans coordonnées.
Vous n'avez même pas besoin d'argumenter avec ça, c'est la vérité ;)))
Styles, thèmes - il est possible de tout visser ultérieurement, si vous envisagez initialement un tel ajout. En fait, tout cela devrait se produire dans un contrôle de base et donc l'augmentation de la fonctionnalité ira également dans cette classe.
En ce qui concerne les coordonnées, je vois deux types : les coordonnées absolues, qui sont calculées par rapport au graphique et les coordonnées locales, qui sont calculées par rapport au parent.
Si, par exemple, un formulaire est rendu, son placement dans un graphique est géré par des coordonnées absolues. Si un bouton est placé dans un formulaire, il doit être positionné par rapport au conteneur dans lequel il est placé, c'est-à-dire par rapport au formulaire.
Lorsque les événements de déplacement de la souris sont reçus, nous obtenons les coordonnées absolues du point du curseur par rapport au graphique dans le gestionnaire. Lorsque nous vérifions que le curseur touche le formulaire ou l'un des éléments, nous devons comparer la coordonnée absolue du curseur avec la position actuelle de l'élément, en tenant compte de son positionnement. En d'autres termes, pour un formulaire, il s'agira simplement de comparer ses coordonnées et sa taille actuelles, mais pour un bouton, il faudra calculer la position absolue du bouton dans le système de coordonnées. C'est-à-dire que la coordonnée X pour la comparaison sera calculée de la manière suivante X = (Parent==null)?X() :(X()+Parent.X()), où X() est une fonction de classe qui renvoie la position X de l'élément. Cependant, la vérification de la présence du parent lui-même peut être effectuée au sein même de cette fonction. Par conséquent, si un élément a un parent, la coordonnée sera renvoyée en additionnant la coordonnée du parent à sa propre coordonnée dans le parent. En fait, le nombre d'éléments imbriqués peut être arbitraire et chacun d'eux est positionné par rapport à l'élément sur lequel il se trouve, et non par rapport au graphe, de sorte que la coordonnée absolue peut être calculée de manière récursive.