Discussion :

[Rayek]

Juste comme ça....
Est ce que par hasard, il n'y aurait pas non plus des TActionList dans les fiches ? (ce qui expliquerais le côté "double action", peut-être)

Sinon, vous ouvrez tous les .dfm et .pas et vous remplacez tous les "TLMDSpeedButton" que vous trouverez par "TButton". Il restera à enlever dans les dfm, les quelques propriétés restées en trop et hop.
Vu le peu de temps que ça devrait prendre avec une moulinette "maison", ça vaudrait le coup de tester cette solution. Pensez à faire ça sur une copie du code, au cas où vous auriez besoin de revenir au code original !

Si cela avait été possible, je ne serais pas la à demander le fonctionnement des Class Helper .
On a GExpert sur nos machines donc le changement de compo n'est pas vraiment un problème si on pouvait le faire.

[LadyWasky]

A la rigueur... j'aurais une autre idée à vous soumettre, à cet après midi.

[sjrd]

@Franck : je pensais qu'il n'y avait que moi pour faire ce genre de trucs basés sur une le modèle objet de Delphi. Mais là quand même, c'est carrément pourrir le côté OO des choses Je trouve ça un peu exagéré. Mais c'est drôle à voir quand même

Pour ceux qui pensaient utiliser un class helper, vous confondez class helper et classe partielle (existe en Ruby par exemple). Un class helper permet uniquement d'ajouter des identificateurs supplémentaires à la liste de résolution d'un champ (au sens large : peut être méthode/propriété/type interne/etc.) de la classe "helpée". Elle ne permet en aucun cas de modifier la classe (donc ne peut modifier ni la VMT, ni la DMT - ce qui implique pas de override -, ni la InstanceSize - ce qui implique pas de champ supplémentaire). C'est pas la même chose.
De plus, les méthodes déclarées dans le class helper n'apparaissent pas dans les RTTI de la classe, même avancées.

Pour les appels de méthode héritée, ils sont effectivement tous résolus de façon statique (que ce soit pour virtual, dynamic ou message). Encore heureux ! Ce serait vraiment une bien mauvaise implémentation si c'était dynamique.

[Franck SORIANO]

@Franck : je pensais qu'il n'y avait que moi pour faire ce genre de trucs basés sur une le modèle objet de Delphi. Mais là quand même, c'est carrément pourrir le côté OO des choses Je trouve ça un peu exagéré. Mais c'est drôle à voir quand même

En fait ce n'est pas si pourri que ça.
C'est le principe d'un autre paradigme de programmation : La programmation orientée aspect (AOP).
L'usage le plus classique c'est par exemple d'ajouter une couche de tracing dans une application existante. Au lieu d'allourdir le code partout dans l'application pour instrumenter chaque méthode et générer la trace, tu programmes un aspect qui ajoute automatiquement le code de traçage au début et à la fin de chaque méthode, sur toutes les classes de l'appli...
Après l'implémentation.... de toute façon ça ne marche pas

[LadyWasky]

lors d'un double clic sur ceux-ci, le TLMDSpeedButton exécute deux fois

En même temps, c'est normal, c'est un speedbutton
Il prend en compte 2 clics d'affilés, donc déclenche l'évènement associé 2 fois.

Sur ces choses là, il faut cliquer qu'une seule fois, ou blinder le code déclenché pour qu'il désactive aussitôt sec le speedbutton appelant.
Si ce que j'entrevoie est juste, un "triple-clic" déclenchera 2 fois plus de violation d'accès

Bon, le truc, c'est de faire une unité à part du style unit_trucmuche, dans lequel vous redéclarez TLmDSpeedButton façon ce qu'on a fait avec lecode que je vous ai donné en tout premier :

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
unit Unit_trucmuche;
 
interface
 
uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls, Unit_LMD; //<-- me souviens plus du nom de l'unité où est déclaré TLMDSpeedButton, donc bon, on va dire qu'elle s'appelle comme ça.
 
type
  TLmDSpeedButton = class(StdCtrls.TLmDSpeedButton )
    procedure Click; override;
  end; 
 
 
 
implementation
 
{ TButton }
 
