Lire le TextEdit a chaque fois que son contenu change

Salut,

Je suis capable de trouver le HWND d'un TextEdit multi-ligne qui se trouve sur une Fenetre d'une autre application.

Le contenu de ce TextEdit peut changer a n'importe quel momment. Il faut que je lise le contenu du TextEdit presque automatiquement lorsque le contenu de celui-ci change.

J'ai entendu parler des HOOK pour pouvoir capturer les messages windows. Je suppose que le message EM_REPLACESEL est envoyé. Est-ce que c'est faisable? Si oui, avez-vous des examples ou des tutoriaux qui montre comment utiliser les HOOK (pour capturer les messages sur un TextEdit).

merci

azt

Sinon, le message EN_CHANGE?

Un clavier Azerty en vaut deux

bon, ce que je disais:

je suis aller voir sur MSDN pour le message EN_CHANGE.
c'est écrit:

Sent when the user has taken an action that may have altered text in an edit control. Unlike the EN_UPDATE notification message, this notification message is sent after the system updates the screen. The parent window of the edit control receives this notification message through a WM_COMMAND message.

je crois que ca doit fonctionner.

Mais comment je fais pour savoir que ce message a été envoyé puisque le TextEdit se retrouve sur une fenetre d'un autre programme que le mien?

azt

Faut rentrer dans le processus cible, SetWindowsHookEx ou CreateRemoteThread.

ciao...
BruNews, MVP VC++

Salut,

Un exemple de hook, mais en interne dans l'appli.

Pour que ça marche pour une autre appli, il doit falloire suffire de passer le bon id de thread en paramètre.

Ca à l'air chaud de récupérer cette ID, sauf si c'est nous qui avons lancé l'appli tierce.

Si ce n'est pas nous, il faut commencer par un snapshot des processus.

Celui-ci va commencer par permettre de récupérer l'ID du processus qui nous intéresse.

Ensuite, toutjours avec le même snapshot, on peut lister les ID des threads ainsi que l'ID de leurs processus.

En comparant l'ID du processus parent avec celui récupéré plus haut, on peut trouver les ID des threads du processus.
Et prier pour qu'il n'y en ai qu'un, sinon...

Une alternative est de hooker tout le monde en passant 0 comme thread ID pour hooker tout le monde et tester avec le handle de la fenêtre, mais c'est nettement plus moche.

salut rt15,

est-ce que tu crois que si j'utilise la fonction GetWindowThreadProcessId() ca puisse fonctionner?

Ex:
-----------------------------------------
LRESULT CALLBACK GetMsgProc(int code, WPARAM wParam, LPARAM lParam)
{

}

void BindHookOnWindow(HWND hWnd)
{
 DWORD dwProcessId;
 GetWindowThreadProcessId(hWnd, &dwProcessId);
 SetWindowsHookEx(WH_GETMESSAGE, GetMsgProc, HINSTANCE hMod, dwProcessId);
}
------------------------------------------

De plus, le parametre hMod m'embete.
Il est ecrit:
[in] Handle to the DLL containing the hook procedure pointed to by the lpfn parameter. The hMod parameter must be set to NULL if the dwThreadId parameter specifies a thread created by the current process and if the hook procedure is within the code associated with the current process.

Si je comprend bien, la fonction GetMsgProc doit se retrouver dans une DLL. Et le parametre hMod est donc le handle de cette DLL.
La DLL sera donc injecter dans l'autre application pour que je puisse capturer les messages.

merci

azt

Ah vi très bien ça GetWindowProcessId. Connaissais pas. Effectivement, tu auras peut être bien besoin de faire une dll. En même temps entre un exe et une dll, y a tellement peut d'écart que l'on peut se demander si tu peux pas faire exporter une fonction par ton exe. Une fois que tu auras ton hook en place dans le processus tier, tu peux par exemple envoyer un message perso (WM_USER ou supérieur) à ton processus d'origine avec PostMessage.