Réaliser un projet de crowdsourcing sur Canvas - page 37
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
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.
Dans la bibliothèque standard, il existe un dossier Generic dans le dossier Include, qui contient la classe CHashMapqui implémente l'interface de type clé-valeur.
Un objet unique peut avoir un ensemble de valeurs de n'importe quel type. Bien que l'arbre cartographique ait un temps d'exécution long, il fonctionne assez rapidement.
Cela pourrait même fonctionner pour décrire les propriétés, il faudrait essayer en général.
Ou bien utilisez un autre type de classe de cette bibliothèque, plus adapté à la tâche.
Relisez-le, c'est-à-dire que vous proposez de stocker un tableau égal à un tableau de pixels, afin de stocker des informations dans ce tableau (dans votre cas "quel numéro de fonction" doit être utilisé pour le traitement). ?
Ensuite, il y aura l'inverse - relier l'interface au graphique. Par exemple, pour fabriquer 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.
Et puis, pourquoi lier l'interface au graphique ?
Après tout, vous pouvez obtenir toutes les données, telles que les horodatages et les prix, directement à partir des fonctions pertinentes.
Relisez-le, c'est-à-dire que vous proposez de stocker un tableau égal à un tableau de pixels, afin de stocker des informations dans ce tableau (dans votre cas "quel numéro de fonction" doit être utilisé pour le traitement). ?
Si vous me demandez, je n'ai rien suggéré de tel. Je n'ai rien suggéré du tout)). J'ai juste décrit un peu mon point de vue. Vous êtes libre de ne pas être d'accord.
En principe, il est possible de généraliser les types. Je suis arrivé à la conclusion que rien de mauvais 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é rejetés par souci 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. Là, 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 string, que je peux facilement réduire à n'importe quoi (plus précisément, à ce qui est écrit dans les propriétés du paramètre).
ASTUCE : Par "paramètre de l'élément de commande", vous entendez le PARAMÈTRE GÉRÉ par l'élément de commande.Il s'avère que le tableau global, qui contient tous les contrôles et toutes leurs propriétés, a une profondeur de dimension égale à la somme de toutes les différentes propriétés des contrôles. En d'autres termes, même si certaines propriétés du contrôle ne sont pas nécessaires, ces cellules seront toujours dans ce tableau, car le tableau est toujours uniforme.
Ce qui est surprenant, cependant, c'est l'uniformité du tableau lui-même. À cet égard, l'utilisation d'une structure est plus que justifiée, car dans ce cas, chacune des propriétés peut être décrite par son propre type, y compris l'union.
L'utilisation de structures simplifie vraiment le stockage des propriétés, vous ne devez pas vous limiter à un seul type ou renoncer à quoi que ce soit. Vous n'avez pas à vous occuper des conversions de chaînes de caractères vers d'autres types de données... Une structure supprime toutes ces limitations dès le départ.
En plus des propriétés et des coordonnées elles-mêmes, ce tableau global doit également stocker le système de subordination des éléments. Si l'objet Caption de notre dessin a changé, les boutons doivent également être redessinés, car ils sont situés sur le champ d'en-tête. Ainsi, si un contrôle "central" a changé, tout ce qui s'y trouve doit être redessiné. Peter, comment stockez-vous la structure de dépendance des objets ?Il s'avère que le tableau global, qui contient tous les contrôles et toutes leurs propriétés, a une profondeur de dimension égale à la somme de toutes les différentes propriétés des contrôles. C'est-à-dire que même si certaines propriétés ne sont pas nécessaires pour un élément, ces cellules seront toujours dans ce tableau, car le tableau est toujours uniforme.
Ce qui est surprenant, cependant, c'est l'uniformité du tableau lui-même. À cet égard, l'utilisation d'une structure est plus que justifiée, car dans ce cas, chacune des propriétés peut être décrite par son propre type, y compris l'union.
L'utilisation de structures simplifie vraiment le stockage des propriétés, vous ne devez pas vous limiter à un seul type ou renoncer à quoi que ce soit. Vous n'avez pas à vous occuper des conversions de chaînes de caractères vers d'autres types de données... Une structure supprime toutes ces limitations dès le départ.
...Peter, comment stockez-vous la structure de dépendance des objets ?
Et puis, pourquoi lier l'interface au graphique ?
Après tout, vous pouvez directement récupérer n'importe quelle donnée, les mêmes horodateurs et le même prix, à partir des fonctions pertinentes.
au fait que l'interface d'application (ce avec quoi l'utilisateur opère) n'est pas limitée à une seule fenêtre.
Nous parlons de commerce, n'est-ce pas ?
Eh bien, le placement des éléments interactifs sur le graphique (et leur fixation) est presque impossible à résoudre par des moyens externes.
Là encore, les dialogues/formulaires externes sont faciles à dessiner. Mais les éléments à l'intérieur du graphique sont presque impossibles à dessiner sans les spécificités du terminal et du graphique en question.
Le noyau est la matrice. Il contient toutes les propriétés des objets.
La matrice est constituée de boucles imbriquées et les boucles imbriquées sont du temps. Imho, pas de sarcasme, juste un raisonnement logique.
Peter, vous obtenez ce qui suit : le noyau se compose d'une matrice globale des propriétés des éléments, d'une matrice globale des valeurs des éléments, d'une matrice globale des dépendances, d'une matrice globale des images...
Si d'autres propriétés doivent être ajoutées, la dimensionnalité des matrices est augmentée.
L'accès aux propriétés se fait strictement par index car les cellules n'ont pas de nom.
Au moins les noms des champs sont accessibles avec une structure.
Peter, tu es... géant...
Moi, par exemple, je vois les choses de cette façon (simplifiée) :
Une "classe" de facto est une chaîne spécifique dans votre tableau global, mais avec un visage plus "humain". Les classes sont conçues pour créer leurs propres objets de données, avec un ensemble de propriétés compréhensibles auxquelles on peut accéder par nom plutôt que par index. Une classe est simplement un constructeur de type universel.
Nous créons donc un contrôle de base qui contient les propriétés les plus courantes, que possède presque tout contrôle.
Vous pouvez créer des objets spécialisés sur cette base :
En d'autres termes, chaque type de contrôle suivant complète simplement le type de base avec les propriétés requises.
Et puisque, comme je l'ai écrit plus tôt, les propriétés de base sont stockées dans le contrôle de base, la traversée de la "frappe" du curseur dans le contrôle se fait en vérifiant un seul type de données : CControl. Ayant trouvé l'objet désiré, le programme a immédiatement accès aux propriétés de cet objet, puisque le point de programme se trouve déjà dans l'objet lui-même, tout comme dans votre boucle le programme se trouve sur la ligne de tableau désirée.