Réaliser un projet de crowdsourcing sur Canvas - page 13
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
Pour moi, il est plus facile de créer une équipe de développement de produit, dont les membres, dans une mesure convenue, recevront un bénéfice des ventes du produit (peut-être quelqu'un est l'idéologue du projet, quelqu'un finance une part, quelqu'un est le programmeur).
Et puisque tout le monde est financièrement motivé, mettre en œuvre les bibliothèques nécessaires pour l'interface dans le cadre du projet également.
Pour moi, il est plus facile de créer une équipe de développement de produit, dont les membres, dans une mesure convenue, recevront un bénéfice des ventes du produit (peut-être quelqu'un est l'idéologue du projet, quelqu'un finance une part, quelqu'un est le programmeur).
Et puisque tous sont financièrement motivés - pour mettre en œuvre dans le projet et les bibliothèques nécessaires pour l'interface.
J'ai lu le fil de discussion et je ne comprends toujours pas pourquoi il est nécessaire de dessiner un bouton sur Canvas à partir de zéro. Pouvez-vous expliquer sans émotions ?
parce que les développeurs de MT ne sont pas omnipotents et qu'il est fastidieux de les importuner avec des demandes insignifiantes.
Pourquoi ça pourrait être utile :
1. l'interface sur le bitmap est rapide. Si rapide qu'il est presque impossible de le distinguer de celui du système. Par exemple, j'ai implémenté des éléments semi-transparents avec des gradients etmême lorsqu'ils se déplacent, ils sont rendus de manière fluide sans retard visible, en tenant compte du mélange des couleurs et du calcul du canal alpha sur d'autres objets avec des gradients semi-transparents.
2. l'interface est évolutive. Vous pouvez rendre l'application plus complexe et elle ne ralentira pas en raison de la suppression et de la création d'un grand nombre d'objets de graphe. Les coûts de redécoupage sont minimes, à peine un millième de seconde.
3. il est possible de créer des contrôles prêts à l'emploi et d'en créer de nouveaux, car vous pouvez fournir votre propre pool d'événements, par exemple :
OnMouseDown - a appuyé sur le LKM
OnMouseUp - a appuyé sur le LKM
OnMouseHoverOn - survole le curseur de la souris sur un objet
OnMouseHoverOut - éloigne le curseur de la souris de l'objet.
OnMouseClick : appuyer et cliquer dans les limites de l'objet.
OnMouseDblClick - double clic de souris dans les limites de l'objet.
OnDragStart - événement qui se produit une fois au début du mouvement avec le bouton gauche de la souris enfoncé
OnDragMove - événement généré lors d'un déplacement avec le bouton gauche de la souris
OnDragEnd - événement généré après un déplacement avec le LKM
OnPut - l'objet est transformé en un autre objet.
OnGet - l'objet est transféré vers un autre objet.
OnFocus - l'objet a reçu le focus
OnBlur - l'objet perd le focus
OnResize - l'objet a changé de taille
OnParentResize - l'objet parent a changé de taille.
OnKeyPress - une touche enfoncée
OnChange - la valeur d'un champ a changé
etc.
Pourquoi ça pourrait être utile :
1. l'interface sur le bitmap est rapide. Si rapide qu'elle est pratiquement indiscernable de l'interface du système. Par exemple, j'ai implémenté des éléments semi-transparents avec des gradients etmême lorsqu'ils se déplacent, ils sont rendus de manière fluide sans aucun retard visible, en tenant compte du mélange des couleurs et du calcul du canal alpha sur d'autres objets avec des gradients semi-transparents.
2. l'interface est évolutive. Vous pouvez rendre l'application plus complexe et elle ne ralentira pas en raison de la suppression et de la création d'un grand nombre d'objets de graphe. Le coût du redécoupage est minime, il s'agit seulement d'un remplacement de l'image en un millième de seconde.
3. il est possible de créer des contrôles prêts à l'emploi et d'en créer de nouveaux, car vous pouvez fournir votre propre pool d'événements, par exemple :
OnMouseDown - a appuyé sur le LKM
OnMouseUp - a appuyé sur le LKM
OnMouseHoverOn - survole le curseur de la souris sur un objet
OnMouseHoverOut - éloigne le curseur de la souris de l'objet.
OnMouseClick : appuyer et cliquer dans les limites de l'objet.
OnMouseDblClick - double clic de souris dans les limites de l'objet.
OnDragStart - événement qui se produit une fois au début du mouvement avec le bouton gauche de la souris enfoncé
OnDragMove - événement généré lors d'un déplacement avec le bouton gauche de la souris
OnDragEnd - événement généré après un déplacement avec le LKM
OnPut - l'objet est transformé en un autre objet.
OnGet - l'objet est transféré vers un autre objet.
OnFocus - l'objet a reçu le focus
OnBlur - l'objet perd le focus
OnResize - l'objet a changé de taille
OnParentResize - l'objet parent a changé de taille.
OnKeyPress - touche enfoncée
OnChange - la valeur d'un champ a changé
etc.
Exhaustif, merci !
@Igor Volodin, @Combinator, @Anatoli Kazharski
Je vais commencer par le sujet douloureux).
La question qui me préoccupe le plus est une sorte d'universalité/abstraction pour le stockage des paramètres de rendu.
----
Comme nous l'avons compris, tous les contrôles utilisent de la même manière la police, la couleur de fond et la couleur du texte, etc.
Lorsque tous ces paramètres sont les mêmes pour tous les contrôles, l'interface a un aspect commun avec un concept unique.
Mais comment les stocker ? car les contrôles n'utilisent pas toujours tous les paramètres.
+ Le système est compliqué par le fait que les éléments ont des états différents qui doivent utiliser différemment la police et les couleurs de fond. Il s'agit de Active, Disable, Over, ou Select, etc.
+ il y a des groupes de contrôleurs - relief (comme Button) et champs d'entrée (comme Edit, List), et quand est le fond pour les rendre
----
Dans l'idée de travail actuelle, j'ai un élément d'attribut minimum de la classe GAttribBase, qui contient 5 paramètres de base (police/taille, couleur d'arrière-plan/de bordure, taille de la bordure).
Ces éléments de base sont utilisés pour former un tableau pour les états de la classe GAttributribut(Active/Disabvle/Over/Select, etc.).
Et ensuite, GAttribut est alimenté pour les différents types d'éléments - Relief, Editable, etc.
Ainsi, nous remplissons les paramètres de rendu une seule fois (nous les stockons en xml), ils peuvent être modifiés afin de créer différents designs et nous les utilisons globalement sans les définir pour chaque contrôleur.
Bien sûr, si un contrôleur doit avoir ses propres paramètres de rendu définis - il suffit de créer votre propre objet GAttributribut dans le contrôle et de spécifier les couleurs souhaitées.
----
Ce modèle fonctionne, le design unifié est atteint en un rien de temps, toutes les commandes prennent les couleurs du tableau commun.
Mais à mon avis, ce n'est pas universel. L'utilisateur ne comprend pas quels paramètres de la base GAttribBase sont utilisés pour le rendu de tel ou tel contrôle.
Pour que le codeur sache exactement quelle couleur changer, il devrait examiner la fonction de rendu du contrôle, ce qui est vraiment gênant.
-----
Quoi qu'il en soit, avez-vous des idées pour que le codeur soit libéré de la gestion des couleurs (pour utiliser immédiatement des couleurs prédéfinies et ne pas s'en préoccuper au début) ?
D'autre part, s'il veut recolorer certains des contrôles à l'écran, il n'a pas besoin de chercher à savoir quel GAttribBase est utilisé et dans quel cas.
@Igor Volodin, @Combinator, @Anatoli Kazharski
En général - quelles sont les idées pour que le codeur soit libéré du travail sur les couleurs d'une part (pour qu'il utilise immédiatement les couleurs posées et ne s'en préoccupe pas au début).
Et d'autre part, s'ils veulent recolorer certains des contrôles à l'écran, ils peuvent le faire sans entrer dans le dédale des fonctions de dessin et chercher quel GAttribBase est utilisé et dans quel cas.
Ok, les thèmes.
Par exemple, l'objet principal de notre application, appelons-le App, est associé à l'objet ConcreteTheme.
Qu'est-ce qu'un objet thématique ?
couleurs (arrière-plan, premier plan, désactivé, actif, etc.), tailles de base, tailles de police pour les cas standard : titlesize, commonsize, etc. sprites pour : panneaux, boutons, cases à cocher, etc.
Un nouveau thème est une nouvelle classe/structure avec des valeurs modifiées. Mais il est préférable que les thèmes puissent être hérités en ne surchargeant que certains paramètres.
Le reste - la hiérarchie des contrôles dans laquelle chaque contrôleur utilise par défaut une des valeurs nécessaires de l'objet-thème. S'il doit passer outre, nous appelons une méthode pour travailler avec cette propriété, en spécifiant la nouvelle valeur.
Par exemple, SetBgColor(XRGB(255,0,128)) ;
CView - une classe de base fournissant une interaction de base basée sur des événements
- CRect - coordonnées
- Cpanel a un bgcolor
- CButton a un objet d'état, chaque état a un bg.
- CText possède une couleur de texte et des propriétés de police.
- CCircle
Et ainsi de suite.
Si vous voulez utiliser du xml pour décrire les éléments,
ensuite, pour chaque contrôle ou primitive de classe, nous devons créer une classe génératrice, appelons-la "build-container", qui fera correspondre les attributs (bgcolor="(255,0,128)") aux méthodes correspondantes ( SetBgColor(attrValue)) de la classe. Ces conteneurs de construction seront analysés par un analyseur XML, la sortie sera un objet initialisé avec les valeurs nécessaires, ou avec les valeurs par défaut si aucune valeur n'a été spécifiée.
Ce thème est le même que le mien - un ensemble de GAttributeurs pour différents types de contrôles et leurs états.
mais vous avez déjà suggéré la première étape sur la voie de la transparence pour le codeur - ajouter des fonctions à un contrôle spécifique pour modifier ses propriétés de rendu (SetBgColor, etc.).
Sur le fond, je suis d'accord, il sera clair quelles couleurs il a et ce qui peut être changé.
Une telle question alors - Thème implique-t-il la redondance des paramètres inutilisés ?
Disons que dans ma GAttribBase de base, pour un certain contrôle (par exemple un bouton), nous n'utilisons que la couleur et la taille de l'arrière-plan, et que les autres paramètres (épaisseur de la bordure, etc.) ne sont pas utilisés dans ce contrôle.
En d'autres termes, avez-vous un élément de base pour tous les contrôles ? Où est stockée l'information "pour tous les cas", ou tous les contrôles n'ont que leurs paramètres sans la surcharge d'universalité ?
...
En général, quelles sont vos idées pour que, d'une part, le codeur ne soit pas obligé de travailler avec les couleurs (il utiliserait immédiatement les couleurs par défaut et ne s'en préoccuperait pas au début) ?
Et d'autre part - pour que, s'il veut recolorer un contrôleur à l'écran, il n'ait pas à se plonger dans les contrées sauvages des fonctions de rendu et à trouver quel GAttribBase est utilisé et dans quel cas.
Définissez les valeurs par défaut pour chaque élément. Si l'utilisateur a besoin de changer quelque chose, pour chaque propriété de l'élément, il devrait y avoir une méthode pour définir la nouvelle valeur. C'est comme ça que je le fais maintenant.
Je ne l'ai pas encore :
Mais tout ceci est mon raisonnement concernant mon schéma. Je n'exclus pas qu'elle change encore beaucoup lorsque je commencerai la transition. Ainsi, tout ce que j'ai écrit ci-dessus peut ne plus être pertinent pour le sujet discuté ici. )