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

Nouveau commentaire
 
Реter Konow:
Le noyau est la matrice. Il contient toutes les propriétés des objets.

Vous pouvez choisir votre méthode. Mais, au cours de toutes mes années de développement de GUI, j'ai constaté qu'aucune autre méthode ne peut fournir le même niveau de fonctionnalité. La simplicité et l'efficacité maximales sont la perfection.


Peter, avez-vous de l'expérience et des exemples d'écriture de GUI non seulement dans la version actuelle ?

Vous niez complètement les autres paradigmes, mais prétendez que votre modèle est le meilleur pour la mise en œuvre des interfaces graphiques. C'est une affirmation très controversée.

 

Fabriquer un indicateur qui corrige les angles d'inclinaison des lignes tracées, leurs points d'intersection et les proportions des ellipses. Alors que les points d'ancrage sont fixés dans le futur

après deux week-ends et une journée sanglante d'indé...

PS/ on a l'impression que les personnes qui dessinent les interfaces ne sont pas du tout impliquées dans le commerce.

 
Maxim Kuznetsov:

Réalisez un indicateur qui corrige les angles de pente des lignes tracées, leurs points d'intersection et les proportions des ellipses. Avec les points d'ancrage fixés dans le futur

après deux week-ends et une journée sanglante d'indé...

PS/ On a l'impression que les personnes qui dessinent les interfaces n'ont rien à voir avec le commerce.

Max, j'ose dire que dans la moitié des cas, c'est le cas. Le trader ne doit pas être un programmeur et le programmeur ne doit pas être un trader.

 

J'ose dire que Peter ne programme pas en autre chose que mql. Toutes les versions modernes des langages exigent de savoir travailler avec des classes : java, kotlin, sharp, python, c++, etc. Même 1C a un semblant de classes sous la forme de types d'objets fixes. Mais ce n'est qu'une digression.

De mon point de vue, le système de construction des interfaces devrait ressembler à ceci :

CForm Форма = new CForm;
Интерфейс.Добавить(Форма);
CButton КнопкаBUY= new CButton;
КнопкаBUY.Заголовок = "BUY";
КнопкаBUY.ЦветФона = clrBlue;
КнопкаBUY.Позиция(7,20);
Форма.Добавить(КнопкаBUY);

En d'autres termes, la création d'interfaces doit être déclarative. Je ne peux même pas imaginer comment un autre programmeur ajoutera la description des propriétés d'un contrôle faisant référence aux index......

Je suis sûr que même pour un programmeur moyen, ce serait déroutant, sans parler d'un débutant.

 
Алексей Барбашин:

J'ose dire que Peter ne programme pas en autre chose que mql. Toutes les versions modernes des langages exigent de savoir travailler avec des classes : java, kotlin, sharp, python, c++, etc. Même 1C a un semblant de classes sous la forme de types d'objets fixes. Mais ce n'est qu'une digression.

De mon point de vue, le système de construction des interfaces devrait ressembler à ceci :

En d'autres termes, la création d'interfaces doit être déclarative. Je ne peux même pas imaginer comment un autre programmeur ajoutera la description des propriétés au tableau en se référant aux index......

Je suis sûr que même pour un programmeur moyen, ce serait un casse-tête, sans parler d'un débutant.

S'il y a beaucoup d'éléments et/ou de propriétés qui dépendent d'un index, ce n'est pas un problème et vice versa, il est difficile d'écrire un fouillis tout en se référant à chaque élément individuel.

 
Roman:

Une matrice, ce sont des boucles imbriquées, et les boucles imbriquées, c'est du temps. Je ne suis pas sarcastique, je raisonne juste logiquement.

Bien. Tout dans l'univers prend du temps).
 
Алексей Барбашин:

1. Peter, vous obtenez ce qui suit : le noyau est constitué 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...

2. Si vous devez ajouter d'autres propriétés, la dimensionnalité des matrices est augmentée.

3. Les propriétés sont accessibles strictement par des index, car les cellules n'ont pas de nom.

Au moins les noms des champs sont accessibles avec la structure.

Peter, tu... géant...

Moi, par exemple, je vois les choses de cette façon (simplifiée) :

4. 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.

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.

1. Le noyau est une matrice globale. Deux dimensions. Le noyau est construit par une fonction spéciale qui lit un fichier où le langage de balisage indique quelles fenêtres et quels éléments doivent être créés.