procedure TLmDSpeedButton.Click;
begin
  enabled:=false; //empêche un double-clic pendant que le premier clic s'exécute encore, je pense que c'est ça qui déclenche les violation d'accès
  inherited;
  enabled:=true;
end;

Puis dans toutes les fiches, vous rajoutez l'unité unit_trucmuche en fin des uses.
ça devrait le faire ou il n'y a plus rien à faire

[Rayek]

En même temps, c'est normal, c'est un speedbutton
Il prend en compte 2 clics d'affilés, donc déclenche l'évènement associé 2 fois.

Sur ces choses là, il faut cliquer qu'une seule fois, ou blinder le code déclenché pour qu'il désactive aussitôt sec le speedbutton appelant.
Si ce que j'entrevoie est juste, un "triple-clic" déclenchera 2 fois plus de violation d'accès

Bin oui
Mais bon moi j'y peux rien sur le choix des boutons, l'application à plus de 10 ans et j'ai pas vraiment le choix ...

[code]unit Unit_trucmuche;

interface

uses
Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
Dialogs, StdCtrls, Unit_LMD; //<-- me souviens plus du nom de l'unité où est déclaré TLMDSpeedButton, donc bon, on va dire qu'elle s'appelle comme ça.

Code :

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

1
2
3
4
type
  TLmDSpeedButton = class(StdCtrls.TLmDSpeedButton )
    procedure Click; override;
  end;

Je n'ai pas encore eu le temps de tester mais j'ai une remarque :

J'ai du mal à comprendre le StdCtrls.TLMDSpeedButton, cette classe n'appartient pas à StdCtrls donc ca ne va pas compiler ?
Est ce que je ne devrais pas mettre plutôt l'unité où se trouve le TLMDSpeedButton ?

[chaplin]

Je n'ai pas encore eu le temps de tester mais j'ai une remarque :

J'ai du mal à comprendre le StdCtrls.TLMDSpeedButton, cette classe n'appartient pas à StdCtrls donc ca ne va pas compiler ?

- Exact

Est ce que je ne devrais pas mettre plutôt l'unité où se trouve le TLMDSpeedButton ?

- Oui, c'était le principe qui était exposé pour TButton , il faut déclarer l'unité dans laquelle se trouve la classe TLMDSpeedButton.

[Rayek]

Ok merci, dès que je peux je teste çà

[LadyWasky]

Oui, c'était le principe qui était exposé pour TButton , il faut déclarer l'unité dans laquelle se trouve la classe TLMDSpeedButton.

Bien rectifié. Il y a des heures on ne sait plus trop ce qu'on écrit !

[sjrd]

En fait ce n'est pas si pourri que ça.
C'est le principe d'un autre paradigme de programmation : La programmation orientée aspect (AOP).
L'usage le plus classique c'est par exemple d'ajouter une couche de tracing dans une application existante. Au lieu d'allourdir le code partout dans l'application pour instrumenter chaque méthode et générer la trace, tu programmes un aspect qui ajoute automatiquement le code de traçage au début et à la fin de chaque méthode, sur toutes les classes de l'appli...
Après l'implémentation.... de toute façon ça ne marche pas

Effectivement, présenté comme ça...

C'est vrai que l'AOP est un concept que je n'ai pas encore eu l'occasion d'approcher, bien que je connaisse vaguement le principe.

[Paul TOTH]

Oui, donc c'est très limité, il me semblait bien aussi

c'est juste qu'il faut comprendre à quoi ça sert et pourquoi ça a été créé

en gros un class helper permet d'ajouter des méthodes statiques à une classe, sans avoir à modifier la déclaration de la classe.

ça a été créé pour ajouter des méthodes aux classes .Net qu'on ne pouvait pas modifier.

c'est possible car une méthode statique est résolue à la compilation...il n'y a donc pas de différence entre cette méthode et une simple procédure ayant une classe objet comme paramètre.

[BuzzLeclaire]

Bonjour à tous,

Est-ce que ces classes Helper pourraient éventuellement être utilisées pour gérer les exceptions ?

@Merci

[Paul TOTH]

Bonjour à tous,

Est-ce que ces classes Helper pourraient éventuellement être utilisées pour gérer les exceptions ?

@Merci

c'est à dire ?!