Discussion :

[KlausGunther]

Je réalise une vaste DLL de support, en Delphi 6 Personal Edition, pour un langage Freeware externe (clone de Basic).

Dans le cadre de ce travail, je souhaite mettre à disposition une fonction permettane de gérer la couleur et les délais des HINT des différents objets de l'application. Pour cela, je tente d'utiliser les propriétés de l'objet TApplication, et j'ai bien conscience que cela est supposé s'appliquer sur les HINT de tous les objets de l'application.

J'ai créé une petite fonction qui fait ce travail, mais il y a un problème. Elle se termine bien, sans erreur, mais en réalité, elle n'a aucune action effective. Voici mon code:

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 ConfigureHintProperties(app: integer; HHP,HP, R,G,B: integer):integer; stdcall; export;
var
  ClassName: array[0..255] of char;
  s: string;
  oldapp: integer;
begin
  result := -1;
  try
    if app=0 then exit;
    GetClassName(THandle(app), ClassName, 255);
    s := trim(ClassName);
    if s<>'TApplication' then exit;
    oldapp := integer(Application.Handle);
    Application.Handle := THandle(app);
    Application.HintHidePause := HHP*1000;
    Application.HintHidePause := HP*1000;
    Application.HintColor := RGB(R,G,B);
    Application.Handle := THandle(oldapp);
    result := 0;
  except
  end;
end;
exports ConfigureHintProperties;

J'essaie de changer les propriétés HintHidePause, HintHidePause et HintColor. En vérifiant dans la fonction, ces valeurs ont bien été changées. Mais dans le "monde réel", je ne constate aucun changement. Qu'est-ce que j'ai manqué ? Il y a forcément un problème d'incompréhension de ma part.

Juste pour compléter l'information: la valeur passée dans le premier paramètre est bien la valeur de Application.Handle du programme appelant. D'ailleurs, ma fonction teste bien cela en vérifiant le ClassName obtenu par ce handle.

(J'espère que j'ai posté ce message dans la bonne rubrique...).

[KlausGunther]

Pour compléter ma question, je poste ci-joint un fichier ZIP contenant deux projets:
test_Hint.dpr et ses fichiers associés: une DLL contenant une seule fonction: ConfigureHintProperties
programme.dpr: programme principal appelant cette fonction en liant cette DLL de façon statique

Il y a 3 champs permettant de modifier les paramètres: deux SpinEdit po. Chaque modification est répercutée immédiatement par un appel à la fonction DLL.

Or, bien que la fonction retourne la valeur 0 indiquant son exécution sans erreur, le hint du bouton s'affiche normalement, sans tenir compte des paramétrages imposés.

Je ne vois absolument pas où est le problème.

[Cirec]

coté Dll:

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
function ConfigureHintProperties(app: integer; HHP,HP, R,G,B: integer):integer; stdcall; export;
begin
  result := -1;
  try
    if app=0 then exit;
    with TApplication(app) do begin
      HintHidePause := HHP*1000;
      HintPause := HP*1000;
      HintColor := RGB(R,G,B);
    end;
    result := 0;
  except
    Result := -1;
  end;
end;

coté Programme:

Code :

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

  res := ConfigureHintProperties(Integer(application), Form1.SpinEdit1.Value,Form1.SpinEdit2.Value, R,G,B);

Cordialement,
@+

[KlausGunther]

Merci pour ton message, Cirec !

