Discussion :

[Invité]

Bonjour,

je cherche à réaliser un composant TTimePicker [ma classe s'appelle TimeEdit... j'ai réussi à réaliser un TTimeEdit en dérivant un TEdit TTimeEdit = class(TEdit)]. Et donc j'ai voulu améliorer mon approche à partir de ce code.

Le composant sera constitué d'un TEdit, d'un TSpeedButton et d'une petite StringGrid (les 2 premiers visibles en permance et le 3ème visible à la demande). Fonctionnement comme un TDatePicker : on clique sur le SpeedButton. La StringGrid apparaît, on y choisit les heures, les minutes et les secondes. J'ai un code équivalent dans une Form qui fonctionne à partir des 3 éléments séparés... Donc j'aimerais intégrer l'ensemble dans un unique composant...

Pour l'instant, j'obtiens quelque chose comme :


S'agit-il d'un problème de déclaration puis de création ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
type
  TTimeEdit = class(TEdit)
  private
    FButton: TSpeedButton;  [...]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
constructor TTimeEdit.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  FButton := TSpeedButton.Create(Self); [...]

Je cherche une documentation (élémentaire) claire expliquant comment incorporer dans un même composant plusieurs éléments visuels comme SpeedButton, StringGrid... J'ai bien trouvé des exemples de création de composants visuels mais je n'arrive pas à transposer... En réalité, il s'agit en général de la description du composant mais pas des techniques sous-tendues pour le réaliser... et c'est ce que je cherche.

Merci. Cordialement.
Gilles

[pomalo]

bonjour

peut être que ton parent est pas bon car il me semble que t'essaie de mettre un speedbouton dans un tedit

faudrai l'avis d'un specialiste des composants graphiques

cordialement
claude

[Invité]

Bonjour,

Je me suis demandé un moment, s'il ne fallait pas déclarer 2 voire 3 "type"... a moins qu'il ne faille prendre un autre héritage au départ...

Je veux arriver à ce qui est en dessous qui fonctionne en code simple dans la Form... "Cela" gère les heures_24 ou les heures_12 (AM,PM), l'absence ou non de secondes, la création et l'affichage dynamique de la StringGrid (taille, position), son ouverture par le SpeedButton, sa fermeture par le choix des minutes (ou des secondes selon le cas),
J'utilise des variables

• iHourSelected, iMinSelected, iSecSelected (qui seraient protected)
• b12 (12 ou 24), bSec (secondes ou pas), 4 variables Tcolor qui seraient published (la gestion des couleurs serait la bienvenue)...
• un tspeedButton et une StringGrid et des variables de tailles et de positions

Dans un premier temps, il m'a semblé que l'héritage d'un TEdit était naturelle... Les propriétés b12 et bSec sont faciles à intégrer. Mais dans ce cas comment rajouter par exemple dans le composant, le choix de l'image du SpeedButton et la possibilité de choix des couleurs de la StringGrid ?

Bref, la structure des composants utilisant plusieurs objets visuels dont on peut modifier certaines propriétés pour chacun d'eux reste, en ce qui me concerne, un mystère au niveau structurel... "Certaines", car par exemple, il est hors de question de modifier la position du TSpeedButton qui par calcul reste aligné sur le TEdit ou celle de la StringGrid qui est calculée aussi. D'ailleurs à ce sujet, est-il possible avec un Composant de modifier dynamiquement la position de celle-ci : si en bas de l'écran, alors la StringGrid s'ouvre au-dessus du TTimePicker... Pour cela, il faut connaitre la taille de la fenêtre... à partir du composant... Idem pour droite (on aligne le bord droit de la StringGrid avec le bord droit du TSpeedButton)...

Evidemment cela pénalise lourdement le code de ma Form d'autant que j'ai 3 "TTimeEdit" à gérer dans celle-ci... Ce qui "m'agasse" c'est que le code est facilement réalisable dans la Form mais que l'agréger dans un composant soit si "délicat" : comme je l'ai déjà écrit, on trouve "j'ai fait ça (et ça marche)" mais jamais on ne trouve "Pour faire cela il faut (on peut) utiliser cette méthode car..." (sauf pour des comosants basiques visuels ou non). De plus l'approche Delphi semble souvent ne pas fonctionner.

