UN JOLI BOUTON !
Bacterius
Messages postés
3792
Date d'inscription
samedi 22 décembre 2007
Statut
Membre
Dernière intervention
3 juin 2016
-
14 sept. 2009 à 15:11
Dark_Side Messages postés 7 Date d'inscription mardi 3 février 2004 Statut Membre Dernière intervention 30 mars 2004 - 16 févr. 2012 à 18:58
Dark_Side Messages postés 7 Date d'inscription mardi 3 février 2004 Statut Membre Dernière intervention 30 mars 2004 - 16 févr. 2012 à 18:58
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/50563-un-joli-bouton
https://codes-sources.commentcamarche.net/source/50563-un-joli-bouton
16 févr. 2012 à 18:58
Bon compo, bien zoli.
Seul hic, y'a pas les 'anchors' pour attacher les boutons aux bords des fiches.
23 janv. 2012 à 20:12
9 nov. 2009 à 09:46
Cordialement, Bacterius !
9 nov. 2009 à 09:42
Je ne programme pas qu'en temps qu'amateur, et ce n'est pas à toi que je vais l'apprendre, la conception prend du temps, énormément de temps... Et bien évidement, les clients passent avant tout autre chose ;).
Si tu avais jeté un oeil sur mon site web, tu aurais su ce qu'il en est...
Mais sache que je ne t'oublie pas...
Certains auteurs n'aiment apparement pas être dérangés, puisqu'il ne répondent pas à mes mails (je parle au sens général), ce qui me retarde également...
Mais promis, j'essaie de faire mon maximum!
Cordialement
Florent
9 nov. 2009 à 06:59
Cordialement, Bacterius !
19 oct. 2009 à 14:03
Et le procès, c'était un exemple de "conséquence", je n'ai aucune l'intention d'en faire un ...
J'attends les modalités, pour faire ça dans les règles.
Cordialement, Bacterius !
19 oct. 2009 à 14:00
Je pense donc qu'on ne c'est pas compris, moi mal exprimé, c'est sûr je viens de relire mon message, et toi idem, avec la menace du procès, qui m'as fait un peu cogiter, car je pensais que tu parlais pour toi.
Mais je te rassure tu n'es pas le seul, sans doute me suis-je mal exprimé à chaque fois ???
Pour l'instant je ne publirai donc rien ...
Je t'enverrai un MP dans quelques temps avec toutes les modalités exactes, pour bien voir où l'on va!
Merci de ta compréhension, vraiment
Florent
19 oct. 2009 à 13:48
- dans ton premier message, tu parles "d'intégrer" les composants à ta librairie
- je te réponds oui : un accord basé sur ce que tu as dit est en quelque sorte signé
- dans ton prochain message, tu parles de "porter" ces composants dans ta librairie
- je te réponds attention, je n'ai pas signé pour "porter" mais pour "intégrer".
Dans mon cas, je suis tout à fait d'accord dans les deux cas (intégrer ou porter) mais j'essayais simplement de t'avertir des conséquences que ça pourrait avoir si tu le fais "dans la vraie vie". Maintenant, si tu ne sais pas concevoir ça ...
Cordialement, Bacterius !
19 oct. 2009 à 13:40
Cordialement, Bacterius !
19 oct. 2009 à 13:34
19 oct. 2009 à 13:08
Et merci pour l'astuce sur le TImageList, je ne la connaissais pas et j'avais remarqué ce bug (pas de vraie liaison entre la liste d'images et le contrôle bouton).
Cordialement, Bacterius !
19 oct. 2009 à 10:45
La librairie n'est cependant pas encore prête, fin du mois ou courant novembre sans doute .... Concernant ton SmoothButton, il y a un bug lorsqu'on supprime le TImageList sans l'avoir déréférencé dans le bouton... Il faut ajouter une procedure du type: "procedure Notification(Component: TComponent; Operation: TOperation); virtual;". Lorsque j'ai "porté" ton composant pour ma Lib, je l'ai remplacé par un simple Glyph, mieux adapté à ce genre de composant.
a+
Florent
mon site: http://thegeekman.jimdo.com (rubrique AntarèsVCL)
19 oct. 2009 à 05:29
Cordialement, Bacterius !
14 oct. 2009 à 05:27
Cordialement, Bacterius !
14 oct. 2009 à 03:47
@Florent : oui tu peux intégrer ce composant, et les compos Tangent aussi même si ils sont un peu foireux. Mais si tu pouvais citer mon nom et le site de delphifr, j'en serais reconnaissant :) Et merci pour le bug visuel, je pense que ça se limite à un "-1" quelque part dans les coordonnées, je vais fixer ça ...
Cordialement, Bacterius !
13 oct. 2009 à 12:30
Florent
13 oct. 2009 à 12:28
il faut quand même que je te le dise ...
le TButton permet aussi l'affichage d'icônes/Bitmaps (5 états) ... eh oui un de plus :D
et on peut aussi s'en servir pour skinner le bouton (toujours 5 états)
le tout se fait très simplement avec une ImageList et des messages (comme pour la StatusBar ^^)
parce que je sais que tu aimes les défis je te laisse chercher tout seul :p
j'en ai déjà dit de trop ... la suite plus tard ... ;)
13 oct. 2009 à 11:58
Autre question, je m'apprète à publier une libraire de composant, sous licence MPL, totalement gratuite pour toute utilisation... Pourrais-je y intégrer tes composants "Angent" ainsi que celui-ci ?
Cordialement
Florent
13 oct. 2009 à 06:55
1er bloc de 4 lignes : quand le bouton est relâché
2eme bloc : quand le bouton est "enfoncé"
1ere ligne de chaque bloc : Désactivé
2eme ligne : Non sélectionné
3eme ligne : Souris dessus
4eme ligne : Souris cliquée
Format des lignes :
Bordure extérieure - Bordure intérieure haut - Bordure intérieure milieu haut - Bordure intérieure milieu bas - Bordure intérieure bas - Dégradé haut - Dégradé milieu haut - Dégradé milieu bas - Dégradé bas.
Cordialement, Bacterius !
13 oct. 2009 à 06:52
Bordure extérieure - Bordure intérieure haut - Bordure intérieure bas - Dégradé haut - Dégradé milieu haut - Dégradé milieu bas - Dégradé bas.
1ere ligne : Désactivé
2eme ligne : Non sélectionné
3eme ligne : Souris par-dessus
4eme ligne : Souris cliquée dessus
Note qu'il y a sûrement encore du boulot à faire du côté de la gestion de la souris ?
Cordialement, Bacterius !
12 oct. 2009 à 15:23
Très joli composant, félicitation. Peux-tu expliquer par contre, dans un petit tutoriel, à quoi corresponde chaque couleur dans le thème Ubuntu, car j'aimerai en faire des persos... j'ai testé un peu, apparement les premières couleur sont celles du bord, mais on s'y perd vite ....
Et pourquoi pas une petite application pour faire des thèmes ?
Cordialement
cineon
24 sept. 2009 à 14:04
Cordialement, Bacterius !
24 sept. 2009 à 09:43
Cordialement, Bacterius !
24 sept. 2009 à 08:31
Cordialement, Bacterius !
23 sept. 2009 à 18:04
o_O
23 sept. 2009 à 12:56
23 sept. 2009 à 12:53
- Transformation du bouton vers un TCustomControl plutôt qu'un TGraphicControl.
Ce n'est qu'une étape, car
Comment faire danser les claquettes à mon Avatar en 3D sans ergonomie?
Salut, Cordialement, A+, Nic
23 sept. 2009 à 10:33
Cordialement, Bacterius !
23 sept. 2009 à 10:32
LES PLUS :
- Transformation du bouton vers un TCustomControl plutôt qu'un TGraphicControl. Ca permet une gestion de la focalisation ! (gestion du Tab, de la touche Entrée, ...)
- De nombreux bugs, concernant principalement la gestion des états du bouton (FState, FIsDown, FUseDown ... tout cela prêtait à confusion).
- Le thème Ubuntu est complètement mis à jour et terminé graphiquement (j'avais fait une petite confusion) et fonctionne m aintenant. D'ailleurs, le système de dessin est légèrement modifié pour l'occasion.
LES MOINS :
- J'ai perdu tous les autres thèmes que Ubuntu ... mais je les remettrai bientôt, avec d'autres :)
___________________
L'exemple est mis à jour, ça ressemble vraiment à Ubuntu maintenant avec les boutons :p
Cordialement, Bacterius !
22 sept. 2009 à 21:09
J'aimerais bien que l'on trouve un moyen de voir un périphèrique comme un bloc de mémoire au lieu de considérer des fichiers, même à accès direct. Mais il faut mesurer le danger commercial à y mettre du silicium. (Les subventions des vaches à lait proviennent peut-être des impots de l'essence des tracteurs du fourrage). On peut aussi trouver un compromis de structure englobant la notion de fichier. Un convertisseur analogique, par exemple, serait plus souple et plus compact. Seul un travail laborieux pourrait nous le confirmer. Le développement en langue maternelle permettrait peut-être de développer la coopération. Celà existe peut-être déjà mais je n'ai pas envie d'attendre la prochaine guerre (avec la remise à zéro des privilèges intellectuels) pour l'apprendre.
A+ Nic
22 sept. 2009 à 20:23
Je ne connais rien au language C, et j'y ai renoncé suite à Scanf, mais puisque j'ai cru comprendre que les fournisseurs se sont entendus pour produire unanimement les pilotes dans ce language, je prends ma première leçon dès ce soir.
Il ne s'agit pas de faire mieux: Si ça existe en C, je serais ravi de ne pas les faire. Simplement je voudrais quelque chose de moins adapté et plus général pour voir évoluer les gestionnaires de périphèriques: ma mémoire Flash remplace le disque dur et elle est gérée virtuellement comme tel.
Je voudrais en profiter pour refaire la gestion des fenêtres en m'inspirant de OpenGl et xaml à patir de l'encapsulation asynchrone de gestion de la souris controlé par un timer.
Le défaut du bitmap concerne le décalage entre la gestion des icones par le système Windows à fenêtre et celui du Framework.
Cordialement A+, Nic
22 sept. 2009 à 19:37
S'il fallait trouver un responsable historique, je dénoncerais plutôt les inventeurs du langage C, avec le type FILE* qui a imposé ce modèle de gestion uniformisée des périphériques lors de l'écriture des premiers OS. Compatibilité oblige, les versions suivantes ont repris le même principe. Ceci dit, à ce bas niveau d'écriture, il me semble que ça reste assez proche du fonctionnement physique d'un périphérique: on lui transmet des données et il nous en envoie.
En ce qui concerne la gestion des listes, le C++ avec sa STL est pas mal: il y a des types de données et des algos adaptés à pas mal de cas. Mais il est vrai qu'un programmeur laborieux et raisonnablement doué devrait arriver à faire légèrement mieux. Je crois qu'il y a aussi des versions avec des optimisations supplémentaires (librairies Boost) mais je ne suis plus trop au courant.
Au fait je ne comprends pas ce que signifie "Le défaut du bitmap d'origine vise à limiter les préoccupations au plan". Est-ce que tu parles du HBITMAP qui vient de Win 3.1?
22 sept. 2009 à 16:09
J'ai cru longtemps que l'héritage permettrait de passer simplement du clavier/écran/interface semi-graphique au modèle souris/Fenêtre graphique, mais le compilateur voit les périphériques comme des fichiers que les pilotes Windows réservés à des applications commerciales lui accordent en pature comme pour inciter les amateurs à défricher pour son compte.
Nous disposons, Grace à Dos, d'une interface de commande extraordinaire pour nos bases de données. Celle-ci est volontairement limitée pour favoriser l'organisation des informations par magnétisation de surfaces rouillées.
Si nous avions recherché d'autres formes d'archivage, en imbriquant des petites files de bulles de mémoire de façon matricielle, par exemple, le monopole aurait courru le risque de nous voir perfectionner des algorythmes de gestion du tas.
Le défaut du bitmap d'origine vise à limiter les préoccupations au plan. Ce n'est pas pour rien non plus que la gestion des noeuds de listes (1) ou Les algorythmes de synchronisation (2) doivent être re-conceptualisés sans cesse pour chaque cas particulier: Il est inimaginable que personne n'ait déjà défini et clarifié leurs méthodes ou que les primitives d'objets utilisables à chaque couche d'encapsulation n'apparaissent pas "Publics".
Merci Wincrosoft, et comme qui dirait: "On va pas re-inventer la lune". Avec le dictionnaire (mot pour mot) et le treeNode (classement hiérarchique) On peut déjà bien s'amuser.
(1)Tableaux de pointeurs vers le noeud suivant, précédent, antériur et postérieur ainsi que le pointeur d'étiquette et celui de l'objet. Cet Objet comporte généralement un pointeur vers une donnée du tas ainsi que sa taille pour gérer les allocations.
(2) Le petit objet utile à coordonner le curseur dans la ligne de l'éditeur, le texte dans la fenêtre, la fenêtre sur l'écran, la barre de défilement, la position dans le fichier et tant d'autre choses, ce petit objet se complète si bien de lui-même qu'il est difficile d'envisager son remplacement par héritage. La qualité de sa définition limitera dès le départ la version du programme.
A+, Nic
22 sept. 2009 à 07:19
Cordialement, Bacterius !
21 sept. 2009 à 09:59
Ah je n'ai pas envisagé le cas d'un lecteur A: ... je ferai la mise à jour qui evite le problème comme tu le proposes.
J'ai également noté quelques autres bugs liés au bouton (genre le "down" qui foire un peu), je ferai une mise à jour bientôt.
Cordialement, Bacterius !
21 sept. 2009 à 09:51
je viens de tester ton prog, et j'ai une erreur avec
"GetDiskFreeSpaceEx(PChar(Format('%s:\', [L])), DriveFreeSize, DriveSize, nil);"
si je n'ais pas de disque dans mon lecteur A:
pas d'erreur quand j'ai un disque , mais même erreur quand je le retire
:) oui j'ai encore un A
if DriveSize <> 0 then ajouté avant
GetDiskFreeSpaceEx(PChar(Format('%s:\', [L])), DriveFreeSize, DriveSize, nil);
evite l'erreur chez moi
ThemeBox et ApplicationBox ont un fond tout noir ???
le texte des radio boutons est illisible
j'ai D7
je sais ça n'est pas lié a ton zoli bouton (merci pour ça) mais je comprend pas
20 sept. 2009 à 07:23
Cordialement, Bacterius !
PS : si vous avez des idées de thème, n'hésitez pas, il en faudrait plus que deux :p
17 sept. 2009 à 06:22
Et tiens j'ai un autre exemple flagrant : tu crées un programme, avec quelques variables globales (A, B, C: Integer). Delphi gère nativement les variables, en créant et en libérant la mémoire à la place du programmeur (pour les variables simples, genre Integer ou String, pas pour les classes). Tous ceux qui vérifient que @A = nil et qui libèrent la variable si <> nil, levez la main !.
Cordialement, Bacterius !
17 sept. 2009 à 06:18
@Forman : Merci :)
@VoicedMirror : je ne dis pas que ça ne sert à rien ! Je dis que la POO permet de partir du principe (mots mêmes d'un développeur de Delphi, si je me souviens bien) que les opérations vont réussir et non pas échouer, et que si quelque chose échoue, si l'erreur se situe dans les ancêtres de notre composant, elles seront arrêtées et ne se propageront pas. Donc, à priori, sauf si l'on passe en mode API, les try..finally sont rares.
Tu écrirais :
procedure Test(A, B: Integer): Integer;
begin
try
Result := A div B;
finally
on e: EDivideByZeroError do raise Exception.Create('Division par zéro.');
end;
end;
Non, car l'exception est déjà gérée nativement par SysUtils, il est inutile de l'intercepter, d'inhiber le gestionnaire de SysUtils et de mettre le notre par-dessus.
Si tu te mets à tout vérifier, depuis une libération de mémoire (logique) jusqu'à une division par zéro, c'est pas du Delphi, car tu ne tiens pas compte des gestionnaires ancêtres ...
Mais après j'ai peut-être tort. Mais on m'a toujours dit de soutenir mes arguments et de ne pas tomber au premier coup de cannes dans les jambes.
Mais ... désolé encore. Je regrette également que tu l'ais pris de cette façon.
Cordialement, Bacterius !
PS : Bon c'est vrai que j'ai du mal avec les blocs try..finally..except. "Dois-je comprendre le constructeur dans le bloc ? Où va le pointeur d'instruction si il y a une erreur ? Est-ce que la procédure se termine net, ou finit son exécution ? Que se passe-t-il vraiment dans un except ? Comment fonctionne le finally ?"
16 sept. 2009 à 19:54
En tant qu'ex-enseignant en info, j'estime que notre jeune ami Bacterius (16 ans si j'en crois sa fiche) a un bel avenir de programmeur devant lui, et fait preuve d'une maturité de programmeur que peu de monde peut (aurait pu?) revendiquer à son âge. Il lui reste encore pas mal de temps pour apprendre les blocs try...finally. Pour ma part je ne peux que lui conseiller de continuer la prog!
16 sept. 2009 à 19:49
Ceci dit, il est vrai que le modèle de composants de Delphi - s'il est appliqué RIGOUREUSEMENT - supprime la nécessité d'utiliser des blocs d'exception pour libérer la mémoire des champs des objets. Typiquement, si on imagine un composant TMachin (dérivé de TComponent) avec un champ
FBitmap: TBitmap;
qui est créé dans le constructeur, il suffit de mettre
FreeAndNil(FBitmap)
dans le destructeur. Ainsi, si la création du bitmap échoue dans le constructeur (out of memory par ex) FBitmap vaut nil et FreeAndNil(FBitmap) ne fait rien. Si une erreur se produit plus loin dans le constructeur, FBitmap serait libéré car différent de nil. Tout ça parce que Delphi appelle le destructeur si jamais une exception se produit dans le constructeur.
En outre, il y a déjà un équivalent de try...finally dans le programme principal de Delphi qui détruit l'objet Application. Et du coup, ça détruit toute l'arborescence de composants derrière (puisque Application est Owner de toutes les TForm, puis les contròles, et ainsi de suite). Idem si on met Action:=caFree dans le OnClose d'une fiche, qui détruit toute l'arborescence à partir de la fiche. Évidemment, ça suppose de ne jamais créer de composants avec Owner=nil (ou alors faire FreeAndNil dans un destructeur comme plus haut).
Sans vouloir ouvrir le champ aux réflexions trollesques sur quel langage est le plus mieux, il faut quand même reconnaître que Delphi a une architecture qui est propice à l'économie des hommes-mois (et les semaines-femmes, ça marche aussi? :-P) Mais bon, comme toujours, ça implique de respecter les règles et conventions implicites du langage. Le problème, c'est que contrairement au C++ par exemple où les règles et conventions sont beaucoup plus universelles et codifiées dans une vaste littérature ainsi que dans les cours donnés à la fac ou en école, l'enseignement du Delphi n'a pas bénéficié d'une telle uniformisation donc chacun applique ses conventions propres, parfois non interopérables entre elles voire avec celles imaginées par les concepteurs de Borland...
16 sept. 2009 à 06:53
Cordialement, Bacterius !
16 sept. 2009 à 06:52
Sinon merci pour m'avoir guidé sur les limites d'affichage. Je vais surcharger la WndProc avec WM_RESIZE :)
Et pas bête pour le TCustomImageList et pour le nom, j'avais même pas fait attention :s
J'ai l'intention de développer une suite "thèmée" qui reprend tous les composants Delphi standard, et qui va les refaire avec un bô dégradé.
@VoicedMirror :
- si il fallait mettre des try..except à chaque allocation de mémoire ... on ne s'en sortirait plus. L'intérêt de la POO c'est que le développeur peut partir du principe que ça va marcher. Ici, le système Delphi nous garantit que la création/libération du bitmap ne peut échouer que si la mémoire est épuisée. Et entre nous, le gestionnaire de mémoire Windows fait en sorte d'écraser la mémoire des processus qui tournent au minimum, donc en gros on est très rarement à court de mémoire lors d'une utilisation normale du PC. Mais ... je vais les ajouter si tu veux :]
- le TImageList ... moi je le trouve très bien conçu. Il permet de gérer des listes d'image, sans avoir à se préoccuper des "array of TBitmap" insupportables à gérer. Et ça annule un problème supplémentaire pour la gestion d'un objet TBitmap si l'on ne passait pas par une TImageList.
- pour le niveau initié ... c'est vrai ... mais là on va passer aux choses sérieuses ... j'ai l'intention de faire la TSmoothCheckBox, TSmoothMainMenu, TSmoothPopupMenu, TSmoothRadioButton, TSmoothRadioGroup, TSmoothGroupBox. :)
Cordialement, Bacterius !
15 sept. 2009 à 17:46
Je n'aime pas trop non plus ça:
if Height < 5 then Height := 5;
pendant le réaffichage. Il y a des méthodes Delphi à surcharger pour ça (par exemple Resize ou une autre dont je ne me souviens plus du nom qui gère les TSizeConstraint lors du redimensionnement).
Personnellement j'aime bien le principe d'utiliser une TImageList pour gérer les différents états. En plus d'être pratique, c'est un plus conceptuellement, puisque les TCustomImageList peuvent être héritées, par exemple pour les virtualiser (c'est à dire que la liste d'images peut être procédurale, plutôt que stockée dans un bitmap statique). Par exemple, pour implémenter un support de thèmes sans trop se fatiguer, tu peux faire un descendant de TCustomImageList qui va chercher des images en ressources d'une DLL (et de ce fait, changer le thème en chargeant les ressources depuis une autre DLL). D'ailleurs, si je peux me permettre un conseil, je déclarerais la propriété ImageList de ton composant comme étant de type TCustomImageList pour autoriser des listes d'images non standard (ça augmente l'ergonomie et ça ne demande aucun travail supplémentaire). Personnellement, je l'aurais même plutôt appelée "Images" pour éviter la confusion avec le type du même nom.
Sinon c'est très joli :-)
14 sept. 2009 à 15:11
Cordialement, Bacterius !