[WIN32]Subclassing de classe récalcitrant

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 :calim2:

Bonjour,

Citation:

---

Envoyé par omen999

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 :calim2:

---

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

Citation:

---

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 ;)

Citation:

---

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 :aie:

Citation:

---

Envoyé par omen999

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

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 :calim2:
pour ce qui est de la prog win32, j'ai quelques notions sur le sujet :mouarf:
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 :aie:
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

Citation:

---

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)

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

Citation:

---

Envoyé par omen999

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"

Citation:

---

Envoyé par omen999

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 :aie:

---

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

Citation:

---

Envoyé par 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

---

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

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

je déterre le sujet pour la bonne cause puisqu'il est résolu après un retour récent sur ce vieux code. :aie:
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 :ccool:

so résolu
merci encore