Discussion :

[omen999]

bonjour,

je rencontre le problème suivant :
je monitore une application tiers écrite en delphi qui utilise dans une form un composant TAdvOfficePager (TMS Software).
cette form est créée dynamiquement par une action utilisateur et plusieurs peuvent être ouvertes simultanément
je dois détecter certaines actions sur ce contrôle, détection que j'obtiens en subclassant celui-ci.
comme celui-ci est susceptible d'être créé un certain nombre de fois,
j'avais naturellement pensé me simplifier la vie en subclassant la classe (SetClassLong) et non la fenêtre.
ce subclassement s'effectue sans erreur mais je constate qu'il reste parfaitement
inopérant pour les nouvelles fenêtres de ce contrôle
je suppose que le constructeur doit réinitialiser la wndproc ou un truc du genre

auriez-vous une idée sur une façon de résoudre ce problème
sachant que je n'ai pas la main sur les sources de l'application
et que le support de TMS est réservé aux clients enregistrés

[Ph. B.]

Bonjour,

auriez-vous une idée sur une façon de résoudre ce problème sachant que je n'ai pas la main sur les sources de l'application
et que le support de TMS est réservé aux clients enregistrés

Ben, détecter chaque ouverture de ce type de fiche et subclasser chacune d'entre elles...
Cette application est lancée dans le même thread ou dans des threads indépendants ?
--
Philippe.

[omen999]

Ben, détecter chaque ouverture de ce type de fiche et subclasser chacune d'entre elles...

ça, c'est ce que je fais déjà avec en prime l'adresse de la précédente wndproc en GWL_USERDATA pour n'en avoir qu'une à gérer pour tous les subclassements

Cette application est lancée dans le même thread ou dans des threads indépendants ?

toutes les instances du ctrl sont dans le même thread ainsi que mon appel infructueux au subclassement de classe
mais de toute façon, le subclassement de classe n'est pas thread-dépendant

[Mat.M]

j'avais naturellement pensé me simplifier la vie en subclassant la classe (SetClassLong) et non la fenêtre.

j'aurais fait exactement l'inverse.
En win32 un contrôle est crée avec CreateWindow ou -Ex.
Qu'importe le langage (Delphi,.NET..) si tu veux créer un contrôle comme une EditBox,il faut passer par CreateWindow
Ensuite ce contrôle est géré par la WindowProcedure de la fenêtre parente qui redistribue les messages systèmes comme EM_GETLINE pour une EditBox via un WM_COMMAND.
Par exemple si tu veux voir qu'une combobox reçoit une notification en win32
il faut examiner le message WM_COMMAND dans la WinProc puis récupérer le ID du Contrôle puis voir si par exemple puis CBN_EDITCHANGE.

SetClassLong n'est pas l'API appropriée : tu ne rattaches pas un pointeur à la boucle de message de la fenêtre parente
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx
Il faut utiliser SetWindowLong sur la procédure de fenêtre parente

[omen999]

mmm, je n'ai pas l'impression que tu as lu les messages précédents car c'est effectivement le subclassement individuel que j'utilise
pour ce qui est de la prog win32, j'ai quelques notions sur le sujet
la classe en window management, c'est une façon pour MS de proposer une POO rudimentaire pour créer des instances de contrôles à partir d'un modèle
ça permet notamment le superclassing qui doit être, de mémoire, la technique utilisée par la vcl delphi pour créer des composants à partir des ctrls win32
modifier l'adresse de la wndproc de la classe doit normalement permettre aux nouvelles instances du ctrl créé à partir de cette classe d'inclure ma wndproc perso
malheureusement, je suppose (?) que le constructeur ne doit pas respecter l'intégrité de la chaine des wndproc en la réinitialisant à sa sauce ce qui n'est pas conforme aux règles définies par MS
comme c'est la 1ère fois que je rencontre le problème, je me demandais s'il existait un trick quelconque sur ce sujet

Qu'importe le langage (Delphi,.NET..)

entièrement d'accord, c'est pourquoi j'avais hésité à poster dans le sous-forum programmation windows et je vais voir s'il est possible de déplacer le sujet (ou pas)

[Mat.M]

Salut voilà des exemples en C++ à tout hasard
http://www.codeproject.com/KB/DLL/PasswordSPY.aspx
http://www.codeproject.com/KB/system...ying_hack.aspx

modifier l'adresse de la wndproc de la classe doit normalement permettre aux nouvelles instances du ctrl créé à partir de cette classe d'inclure ma wndproc perso

oui on est d'accord c'est ce que j'ai essayé d'expliquer

sinon regarder cela
http://msdn.microsoft.com/en-us/libr...(v=VS.85).aspx
il ya des nouvelles fonctions de "subclassing"

malheureusement, je suppose (?) que le constructeur ne doit pas respecter l'intégrité de la chaine des wndproc en la réinitialisant à sa sauce ce qui n'est pas conforme aux règles définies par MS

si le composant est un Active X alors c'est que le contrôle est construit avec une autre manière.
Peut-être que tu peux tracer en code assembleur mais c'est très fastidieux

mmm, je n'ai pas l'impression que tu as lu les messages précédents car c'est effectivement le subclassement individuel que j'utilise

si j'ai parfaitement bien lu mais tu ne décris pas les procédures et les étapes pas-à-pas pour essayer de résoudre le problème

[Montor]

Delphi crée une propriété sur la fiche contenant le pointeur de la fiche dont j'ai oublié le nom regarde l'unité controls, utiliser GetProp
pour recuperer cette information et exceter une Remotethead pour faire un turuc de genre

TForm(Lepointeur).classname

[omen999]

je déterre le sujet pour la bonne cause puisqu'il est résolu après un retour récent sur ce vieux code.
j'ai suivi le conseil de Mat.M et utilisé les méthodes de subclassing plus récentes
après adaptation à la mimine pour mon vieux D4 ça fonctionne nickel

so résolu
merci encore