Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre régulier
    Applications en multiscreen et gestion des events touchscreen/souris
    edi: Lazarus 2.0.6
    context: Dual screen dont un touchscreen 10" (usb link pour virtual screen).


    Bonjour, j'ai un soucis avec deux applications dont l'une est graphique Direct3d en fullscreen sur un écran normal et l'autre en fullscreen mode fenêtré sur un touchscreen( écran virtuel sur tablet android) en deuxième écran. Lorsque je clique ( avec le doigt) sur le touchscreen, l'application graphique de l'ecran principal( ayant le focus souris) s'icônise en barre des tâches et le curseur souris va directement sur le bouton fenêtré de la deuxième application.
    J'aimerais pouvoir utiliser indépendamment/mode exclusif le touchscreen pour l'application fenêtré, et la souris pour le reste. comment dois je m'y prendre ? avez vous des pistes ?

  2. #2
    Membre expert
    Salut j'ai rien compris

    Mais, bref, allons y à la louche

    c'est quoi ce bidouillage avec une tablette ?
    c'est toi qui à coder les applications ?
    Les 2 sont en Direct3D ?

    pour moi le comportement est normal surtout avec ce genre d'applis utilisant Direct3D ou OpenGL en PLEIN ECRAN, lance cette 1ere en mode fenêtré. Tu ne devrai plus avoir ce comportement

    A+
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  3. #3
    Membre régulier
    Merci d'avoir répondu, pour quelqu'un qui n'a rien compris t'as plutôt bien cerné le probleme .
    j'avais pensé à cette solution, mais même si elle est fonctionnelle, ça reste un bidouillage pas très classe de mon point de vue( toutes les sorties d'application comme le son est coupé) et les bords de fenêtre ca fait assez sale vu l'usage .

    Pour répondre a ta première question sur la bidouille, je me sert d'une tablette 10" android pour faire de "l'exportdisplay" via USB, sous windows cet écran est detecté avec le "tablettactileHID" qui lui correspond. Cet ecran tactile virtuel est géré par une carte graphique virtuelle software, c'est pas top, mais mon i9 s'en fou royale..XD..

    Apres une aprem à fureter sur la question je me rends compte que mis a part faire une fenêtre child de l'application graphique et de charger une DLL contenant l'app fenêtré dans celle-ci, windows continuera de faire perdre le focus à l'application graphique ( car c'est le fonctionnement normal du gestionnaire d'event windows de regrouper tout les input pointeurs vers la souris sans discinctions ). malheureusement je n'ai pas le droit de bidouiller le code de l'appli graphique.

    Sauf si :
    - j'ai un moyen de me substituer au gestionnaire d'event windows et de faire un filtre qui bloque uniquement les events touchpad pour éviter que windows et les autres apps ne les reçoivent. dans ce cas il y aurait une ouverture.
    - On peu rediriger le flux d'un input exclusivement vers une appli précise, grâce aux api windows.

    Mais est ce au moins possible?

    C'est pour utiliser l'application fenêtré comme un tableau de bouton(grid/telecommande graphique) pour envoyer des keystrokes à l'application graphique et m'eviter les combinaisons de touche fastidieuses.

    d'autres idée ?
    ( j'veux pas entendre parler de réseau XD)

    au passage j'ai trouvé ton projet Gif animé très utile pour le mien( non lucratif/GPLv3 ), puis je l'intégrer ?

  4. #4
    Rédacteur/Modérateur

    Citation Envoyé par megs Voir le message
    faire un fenêtre child de l'application graphique et de charger une DLL contenant l'app fenêtré dans celle-ci, windows continuera de faire perdre le focus à l'application graphique
    Ça ne résoudra pas le problème. Plus que l'app active, c'est la fenêtre au premier plan qui consomme les commandes clavier. Et puisque ce sera ta fenêtre, elles n'atteindront jamais leur cible.

    A la place, il faut spécifier que la fenêtre (ton tableau de boutons) ne s'active jamais. Il est tout à fait possible de le faire sous Windows et c'est le principe même des claviers virtuels.

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    type
      TForm1 = class(TForm)
      protected
        Procedure CreateParams(var Params: TCreateParams); override;
      end;
     
    procedure TForm1.CreateParams(var Params: TCreateParams);
    begin
      inherited;
      Params.exstyle := Params.exstyle or WS_EX_NOACTIVATE;
    end;

  5. #5
    Membre régulier
    "c'est l'app active qui consomme les frappes clavier" nop pas dans le cas du SendMessage(H, WM_KEYDOWN, vKey, lParam);

    ne pas activer la fiche : merci, mega supertop j'essaye ça et je reviens ... une foi que j'aurrais trouvé la bonne méthode pour lazarus...

  6. #6
    Membre régulier
    Veuillez noter l'ordre d'apparition des déclarations d’unités afin que ca fonctionne....

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    22
    23
    24
    25
    26
    27
    28
    29
    30
    31
    32
    33
    34
    35
    36
    37
    38
    39
    40
    41
    42
    43
    44
    45
    46
    47
    48
    49
    50
    51
    52
    53
    54
    55
    56
    57
    58
    59
    60
    61
    62
    63
    64
    65
    66
    67
     
    unit Unit1;
     
    {$mode objfpc}{$H+}
     
    interface
     
    uses
      LCLtype,windows,Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls ;
     
    type
     
      { TForm1 }
     
      TForm1 = class(TForm)
        BT_GetApp: TButton;
        BT_SendTo: TButton;
        ListBox1: TListBox;
        procedure BT_GetAppClick(Sender: TObject);
        procedure BT_SendToClick(Sender: TObject);
      protected
        Procedure CreateParams(var Params: TCreateParams); override;
      private
      public
      end;
     
    var
      Form1: TForm1;
     
    implementation
     
    {$R *.lfm}
     
    { TForm1 }
    procedure TForm1.CreateParams(var Params: TCreateParams);
    begin
      inherited;
      Params.exstyle := Params.exstyle or WS_EX_NOACTIVATE;
    end;
     
    procedure TForm1.BT_GetAppClick(Sender: TObject);
    var app, edit: HWND;
    begin
      app := FindWindow('notepad', nil);
      edit := FindWindowEx(app, FindWindow('Edit', nil), nil, nil);
     
      SendMessage(edit, WM_CHAR, dword('H'), 0);
      SendMessage(edit, WM_CHAR, dword('e'), 0);
      SendMessage(edit, WM_CHAR, dword('y'), 0);
     
      PostMessage(app, WM_KEYDOWN, VK_F5, 0);
      PostMessage(app, WM_KEYUP, VK_F5, 0);
     
    end;
     
    procedure TForm1.BT_SendToClick(Sender: TObject);
    var
      app, edit: HWND;
    begin
      app := FindWindow('notepad++', nil);
     
     
      PostMessage(app, WM_KEYDOWN, VK_F5, 0);
      PostMessage(app, WM_KEYUP, VK_F5, 0);
    end;
     
    end.

  7. #7
    Rédacteur/Modérateur

    Citation Envoyé par megs Voir le message
    pas dans le cas du SendMessage(H, WM_KEYDOWN, vKey, lParam);
    C'est une mauvaise idée à moins de savoir exactement ce que fait l'app cible.

    Imagine qu'en recevant disons un "A" elle veuille connaitre l'état du shift par GetKeyState. Et bien ça ne fonctionnera pas même si le shift a aussi été envoyé avant par Send/PostMessage puisque c'est le système qui fixe l'état des touches au remplissage du buffer, pas l'app cible.

    Si tu voulais utiliser SendMessage, c'est je suppose uniquement parce que ta fenêtre était au premier plan et que la cible ne recevait pas les commandes (ce que je mentionnais précédemment). Si maintenant elle est toujours désactivée, tu n'as plus ce problème et je te conseille vivement de remplir le buffer de clavier comme il se doit par SendInput (ou éventuellement par Keybd_Event).

  8. #8
    Membre expert
    Citation Envoyé par megs Voir le message
    Merci d'avoir répondu, pour quelqu'un qui n'a rien compris t'as plutôt bien cerné le probleme .
    j'avais pensé à cette solution, mais même si elle est fonctionnelle, ça reste un bidouillage pas très classe de mon point de vue( toutes les sorties d'application comme le son est coupé) et les bords de fenêtre ca fait assez sale vu l'usage .
    Ouep j'ai compris plus ou moins en "supposant que...." , bref....

    En mettant les bordure a bsNone, ça ne le fait pas ?

    Citation Envoyé par megs Voir le message

    Pour répondre a ta première question sur la bidouille, je me sert d'une tablette 10" android pour faire de "l'exportdisplay" via USB, sous windows cet écran est detecté avec le "tablettactileHID" qui lui correspond. Cet ecran tactile virtuel est géré par une carte graphique virtuelle software, c'est pas top, mais mon i9 s'en fou royale..XD..
    Je vais faire des recherches la dessus je ne savais pas que c'était possible

    Citation Envoyé par megs Voir le message

    Apres une aprem à fureter sur la question je me rends compte que mis a part faire une fenêtre child de l'application graphique et de charger une DLL contenant l'app fenêtré dans celle-ci, windows continuera de faire perdre le focus à l'application graphique ( car c'est le fonctionnement normal du gestionnaire d'event windows de regrouper tout les input pointeurs vers la souris sans discinctions ). malheureusement je n'ai pas le droit de bidouiller le code de l'appli graphique.

    Sauf si :
    - j'ai un moyen de me substituer au gestionnaire d'event windows et de faire un filtre qui bloque uniquement les events touchpad pour éviter que windows et les autres apps ne les reçoivent. dans ce cas il y aurait une ouverture.
    - On peu rediriger le flux d'un input exclusivement vers une appli précise, grâce aux api windows.

    Mais est ce au moins possible?

    C'est pour utiliser l'application fenêtré comme un tableau de bouton(grid/telecommande graphique) pour envoyer des keystrokes à l'application graphique et m'eviter les combinaisons de touche fastidieuses.

    d'autres idée ?
    ( j'veux pas entendre parler de réseau XD)
    AndNotOr t'as donné la solution et comme il le dis utiliser SendInput est plus approprié que SendMessage surtout si tu ne peux pas toucher au code de l'appli principale. (ce qui aurait été plus simple)

    Citation Envoyé par megs Voir le message

    au passage j'ai trouvé ton projet Gif animé très utile pour le mien( non lucratif/GPLv3 ), puis je l'intégrer ?

    Merci pas de problème, tu peux l'utiliser il est sous licence MPL

    A+

    Jérôme
    • "L'Homme devrait mettre autant d'ardeur à simplifier sa vie qu'il met à la compliquer" - Henri Bergson
    • "Bien des livres auraient été plus clairs s'ils n'avaient pas voulu être si clairs" - Emmanuel Kant
    • "La simplicité est la sophistication suprême" - Léonard De Vinci
    • "Ce qui est facile à comprendre ou à faire pour toi, ne l'est pas forcément pour l'autre." - Mon pèrei

    Mes projets sur Github - Blog - Site DVP

  9. #9
    Membre régulier
    SendInput est plus approprié que SendMessage surtout si tu ne peux pas toucher au code de l'appli principale. (ce qui aurait été plus simple) bha... ca dépend, le sendInput oblige a activer l'app avant l'envoie de l'input ( ce qui dans mon cas, c'est vrais n'est pas vraiment un problème mais bon ). je testerais l'un est l'autre pour voir lequel servira le mieux mes interêts.

    Je vais faire des recherches la dessus je ne savais pas que c'était possible
    playstore->TwomonSE 9euros +app Winx64 sur leur site. ( ca va..pas trop cher l'écran tactile pour un recyclage de tablette DSlide "gratuite").

    merci en tout cas.

###raw>template_hook.ano_emploi###