Discussion :

[Papy214]

Bonjour

Le code suivant me pose problème:

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
 
var
  Form7: TForm7;
 
implementation
 
{$R *.dfm}
 
function Pt(Obj: TObject): NativeUint;
begin
  Result := NativeUint(@Obj);
end;
 
procedure Comp(P: NativeUINT);
var
  K: NativeUint;
begin
  K := Pt(Form7);
  if P = K then
    ShowMessage( TForm7( Pointer(P)^ ).Name );
end;
 
procedure TForm7.FormCreate(Sender: TObject);
var
  V1, V2: NativeUint;
begin
  V1 := Pt(Self);
  V2 := Pt(Form7);
  Comp(V2);
end;

Dans le FormCreate, V1 et V2 sont égaux.
Mais dans Comp, K est différent de P alors que je le récupère de la même façon que dans FormCreate

Et là, je ne comprends pas pas trop le pourquoi du comment :-(

[p.leali]

Pour Delphi les objets sont en fait des pointeurs sur des objets. Il suffit de virer le @ devant obj et ça devrait fonctionner.

Code :

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

1
2
3
4
5
 
function Pt(Obj: TObject): NativeUint;
begin
  Result := NativeUint(Obj);
end;

[Papy214]

Pour Delphi les objets sont en fait des pointeurs sur des objets. Il suffit de virer le @ devant obj et ça devrait fonctionner.

Code :

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

1
2
3
4
5
 
function Pt(Obj: TObject): NativeUint;
begin
  Result := NativeUint(Obj);
end;

Oh le voilà ! Bienvenue !

J'essaye demain. Le vpn est cassé depuis 2 jours et le bureau est inaccessible depuis chez moi.

[Andnotor]

Result := NativeUint(@Obj) ne peut pas fonctionner. @Obj est un pointeur sur la variable Obj locale à la fonction et non son contenu.

V1 et V2 sont égaux parce qu'une variable locale est désallouée à la sortie de la fonction. Le deuxième appel immédiat à Pt peut donc réutiliser la même adresse que le premier pour sa variable Obj.
Dans Comp, ça ne joue plus puisque cette fonction a également un paramètre. C'est ce paramètre P qui sera à l'adresse du Obj précédent (tu peux contrôler, P = @P). A l'appel de Pt depuis Comp, Obj sera décaler sur la pile

[Papy214]

Paul : Effectivement, ça fonctionne avec le code suivant :

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
 
function Pt(Obj: TObject): NativeUint;
begin
  Result := NativeUint(Obj);
end;
 
procedure Comp(P: NativeUINT);
var
  K: NativeUint;
begin
  K := Pt(Form7);
  if P = K then
    ShowMessage( TForm7( Pointer(K) ).Name );
end;
 
procedure TForm7.FormCreate(Sender: TObject);
var
  V1, V2: NativeUint;
begin
  V1 := Pt(Self);
  V2 := Pt(Form7);
  Comp(V2);
end;

Andnotor :

Je ne comprends pas ton raisonnement. V1 et V2 contiennent l'adresse (convertie en entier) de mon TForm.
Les 2 variables contiennent la même valeur puisque j'appelle 2 fois la fonction sur le même objet dénommé de 2 manières différentes.
Dans Comp, le résultat de la fonction devrait donner la même valeur puisque puisque j'appelle la fonction de la même façon.
Enfin, il me semble

[Andnotor]

Je ne comprends pas ton raisonnement. V1 et V2 contiennent l'adresse (convertie en entier) de mon TForm.

Pas avec @Obj, c'est l'adresse de Obj qui est retournée et non son contenu. Tu peux appeler Pt() sur n'importe quoi, même nil si tu veux, tu auras toujours le même résultat

ou alors, tu veux dire que dans ma fonction, P est un pointer sur un pointer ?

C'est ça, Obj est une variable pointeur typé. @Obj est un pointeur sur cette variable de type pointeur

[Papy214]

Result := NativeUint(@Obj) ne peut pas fonctionner. @Obj est un pointeur sur la variable Obj locale à la fonction et non son contenu.

V1 et V2 sont égaux parce qu'une variable locale est désallouée à la sortie de la fonction. Le deuxième appel immédiat à Pt peut donc réutiliser la même adresse que le premier pour sa variable Obj.
Dans Comp, ça ne joue plus puisque cette fonction a également un paramètre. C'est ce paramètre P qui sera à l'adresse du Obj précédent (tu peux contrôler, P = @P). A l'appel de Pt depuis Comp, Obj sera décaler sur la pile

ou alors, tu veux dire que dans ma fonction, P est un pointer sur un pointer ?

[der§en]

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
 
procedure Comp(P: NativeUINT);
var
  K: NativeUint;
begin
  K := Pt(Form7);
  if P = K then
    ShowMessage( TForm7( Pointer(P)^ ).Name );
end;
 
procedure TForm7.FormCreate(Sender: TObject);
var
  V1, V2: NativeUint;
begin
  V1 := Pt(Self);
  V2 := Pt(Form7);
  Comp(V2);
end;

Il y a que moi que cela choque de travailler un coup avec un type NativeUInt d'un côté et un type Pointeur de l'autre ?

Il me semble que ce code pourrais être simplifié en utilisant exclusivement des Pointeurs.

[Papy214]

Oui, je sais, c'est bizarre mais j'ai une bonne raison de faire ça

Je dois coder une classe qui reprend exactement les mêmes procédures avec les même paramètres qu'un activeX existant.
Enfin, une partie seulement des fonctions, heureusement pour moi.
Le but est de remplacer l'activex par mon objet sans toucher au code source du projet.

Et plusieurs de ces fonctions utilisent un handle de type integer comme paramètre.
Sauf que j'utilise un objet et non un TControl.
Donc, pas de handle. Et pas le peine d'en créer un si je peux éviter.
En interne, je peux utiliser n'importe quelle valeur entière.
Chaque instance de la classe doit avoir un identificateur entier (comme si c'était son handle).
Cet identificateur me sert dans un système de message pour faire communiquer les objets les uns avec les autres.
D'abord, j'ai utilisé un compteur en variable de classe.
Et je me suis dis que pour éviter ça, je pourrais simplement utiliser l'adresse de l'objet.
Mais comme il me faut un entier, je caste l'adresse en entier et je passe cette valeur dans ma structure de message.
à réception du message par l'instance correspondante, je me sers de la valeur que je caste à nouveau en pointer puis dans le type voulu pour pointer sur l'objet.

Voili voilà !

[der§en]

Oui, je sais, c'est bizarre mais j'ai une bonne raison de faire ça

Je dois coder une classe qui reprend exactement les mêmes procédures avec les même paramètres qu'un activeX existant.

Ah, si tu as des contraintes externes, c'est différent, je retire ce que j'ai dit

[Paul TOTH]

Ah, si tu as des contraintes externes, c'est différent, je retire ce que j'ai dit

il reste possible de gérer un index dans une liste, on un dictionnaire Index->Objet qui permet de vérifier la validité de l'objet avant de l'utiliser...mais l'usage d'un THandle pour stocker un objet est tout à fait valide

[Papy214]

il reste possible de gérer un index dans une liste, on un dictionnaire Index->Objet qui permet de vérifier la validité de l'objet avant de l'utiliser...mais l'usage d'un THandle pour stocker un objet est tout à fait valide

C'est ce que j'avais fait au départ. Un simple compteur en variable de classe incrémenté à chaque création d'objet et qui donnait un id différent pour chaque instance.
La solution était simple et tout à fait conforme à l'usage que je voulais en faire.
Ça fonctionnait très bien mais je trouvais ça superflu si je pouvais utiliser l'adresse de l'objet lui-même.

Comment aurais-tu fait dans un cas pareil ? Utilisation du compteur ou utilisation de l'adresse de l'objet ?