Discussion :

[Andnotor]

Le tout me paraît compliqué

* de la méthode finale de mise en évidence du contrôle actif

Là c'est un choix. Je pense en effet que gérer les rafraichissements sont plus compliqués. Mais la fenêtre fera appel aux mêmes fonctions pour son positionnement (GetWindowRect). En gérant WM_NCHITTEST, tu pourrait même remplir la forme d'une couleur semi-transparente (ta demande du premier post) sans altérer le comportement général.

de la gestion globale des contrôles utiles (ma classe)?

Que tu encapsules tes méthodes dans une classe, pourquoi pas. Mais elle ne peut être que générique et je ne vois pas l'utilité d'en avoir une par contrôle. Enfin si, je vois : les timers (voir explication ci-dessous)

de la méthode d’interception des événements (clavier, focalisation, premier plan)

Là sans aucun doute
Toutes les détections devraient être faites par hooks notifiant ton application des changements.

Un WH_CALLWNDPROC(RET) pour intercepter WM_SETFOCUS et WM_ACTIVATE.
Un WH_KEYBOARD pour les frappes clavier. Si le champ est supposé numérique, tu pourrais même facilement interdire les caractères alpha. Et bien sûr tu serais notifié de chaque frappe alors qu'avec un timer tu ne peux contrôler que l'état des touches à un temps T.

la manipulation et au contrôle des valeurs des nombreux champs présents dans l'appli cible. Le but étant de pouvoir les utiliser comme s'il s'agissait de contrôles de ma propre appli ou j'écrirais : "editNomClient.text:=..." etc....

Si on part du principe du hook (travaille en amont. Soit avant que la donnée soit insérée), la fiche avec quelques méthodes supplémentaires suffirait. (WriteField, ReadField, CheckField)

Maintenant si l'insertion d'une donnée peut entraîner la modification d'un autre champ, je ne dis pas...

Je pense que l'utilisation de timer complique beaucoup ton application puisque lorsque l'événement est généré (même avec un temps très court), tu ne peux garantir que le champ à tester soit bien celui détenant la focalisation. Tu es donc obligé de parcourir à chaque fois l'ensemble des champs...

Penses-tu que c'est le genre de technique utilisée pour les affichages "OSD" utilisés par certains drivers de clavier qui à l'appui de caps lock, par expl, affichent en bas de l'écran un texte comme "Capslock ON" qui reste bien audessus de toutes les appli pendant qq secondes et ce, même si on est entrain d'en déplacer une ?

Sans doute. C'est en tout les cas ainsi que je le ferais

[David]

Merci Andnotor d'avoir encore pris du temps pour me répondre.

Chacun des points sur lesquels tu m'as répondu m'inspire une nouvelle remarque ou interrogation mais je vais m'abstenir car cela ne ferait que nous éloigner un peu plus du sujet de départ pour nous rapprocher d'autres sujets/ techniques (timer, hooks, etc). Et là le post n'en finirait plus !

Je vais donc prendre en compte tous ces conseils et pistes, et les étudier correctement avant de reposter si besoin est.
Les hooks par expl sont un technique que je ne n'ai jamais mis en œuvre, mais je pense que l'on trouve largement de quoi se documenter sur le sujet (il faut passer par un dll, je crois).
De toute manière, tu as 100% raison sur le fait de privilégier un méthode événementielle à l'utilisation de timers.
(c'est juste que dans ma courbe de progression ils étaient avant ! )

Et dire qu'au départ je voulais m'en sortir avec un sendmessage !

[Andnotor]

Et dire qu'au départ je voulais m'en sortir avec un sendmessage !

Mais ce n'est pas si faux
Tout repose sur les messages et le but du hook est de les intercepter avant qu'ils n'atteignent l'application cible.
La gestion (le niveau intermédiaire) consistant à envoyer un autre message à notre application, asynchrone par PostMessage pour simplement dessiner un rectangle de focalisation ou synchrone par SendMessage si le message d'origine doit être modifié ou sa propagation "abortée".

Pense que tes timers aussi réagissent à des messages de type WM_TIMER...