Pour prendre une image triviale, c'est un peu comme si pour résoudre un système de deux équations du premier degré à 2 inconnues ayant pour solution deux chiffres entiers, j'essayais de résoudre au hasard ou de manière construite par itération par exemple (0,0), (0,1)...(9,9)... sans que personne ne me "conseille" la méthode de résolution par substitution, par combinaisons linéaires ou par les déterminants... Et s'il n'y a pas de solution ? On en revient à une vieille discussion sur les limites du "mimétisme simple" comme méthode pédagogique...

Evidemment, je pourrais regarder de près le code du TDatePicker et le mimer... et il faudra recommencer la prochaine fois ? Et s'il n'y a pas de modèle ?

Alors, un spécialiste composant pourrait-il m'indiquer (une doc) les principes de base adaptés à mon problème ?

Cordialement. Gilles

[yann.m]

bonjour

A mon avis le problème viens du fait que tu utilise plusieurs composants visuels qui ont besoin de communiquer entre eux (ce que tu arrive apparemment à faire via une TForm).

La solution la plus simple serait d'utiliser un TCustomPanel comme classe ancêtre de ton composant visuel.

Tu override ensuite les contructor/destructor pour ajouter tes composants à celui-ci (TEdit etc...) et tu ajoute tout ce dont tu as besoin comme procedure/function/property pour gérer tes objets au sein de ton composant.


ex :fichier moncomposant.pas

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
 
 
unit MonComposant;
 
...
 
interface
 
uses
  ...
 
type
 
 
  TMonComposant = class(TCustomPanel)
 
 
  private
      { private declarations }
      // objets
      MonEdit: TEdit;
      // procédures privées
      procedure MonEditOnChange(Sender: TObject);
 
 
  public
      { public declarations }
 
      constructor Create(AOwner: TComponent); override;
      destructor Destroy; override;
 
  published
      { published declarations }
 
      ...
 
  end;
 
 
implementation
 
 
{ private declarations }
 
 
procedure TMonComposant.MonEditOnChange(Sender: TObject);
begin
    // faire qqchose...
end;
 
 
 
{ public declarations }
 
 
 
constructor TMonComposant.Create(AOwner: TComponent);
begin
    inherited Create(AOwner);
    // créer/ajouter objets une fois le parent TMonComposant créé
    MonEdit := TEdit.Create(Self); // self = le composant lui-même, soit un TCustomPanel
    MonEdit.Parent := Self;
    MonEdit.OnChange := @MonEditOnChange; // le TNotifyEvent vas ici déclencher la procédure interne "TMonComposant.MonEditOnChange(Sender: TObject);"
    ... 
end;
 
destructor TMonComposant.Destroy;
begin
    // libérer objets/ressources si besoin avant la destruction du parent
    // les objets crées sous la forme "unobjet.Create(Self);" son automatiquement détruits par leur parent (ici le TMonComposant) lorsque celui-ci est détruit
    // inutile donc de faire des MonEdit.Destroy; ou MonEdit.Free;
    // par contre un objet de type "MonImage := TBitmap.Create;" devrait bien être libéré ici sous la forme "MonImage.Free;"
    ...
    inherited Destroy; 
end;
 
 
 
end.

ajouter le nouveau composant à une TForm par ex :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
 
 
unit Unit1; 
 
{$mode objfpc}{$H+}
 
interface
 
uses
  ...
  MonComposant,
  ...
 
type
 
  { TForm1 }
 
  TForm1 = class(TForm)
      procedure FormCreate(Sender: TObject);
 
  private
    { private declarations }
 
  public
    { public declarations }
  end; 
 
var
  Form1: TForm1;
  Composant1: TMonComposant;
 
implementation
 
{ TForm1 }
 