Je conçois bien que ça marche en passant Application. Malheureusement, je dois me contenter de Application.Handle. En fait, le projet Programme.dpr n'est qu'une simulation pour mettre le problème en évidence. Dans la "vie réelle", ma DLL est appelée par un programme réalisé dans un autre langage (lui aussi basé sur Delphi, mais je n'ai pas la maîtrise des sources !). Et seule la valeur de Application.Handle est disponible, via une fonction intrinsèque disponible dans ce langage.

Je le sers déjà de cette possibilité de passer la valeur de Application.Handle à une autre de mes fonctions, pour créer un ColorSelector. Cette fonction est:

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
  DllColorSelector: TColorDialog;
...
function ColorSelector(happ: HWND; aR, aG, AB, aColor: pinteger):integer; stdcall; export;
var
  clr: TColor;
  oldHandle, hmemo: HWND;
  txt, s: string;
  sl: TStringList;
  nlen, i, aclr: integer;
begin
  result := -1;
         try
           oldHandle := Application.Handle;
           if happ<>0 then Application.Handle := happ;
           if not assigned(DllColorSelector) then DllColorSelector := TColorDialog.Create(nil);
           if DllColorSelector.Execute then begin
             clr := DllColorSelector.Color;
             aColor^ := clr;
             aR^ := (clr and $FF);
             aG^ := ((clr shr 8) and $FF);
             aB^ := ((clr shr 16) and $ff);
             result := 0;
           end else begin
             aColor^ := -1;
          end;
         except
         end;
         Application.Handle := oldHandle;
end;

Ca marche sans problème. L'affectation de happ à Application.Handle est indispensable - sinon, ça ne marche pas.
J'ai fait cela également dans d'autres situations - j'ai toujours réussi à "lier" l'objet Application de ma DLL à l'objet Application du programme appelant. Qu'est-ce qui est différent dans mon problème actuel ? C'est ce que je n'arrive pas à comprendre.

Ou, prenons le problème par l'autre bout. Peut-être un problème de différence de version des VCL ? Alors, peut-on changer ces délais et la couleur de fond par des messages, via SendMessage ? Je n'ai rien trouvé à ce sujet...

[Paul TOTH]

Bonjour,

Ce que tu veux faire est presque impossible.

HintPause et HintColor sont des propriétés de l'objet Application, elles ne sont pas directement liées à l'API Windows et donc le Handle de Application n'apporte pas grand chose.

voici une solution presque possible: il nous faut l'instance réelle de TApplication et non son Handle

Windows nous donne tout de même une information intéressante sur les objets Delphi, c'est la WndProc par GetWindowLong(Handle, GWL_WNDPROC), cette procédure est générée dynamiquement par Delphi pour appeler la méthode WndProc de l'objet associé...on a donc bien une association entre le Handle et l'objet Delphi !

Démonstration :

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
 
type
  PObjectInstance = ^TObjectInstance;
  TObjectInstance = packed record
    Code  : Byte;
    Offset: Integer;
    Proc  : Pointer; // TApplication.WndProc
    App   : TApplication;
  end;
 
procedure TForm1.FormCreate(Sender: TObject);
var
  PObj: PObjectInstance;
begin
  NativeInt(PObj) := GetWindowLong(Application.Handle, GWL_WNDPROC);
  if PObj.App = Application then
  begin
    ShowMessage('YES !');
  end;
end;

Ici je teste mon propre objet application pour m'assurer que ça fonctionne, je peux donc vérifier que PObj.App = Application, dans le cas d'une DLL ce teste ne fonctionnera évidemment pas car DLL et EXE ont chacun une instance propre de TApplication.

il devrait alors être possible de changer les propriétés HintPause et HintColor de cet objet Application, en effet ces propriétés n'affectent pas le gestionnaire de mémoire qui n'est pas partagé entre la DLL et l'EXE donc il ne devrait pas y avoir d'effet de bord.

MAIS cela ne fonctionnera QUE si l'EXE et la DLL ont été compilés avec la MEME version de Delphi, car la DLL possède sa propre définition de l'objet Application, si elle a été modifiée par rapport à la version de l'EXE les adresses des propriétés ne seront plus forcément les mêmes.

Après il reste possible de déclare une classe TOldApplication qui soit compatible avec le code de l'autre application, mais ce n'est pas forcément simple car chaque classe ancètre peut avoir été modifiée (TApplication->TComponent->TPersisent->TObject)

une test simple pour s'assurer de la compatibilité est de tester InstanceSize

Code :

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

1
2
3
4
5
6
7
 
begin
  if PObj.App.InstanceSize <> Application.InstanceSize then
  begin
    ShowMessage('Warning ! versions de Delphi incompatibles');
  end;
end;

Dernière remarque, il suffit qu'une DLL du genre de celle que tu développes remplacer la WndProc de l'objet Application par un code personnel pour que la méthode ne fonctionne plus car la WndProc retournée ne sera plus celle de Delphi

Un petit test qui permet de limiter la casse est de s'assurer que PObj.code = $E8 qui est le code assembleur d'un CALL NEAR PTR.

Dernière remarque, tout cela fonction avec Delphi Tokyo mais à priori le fonctionnement était le même sous Delphi 6, donc à part la structure des classes, la méthode pour retrouver l'instance devrait fonctionner.

[KlausGunther]

Merco beaucoup, Paul TOTH ! Je commence à entrevoir les difficultés du défi qui l'attend. Je vais essayer de mettre ces éléments en application.

[KlausGunther]

Mes premiers essais me laissent perplexe.

D'abord, mon compilateur D6 Personal Edition ne laisse pas passer la construction

Code :

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

NativeInt(PObj) := GetWindowLong(Application.Handle, GWL_WNDPROC);

J'ai donc transformé ton code comme suit:

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
type
  PObjectInstance = ^TObjectInstance;
  TObjectInstance = packed record
    Code  : Byte;
    Offset: Integer;
    Proc  : Pointer; // TApplication.WndProc
    App   : TApplication;
  end;
 
procedure GetApplication(happ: THandle);
var
  PObj: PObjectInstance;
begin
  PObj := PObjectInstance(GetWindowLong(happ, GWL_WNDPROC));
  if PObj.App = Application then ShowMessage('YES !')
                            else Showmessage('NO !');
  if PObj.App.InstanceSize <> Application.InstanceSize then
    ShowMessage('Warning ! versions de Delphi incompatibles - '+inttostr(PObj.App.InstanceSize)+'<>'+inttostr(Application.InstanceSize))
  else
    ShowMessage('Warning ! versions de Delphi compatibles - '+inttostr(PObj.App.InstanceSize)+'<>'+inttostr(Application.InstanceSize));
end;

Ai-je bien compris le principe ?

Test 1: j'ai placé ce code dans le projet Progrramme (programme principal) et j'ai appelé la procédure GetApplication dans Form1.Create de la manière suivante:

Code :

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

GetApplication(Application.Handle);

Résultat: un message "YES !", suivi de "compatible" avec les deux tailles identiques de 296 octets.

Test 2: j'ai placé ce code dans le projet test_Hint (la DLL) et j'ai appelé la procédure GetApplication dans ma fonction ConfigureHintProperties comme suit:

Code :

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

GetApplication(app);

Résultat: un message "NO !", suivi de "compatible" avec les deux tailles identiques de 296 octets.

Test 3: j'ai appelé ma fonction ConfigureHintProperties dans cette DLL par mon programme externe réel, écrit en Basic.
Résultat: un message "NO !", suivi de "incompatible" avec les deux tailles différentes de 360 et 296 octets.

Alors, j'ai besoin d'y voir plus clair.
1. comment GetWindowLong avec l'offset WNDPROC (soit la valeur -4) peut-elle retourner un pointeur vers l'instance de l'objet Application ?
2. pourquoi, dans Test 2, j'ai une réponse "NO !" alors que les deux projets (test_Hint.dpr pour la DLL et programme.dbr pour le programme appelant) ont été compilés et générés par le même cimpilateur Delphi ?
3. une question peut-être un peu plus générale: y a-t-il un lien entre le handle d'un objet (forcément un TWinControl, je ne parle pas des Canvas) et l'instance de cet objet ?
4. est-ce que la réponse à (3) s'applique également à un objet TApplication ?

Dans mon esprit, l'objet Application a un lien avec la fenêtre initiale (de dimensions 0x0 pixels) créée par Delphi au démarrage. Cet objet crée également la ou les forms de l'application et détermine la MainForm, entre autres. Je sais bien que TApplication n'est par un TForm, mais TApplication a un handle, et le fait que tu utilises GetWindowLong(Application.Handle, GWL_WNDPROC) semble impliquer que la structure des deux types d'objet est très proche. Est-ce que je me trompe ?

[Cirec]

ça risque d'être impossible puisqu'il semble que le prog externe ait été compilé avec une version différente
de celle utilisée pour la Dll
et Delphi change souvent de taille ^^
Application.InstanceSize:
- D7 = 320
- D? = 360
- D2009 = 388
- Berlin 10.1 = 412
- Tokyo10.2 = 412

dans ce cas même le code que j'ai donné plus haut ne fonctionnera pas c'est certain !
pour l'instant, je ne vois pas comment faire
Cordialement,
@+

[KlausGunther]

Ce n'est pas rassurant, Cirec !

J'essaie d'explorer l'autre piste qui est celle des messages Windows. Puisque l'objet Application a un handle et une WndProc, il est supposé réagir à certains messages envoyés par WendMessage, non ? Je n'ai rien trouvé comme message spécifiquement adressé à cet objet. Y a-t-il une liste ou documentation pour cela ? Car si je pouvais envoyer mes valeurs via un SendMessage, la frontière entre les deux versions de VCL s'efface et il n'y a pas de problème de memory managment, puisqu'il n'y a pas de chaînes de caractères mises en jeu.

Une autre piste serait d'obtenir de schéma (le layout) de l'instance de l'objet Application et d'y accéder directement. D'accord, ce n'est pas propre, mais ça pourrait constituer une solution pour ce cas précis.

[KlausGunther]

J'ai découvert quelques informations sur la structure de mon objet Application. A force de faire des dumps, j'ai identifié les offsets suivants à partir de l'adresse pointée par la variable Application:

Code :

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

1
2
3
4
5
6
7
8
9
{
   Propriété      Offset
   ==============================
   Handle          48 = $00000030
   WndProc         64 = $00000040
   HintColor       92 = $0000005C
   HintHidePause  116 = $00000074
   HintPause      120 = $00000078
}

Exemple:

Code :

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

pinteger(integer(Application)+92)^ := clYellow;

est équivalent à

Code :

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

Application.HintColor := clYellow;

Alors, j'ai deux questions:
1. comment puis-je obtenir la valeur de la variable Application à partir de Application.Handle ?
2. quels sont les équivalents de ces offsets pour une version Delphi dont Application.InstanceSize=360 ?

Avec la réponse à ces deux questions, je pourrais résoudre mon problème ! Je sais bien que c'est un hack, totalement dépendant des deux versions du VCL (celle de la DLL et celle du programme principal). Mais pour mes besoins, c'est suffisant car je sais que cela restera inchangé. Bien sûr, s'il y avait une solution plus "propre"...

[Paul TOTH]

Klauss, reprenons tes exemples

TEST1: tout est ok, rien à dire

TEST2: tout est normal, lire mon commentaire en ROUGE pour comprendre le "NO !"

TEST3: que vient faire le Basic là dedans ?! TApplication c'est un objet Delphi pour des application Delphi ...

1. comment GetWindowLong avec l'offset WNDPROC (soit la valeur -4) peut-elle retourner un pointeur vers l'instance de l'objet Application ?

la VCL utilise la fonction MakeObjectInstance() pour créer une portion de code assembleur qui redirige la WndProc de Windows vers une méthode objet de Delphi, TObjectInstance est la structure utilisé par MakeObjectInstance pour créer ce bout de code, avec:

Code :

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

1
2
3
4
5
6
7
 
TObjectInstance = packed record
    Code  : Byte;    // $E8 = CALL NEAR PTR
    Offset: Integer; // offset calculé vers un code générique qui exploite les informations ci_après
    Proc  : Pointer; // TApplication.WndProc
    App   : TApplication;
  end;

cette structure mémoire n'a pas évolué depuis Delphi 6 et on peut donc retrouver l'instance objet à partir du Handle

2. pourquoi, dans Test 2, j'ai une réponse "NO !" alors que les deux projets (test_Hint.dpr pour la DLL et programme.dbr pour le programme appelant) ont été compilés et générés par le même cimpilateur Delphi ?

voir plus haut

3. une question peut-être un peu plus générale: y a-t-il un lien entre le handle d'un objet (forcément un TWinControl, je ne parle pas des Canvas) et l'instance de cet objet ?

le Handle est en fait le pointer de l'objet du côté Windows, le lien avec l'objet Delphi se fait comme expliqué en (1), et cela UNIQUEMENT pour les objets qui exploitent une WndProc (ce n'est pas le cas d'un Canvas).

4. est-ce que la réponse à (3) s'applique également à un objet TApplication ?

TApplication n'est pas un TWinControl mais il utilise la méthode MakeObjectInstance() pour recevoir des messages. C'est aussi le cas de TCommonDialog et quelques autres composants. A chaque fois on peut retrouver l'instance de l'objet associé à la méthode de gestion de message.


2. quels sont les équivalents de ces offsets pour une version Delphi dont Application.InstanceSize=360 ?

aucune idée...mais en tu devrais pouvoir retrouver l'adresse qui contient clInfoBk, et celle qui contient 500 pour la HidePause...ensuite au pire tu plantes l'appli quelque fois mais tu finiras bien par trouver la bonne adresse

[KlausGunther]

Ok, merci, Paul. Faut que je digère cela un peu - je vais avoir pas mal d'essais à faire...

Juste une remarque, concernant l'apparition du Basic dans mon post. En effet, ma DLL est en Delphi 6 PE, mais elle contient des routines de support destinées à être appelées par des programmes réalisés en une version freeware de Basic. Je me suis pris de passion pour ce langage, et autant pour le petit forum d'autres amateurs de ce langage que j'essaie de soutenir comme je peux. N'ayant pas la maîtrise des sources de ce Basic, mes moyens sont assez limités, et en-dehors de conseils généraux de programmation, j'interviens essentiellement en créant "à la volée" des fonctions via ma DLL en Delphi, tout en respectant les sévères contraintes d'appel imposées par ce langage. Mais c'est un véritable défi, comme je les aime.

Dans le cadre de ma demande d'aide sur ce forum, cela n'aurait évidemment servi à rien de donner le code source du programme Basic en relation avec le problème actuel. C'est la raison pour laquelle j'ai fait un petit projet Programme.dpr, simulant en fait la partie significative du programme Basic en question. Cependant, et c'est la seule chose dont je suis sûr, ce Basic (interprété) est réalisé à l'aide d'une version de Delphi, visiblement pas très récente, mais néanmoins plus récente que mon D6 PE. D'ailleurs, soit dit en passant, ma DLL contient actuellement près de 1000 fonctions, dans tous les domaines, des opérations binaires jusqu'aux bases de données, du pilotage transparent de MS-Office/Open-Office jusqu'aux fonctions graphiques, sprites avec spots sensibles etc.

Voilà pour situer un peu le contexte.