2. Non, la dimensionnalité de la matrice est constante. Il n'y a que 2 dimensions.

3. Les propriétés des objets du noyau sont ordonnées. Chacun a son propre index. Les index sont nommés par des définitions. Plus le nombre de propriétés de l'objet augmente, plus la matrice s'élargit. Il existe des moyens de freiner sa croissance et de compacter les objets qui s'y trouvent.

4. La classe, en tant que description d'objet, est bonne, mais le mécanisme (ce qu'est le code) fonctionne plus efficacement avec le noyau. De toute façon, ça n'a pas d'importance. Il répond aux besoins de chacun.

La description et le stockage dispersés des propriétés des objets (les principales dans la classe de base, les autres dans les descendants) compliquent l'accès et la manipulation. Ajoutez les limitations de visibilité, les modificateurs d'accès et le langage extraterrestre et vous obtenez une véritable réduction non seulement du mécanisme, mais aussi du processus de développement. Cependant, il s'agit d'un avis personnel.
 
Реter Konow:
1. Le noyau est une matrice globale. Deux dimensions. Le noyau est construit par une fonction spéciale qui lit un fichier où le langage de balisage indique quelles fenêtres et quels éléments doivent être créés.

2. Non, la dimensionnalité de la matrice est constante. Il n'y a que 2 dimensions.

3. Les propriétés des objets du noyau sont ordonnées. Chacun a son propre index. Les index sont nommés par des définitions. Plus le nombre de propriétés de l'objet augmente, plus la matrice est large. Il existe des moyens de freiner sa croissance et de compacter les objets qui s'y trouvent.

4. La classe, en tant que description d'objet, est bonne, mais le mécanisme (ce qu'est le code) fonctionne plus efficacement avec le noyau. De toute façon, ça n'a pas d'importance. Il répond aux besoins de chacun.

La description et le stockage dispersés des propriétés des objets (les principales dans la classe de base, les autres dans les descendants) compliquent l'accès et la manipulation. Ajoutez les limitations de visibilité, les modificateurs d'accès et le langage extraterrestre et vous obtenez une véritable réduction non seulement du mécanisme, mais aussi du processus de développement. Cependant, il s'agit d'un avis personnel.

Ce n'est pas compliqué du tout, c'est la beauté et la puissance des classes. Chaque objet suivant construit sa fonctionnalité sur la base de la fonctionnalité de l'objet original. Par conséquent, toutes les fonctionnalités de base (focus, clics, hors élément, glisser-déposer, dessin) sont mises en œuvre sur la base d'objets de base. Le développement et la modification ultérieurs, le développement de nouveaux contrôles - tout cela n'affectera pas la fonctionnalité de base, car elle est créée au niveau, disons, de votre langue : le "noyau" de la bibliothèque. Dans ce cas, les objets auront exactement les types de données qui sont nécessaires pour une propriété particulière.