procedure TForm1.FormCreate(Sender: TObject);
begin
    Composant1 := TMonComposant.Create(Self); // Self = la Tform
    Composant1.Parent := Self; // ajoute donc le composant directement à la TForm
end;
 
initialization
  {$I unit1.lrs}
 
end.

Bon j'ai écrit le code à la barbare il peut y avoir des erreurs, mais c'est pour te faire une idée générale sur le principe.
A toi d'écrire tout le code nécéssaire pour gérer tes obets
Les propriété de l'ancêtre TCustomPanel ne sont ici pas masquées, donc tu peux les utiliser sous la forme "Composant1.Align := alClient;"

Bon courage

ps: Chris37 à réalisé des tutoriaux sur ce sujet, je t'invite à aller jeter un coup d'oeil à son site s'il existe toujours

[Invité]

Merci,

Je vais essayer de suivre cette piste... Ce qui me laisse perplexe, c'est que j'ai examiné le code d'un composant Delphien qui semble intégrer un Tedit et un SpinButton... avec une structure qui ressemble à celle que j'ai tenté d'utiliser. Je ne sais pas si le composant fonctionne : je n'ai plus de Delphi installé sur mes postes depuis un bon bout de temps...

Hormis les tutos de Chris -si je les (re)trouve-, je vais certainement me résoudre à regarder de près le code d'un composant utilisant plusieurs éléments visuels... Mais je me fais peu d'illusions sur la réussite d'une telle approche.

Sinon avec une programmation classique dans la Form, le TEdit, le Button, la StringGrid et mes 2 TLabels maintenant ( http://www.developpez.net/forums/d97...edit-autosize/) ne posent pas de problèmes particuliers... sauf que comme je le mentionnais, il y a du code un peu partout... et il me faut l'équivalent de 3 "composants". Il me reste quand même à finaliser l'approche des bords (placement de la StringGrid)... C'est vrai qu'au pire, il y a la solution proposée par Tintinux... Mais je persiste à essayer de comprendre cette approche composant...

Encore une fois, merci.
Cordialement.
Gilles.

[yann.m]

Hormis les tutos de Chris -si je les (re)trouve-, je vais certainement me résoudre à regarder de près le code d'un composant utilisant plusieurs éléments visuels... Mais je me fais peu d'illusions sur la réussite d'une telle approche.

Et pourtant c'est loin d'être insurmontable. Si tu es capable de gérer plusieurs objets dans une TForm, pourquoi ne pourrait-tu pas le faire au sein d'un autre objet parent ? La logique et la hiérarchie sont identiques...

Le plus simple est de suivre un tuto pour se faire la main avant.

[matthius]

Bonjour !

Je suis l'auteur de ces articles :
http://lazarus.developpez.com/cours/...ad-freepascal/
http://lazarus.developpez.com/cours/...emier-exemple/

Bonne lecture !

[Invité]

Bonjour,

Pourquoi pas l'ouverture d'une Form en effet... Il faut que je regarde si c'est compatible avec ma méthode de gestion perso des Forms.

Pour la documentation, il y a un autre problème, c'est l'obsolescence de certains articles....

Pour gérer proprement les accès aux articles, il faut une base de données et des descripteurs. Le problème, même si je reconnais la bonne volonté des rédacteurs, c'est qu'avant d'écrire, il faut créer le cadre qui permet d'utiliser le contenu... La plupart des CMS sont mauvais à ce niveau... A mon avis, actuellement, compte-tenu du nombre d'articles et d'éléments disponibles, pour accéder de manière pertinente aux données, il faudrait "investir" le temps disponible dans une BDD avec descripteurs (thesaurus) et un logiciel ou composant (développé en Lazarus ) librement diffusable évidemment. Car je ne suis pas persuadé, même en utilisant des techniques "ajaxiennes", qu'un site Web soit capable de rivaliser à investissement égal avec ce type d'application... Ensuite, il resterait à intégrer ce genre de "composant" dans l'IDE

Je considère la question posée comme résolue... Le composant est fonctionnel. Evidemment, il reste très perfectible. Merci pour votre aide.

Cordialement. Gilles.