Discussion :

[Invité]

Bonjour.

J'avais déjà lancé ce topic il y a quelques temps et je m'étais certainement mal expliqué :

J'ai une application en D6 avec une fenêtre unique qui réagit uniquement à des raccourcis-clavier (y compris pour quitter) via "OnKeyDown" pour commander un, on va dire, "appareil" (il s'agit de robotique). Le BorderStyle est "None" et le FormStyle "FsStayOnTop".

Dans ma routine d'initialisation lancée au démarrage, il y a deux lignes : Application.OnDeactivate:= .... et Application.OnActivate:= ...., qui pointent toutes deux sur des routines Delphi du projet.

Elles provoquent des changements de couleur au niveau de la fenêtre mais en plus la première arrête l'appareil (normal, il serait incontrôlable pendant le temps que l'appplication n'a pas le focus).

Je voudrais maintenant simplement savoir s'il existe une instruction qui peut forcer l'environnement Windows, dans cette première routine, à remettre immédiatement le focus (via le handle de l'application ? ) sur l'application elle-même, bref, à empêcher l'application de ne pas être l'application active sur le bureau et ce jusqu'à ce qu'on la quitte au clavier (une application "égoïste" en quelque sorte ). Il n'y aurait alors plus de problème de nécessité d'arrêt entre autres, ni de "réactivation".

Attention, je précise encore une fois, il ne s'agit pas d'UNE fenêtre d'une application donnée qui doit rester active à l'intérieur de l'application, mais bien de l'application elle-même (en un sens, cela contredit l'esprit du multitâche, je sais).

Voilà, s'il n'y a pas de solution (ce que je crains) je resterai à la configuration actuelle sans me faire HaraKiri . Donc ne perdez pas trop de temps sur ce sujet ...

Merci d'avance...

[Invité]

Re-bonjour.

Trouvé par Google :

The problem is that the user has been giving input to a program that is not yours. You're not entitled to have focus just cause you want it.

It may not be the answer you want, but it is the answer. And Microsoft has been working hard to thwart programs that try to steal focus. Any solution you come up with is breaking the rules, and might not work at any point in the future.

The end ...

[10_GOTO_10]

La solution serait de faire un hook du clavier, comme un keylogger, sauf que là ça commanderait ton "appareil" au lieu d'enregistrer les frappes.

Evidemment, c'est plus vite dit que fait : Il faut un hook bas niveau, ce qui nécessite de le faire dans une dll. Puis ensuite de faire remonter l'information vers ton programme par un moyen quelconque (callback, sockets, etc...).

C'est logique que Windows ait interdit de "prendre" le focus : il suffit qu'il y ait deux application "égoïstes" qui, pour de bonnes ou mauvaises raisons, veuillent chacune prendre le focus, et le système serait bloqué à passer de l'une à l'autre.

[Invité]

Merci pour ton tuyau, mais on sort du contexte dans lequel ce système a été développé. Il ne s'agit pas du tout d'un dispositif destiné à être "diffusé" dans un cadre traditionnel.

Je suis un "bricoleur de coin de table" et pensais à une solution en 2 lignes : obtenir le handle de l'application et ensuite (re)donner le focus à l'application définie par le handle. Visiblement, cela ne fonctionne pas.

Une démonstration a été faite dans un LEGT, et apparemment il serait concevable que des élèves (second cycle) se lancent dans ce type de projet. L'essentiel est alors que la perte de focus soit gérée et qu'ils ne se retrouvent pas avec un système "fou" ; cette sécurité est actuellement assurée ... et d'une manière compatible avec les idées du grand Bill

PS : géniale, ton animation !