"Le noyau est construit avec une fonction spéciale qui lit un fichier, où il est écrit dans le langage de balisage quelles fenêtres et quels éléments doivent être créés." - C'est juste un peu léger. Vous avez donc une matrice qui stocke toutes les propriétés, et vous avez également un fichier de balisage qui spécifie exactement comment la matrice avec les propriétés doit être lue..."Les indices sont nommés via les définitions" - chaque indice est câblé à une définition. L'insertion aléatoire d'un champ supplémentaire entraînera un déplacement des propriétés avec des conséquences. "Au fur et à mesure que le nombre de propriétés de l'objet augmente, la matrice s'élargit" - c'est ce que je voulais dire par dimensionnalité (ma faute, j'ai mal appliqué le terme). En créant votre objet de données en tant que classe, vous évitez toutes ces complications. Et il s'agit là d'une véritable complexité, qui n'est pas vraiment nécessaire. Mais nous savons nous créer des complications afin de les surmonter avec succès par la suite.

Et vous n'avez pas à créer de classes hiérarchiques et vous n'avez pas à les utiliser du tout. Mais il est raisonnable d'utiliser des structures pour se débarrasser des fils de données inutiles. IMHO

Peter, vous avez fait un excellent travail en créant une bibliothèque d'interfaces graphiques dans votre style. Mais si vous prévoyez de publier cette chose, cela vaut quand même la peine de tout remanier pour une technologie différente. Je suis prêt à vous aider dans cette démarche et à transférer pas à pas toute la puissance de votre bibliothèque dans une nouvelle direction.

 
Алексей Барбашин:

Il n'y a rien de plus compliqué que cela, ce qui est la beauté et la puissance des classes. Chaque objet suivant construit sa fonctionnalité sur la base de la fonctionnalité de l'objet original. Par conséquent, toutes les fonctionnalités de base (focus, clics, hors élément, glisser-déposer, dessin) sont mises en œuvre sur la base des objets de base. Le développement et la modification ultérieurs, le développement de nouveaux contrôles - tout cela n'affectera pas la fonctionnalité de base, car elle est créée au niveau, disons, de votre langue : le "noyau" de la bibliothèque. Dans ce cas, les objets auront exactement les types de données qui sont nécessaires pour une propriété particulière.

"Le noyau est construit avec une fonction spéciale qui lit un fichier, où il est écrit dans le langage de balisage quelles fenêtres et quels éléments doivent être créés." - C'est juste un peu léger. Vous avez donc une matrice qui stocke toutes les propriétés, et vous avez également un fichier de balisage qui spécifie exactement comment la matrice avec les propriétés doit être lue... En créant votre objet de données comme une classe, vous évitez toute cette complexité. Et ce sont des complexités réelles dont vous n'avez pas vraiment besoin. Nous savons nous créer des complications pour mieux les surmonter par la suite.

Et vous n'avez pas à créer de classes hiérarchiques et vous n'avez pas à les utiliser du tout. Mais il est raisonnable d'utiliser des structures pour se débarrasser des fils de données inutiles. IMHO

Peter, vous avez fait un excellent travail en créant une bibliothèque d'interfaces graphiques dans votre style. Mais si vous prévoyez de publier cette chose, cela vaut quand même la peine de tout remanier pour une technologie différente. Je suis prêt à vous aider à le faire, et à déplacer pas à pas toute la puissance de votre bibliothèque dans une nouvelle direction.

Vous savez, j'ai tellement discuté ici de la mise en œuvre de mes propres solutions et de celles des autres que j'en suis fatigué. )) C'est juste, vraiment fatiguant. Ma pensée est plus adaptée à la matrice, celle des autres aux classes... Ça ne vaut pas la peine de casser des lances.

J'ai généralement tendance à changer ou à simplifier les règles, à m'écarter du cours général, à faire valoir mes idées plutôt que celles d'autrui. Tu ne peux pas me changer.

Merci pour l'offre. Vous pouvez suivre votre propre voie dans le développement des interfaces graphiques. J'ai déjà fait mon chemin et je ne vois pas l'intérêt de le répéter dans un style différent. Il y a un langage de balisage, quelques étapes vers l'éditeur de vis et environ une semaine pour publier. Il y a encore une barre des tâches à refaire et des bugs mineurs à corriger. Ensuite, vous donnerez votre avis sur mon travail. J'espère qu'il sera utile à tous.

ZS. Après la publication, je pourrai donner plus de détails sur les solutions et cela pourra vous aider à créer un analogue dans les classes.
 
Реter Konow:
Vous savez, j'ai tellement discuté ici de la mise en œuvre de mes propres solutions et de celles des autres que j'en suis fatigué. )) C'est juste, vraiment fatiguant. Ma pensée est plus adaptée à la matrice, celle des autres aux classes... Ça ne vaut pas la peine de casser des lances.

Je suis généralement enclin à changer ou à simplifier les règles, à m'écarter du cours général, à faire valoir mon point de vue sur celui d'autrui. Tu ne peux pas me changer.

Merci pour l'offre. Vous pouvez suivre votre propre voie dans le développement des interfaces graphiques. J'ai déjà fait mon chemin et je ne vois pas l'intérêt de le répéter dans un style différent. Il y a un langage de balisage, quelques étapes vers l'éditeur de vis et environ une semaine pour publier. Il y a encore une barre des tâches à refaire et des bugs mineurs à corriger. Ensuite, vous donnerez votre avis sur mon travail. J'espère qu'il sera utile à tous.

Dans votre cas, il ne s'agit pas d'une simplification, mais d'une véritable complication. IMHO

1...313233343536373839404142434445
Nouveau commentaire