Robot mouse Press

Bonjour,

Un petit casse tete chinois XD.


J'ai une boucle que je déclenche avec des condition (boolean) . Maintien du clic droit de la souris et déclenchement de ma boucle avec le clic gauche. Quand je relache le clic gauche la boucle stop.

Donc :

Code:

---

1 2 3 4 5 6 7

while (Main.leftclick && Main.enable) {   point = MouseInfo.getPointerInfo().getLocation(); robot.mouseMove(point.x + correctionX, point.y + correctionY); Thread.sleep(rateoff, ntime);   }

---

Ceci fonctionne tres bien.

Je voulais ajoute la fonction que la souris effectue des clicks a répetition en fonction du temps de "thread.sleep" dans ma boucle



Donc j'ai fais ceci :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

while (Main.leftclick && Main.enable) {     robot.mousePress( InputEvent.BUTTON1_MASK ); ----------> ligne ajoute   // robot.mouseRelease( InputEvent.BUTTON1_MASK ); ------> Si je met ceci ma boucle stop, je n'es qu'un mouvement   point = MouseInfo.getPointerInfo().getLocation(); robot.mouseMove(point.x + correctionX, point.y + correctionY); Thread.sleep(rateoff, ntime);   }

---

Ca fonctionne comme je le souhaite mais il arrive que ma boucle se bloque en infini( je suppose que c'est du au faite que c'est mon clic gauche(souris physique) qui la declenche.

Mais Je doit impérativement garde le déclenchement de ma boucle avec le clics gauche de la souris.

Je me demande si en java on peut differencier le clic physique du clic virtuel.

Sur du language AHK ou python on peu.

D'ailleurs j'avais palier a ce problème en ajoutant la dll.ahk a java ainsi que un script mais la méthode me paraissais trop lourde et je subussais quelque bug.

Alors pour faire plus simple, j'ai aussi fait un ahk que j'ai compile en .exe que je demarrais avec mon application. ceic marchais mais trés difficile de synchronise les clics souris (ahk) avec mes déplacement(appli java).




Je vous remercie

Cordialement


Fred

Bonsoir,


J.ai resolu mon probleme en separent mon robot mouse move et mon robot mouse press en deux boucle "while" en parallele.

Je pense avoir trouve la bonne methode pour les whiles en parallele. J.ai fait un pool de thread m.

Plus de blocage de boucle et je peu meme temporise mes while avec des threadsleep different.

Code:

---

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

.........   if (e.getButton() == MouseEvent.BUTTON2) { Main.rightClick = true; }   if (e.getButton() == MouseEvent.BUTTON1) { Main.left = true; }   executorService.submit(() -> { try { Robot robot = new Robot();   while (Main.rightClick && Main.left && compteur < nballe) {   robot.mousePress(InputEvent.BUTTON1_DOWN_MASK); System.out.println("ClickLeftAuto"); if (e.getButton() != MouseEvent.BUTTON1 ) { return; } Thread.sleep((long) ((long) 1025 / rateoff)); compteur++; System.out.println("compteur++"); } }catch (Exception e1) { e1.printStackTrace(); } });   executorService.submit(() -> { try { Robot robot = new Robot(); Point point;   while (Main.rightClick && Main.left && compteur < nballe) { point = MouseInfo.getPointerInfo().getLocation(); robot.mouseMove(point.x, point.y); if (e.getButton() != MouseEvent.BUTTON1 ) { return; } Thread.sleep((long) ((long) 100 / rateoff)); // System.out.println("NoRecoil-off");   } }catch (Exception e1) { e1.printStackTrace(); } });     reste du code .............

---

Cordialement

Fred

Bonjour,

Je pensais avoir regle le probleme mais en faite non.


Certe ceci est beaucoup moins frequent que avant mais

Par moment ca ce bloque en while infini.

J.ai essaye pas mal de chose mais je doit passe a travers l.essentiel


Merci

Fred

Bonjour,

Je reviens vers vous pour mon problème de clic infini.




Personne a une petite idée pour comment évite cela.


Merci


Fred

Salut,

1. Concurrence d'accès à une variable
   
   La valeur d'une même variable modifiée dans un thread peut ne pas être vue modifiée dans un autre threadpour des raisons d'optimisation de la JVM (Il y a un cache de valeurs dans chaque thread).
   
   Lorsqu'une variable peut être modifiée et lue par plusieurs threads, il y a risque de concurrence d'accès en plus.
   
   Plusieurs solutions possibles (et alternatives) :
   
   1. Déclarer la variable volatile désactive le cache et met la variable dans une zone partagée entre threads.
   2. Procéder à des accès synchronisés (dans des blocs synchronized (sur une instance d'objet), ou par méthodes synchronized) permet de protéger contre la concurrence d'accès (un seul thread) et garanti que les modifications de valeurs faites dans un thread sont vues dans les autres
   3. Utiliser des types d'objets orientés concurrence d'accès, comme AtomicBoolean par exemple au lieu d'un booléen.
2. partage de variable entre portées (scope).
   Avant Java 8, il n'était pas possible d'écrire quelque chose comme :
   
   
   Code:

   ---

   1 2 3 4 5 6 7 8 9 10 11 12

   public void methode1() { Object variable = new Object(); // une variable déclarée dans la portée locale de methode 1   UneClasse instance = new UneClasse() { // une instance de classe anonyme stockée dans une variable déclarée dans la portée locale de methode1   public void methode2() { jeFaisUnTrucAvec( variable ); // utilisation dans la portée locale de methode2 d'une variable de portée locale à methode1 (donc une autre portée) }   } }

   ---

   Ce code ne compilait pas. Parce que variable est déclarée dans la portée locale de la méthode methode1. La syntaxe Java permet tout de même que cette variable soit visible de la méthode methode2 (c'est possible pour les classes anonymes et locales, en variables membres ou de méthode définie à cet endroit), si et seulement si elle est déclarée final (on ne peut donc modifier la valeur de la variable).
   Java 8 a introduit le concept de "effectively final". Le compilateur considère que si la variable n'est effectivement pas modifiée dans la méthode (methode1) alors elle est final : on n'est donc pas obligé de mettre explicitement le mot final dans la déclaration de la variable.
   
   Le corollaire de ça c'est que si la variable est final, c'est que la valeur de la variable ne peut être modifiée.
   Dans ton code, on devine que e est un événement. Et que tu déclenches tes deux processus dans un écouteur d’événements de souris. Même si la variable s'appelle e pour deux événements différents, ce n'est pas la même variable. En revanche, le e dans le code suivant est bien le e de l'évènement qui appelle le executorService.submit().
   
   
   Code:

   ---

   1 2 3 4 5 6 7 8 9 10 11

   executorService.submit(() -> { try { Robot robot = new Robot();   while (Main.rightClick && Main.left && compteur < nballe) {   robot.mousePress(InputEvent.BUTTON1_DOWN_MASK); System.out.println("ClickLeftAuto"); if (e.getButton() != MouseEvent.BUTTON1 ) { return; }

   ---

   Ton code compile parce que e est effectivement final et que, donc, e ne change pas et les états de e non plus. Donc e.getButton() ne change pas entre ce test :
   
   Code:

   ---

   1 2 3 4 5

   if (e.getButton() == MouseEvent.BUTTON1) { Main.left = true; } }

   ---

   et ce test :
   
   Code:

   ---

   1 2 3

   if (e.getButton() != MouseEvent.BUTTON1 ) { return; }

   ---

   Comme le second ne sera exécuté que si le premier est exécuté au moins (parce que while (Main.rightClick && Main.left && compteur < nballe) {, il est parfaitement inutile (e.getButton() ne peut être à la fois égal à MouseEvent.BUTTON1 et différent de MouseEvent.BUTTON1 !). Main.left est suffisant pour stocker le fait que le bouton 1 de la souris est enfoncé (comme il vaut true).
   
   
   
3. Des événements.
   Si de manière globale, il y a évidemment une différence entre un événement physique (un mec qui appuie sur un bouton d'une souris) et un événement logique (dans une API qui utilise cette notion). Toutefois le but d'un langage de haut niveau est de supprimer la complexité. Du point de vue du programmeur, il doit pouvoir faire abstraction de tous les processus techniques et n'avoir qu'à écrire le code qui doit être exécuté lorsqu'on appuie sur un bouton de souris, voire même de préférence lorsqu'on déclenche une action par exemple (donc quelque chose qui peut être déclenché par un appui sur un bouton de souris, un contact sur un écran tactile, l'appui d'une touche de clavier, un cri dans un micro et le franchissement d'un rayon laser, etc, etc). Il n'y aucune raison que le simulateur Robot simule des événements de souris qui ne soit pas traité par Swing comme des événements de souris.
   Ton code fait donc en résumé :
   
   Code:

   ---

   1 2 3 4 5 6 7 8

   si ( on appui sur le bouton de la souris ) { lancer un thread qui { tant que le bouton de la souris est appuyé faire comme si on appuyait sur le bouton de la souris attendre fin tant que } }

   ---

   A noter par ailleurs que appuyer sur le bouton de la souris sous-entend appuyer. Pas relâcher. Ce qui se fait explicitement par robot.mouseRelease().
   
   Je pense que l'approche globale n'est pas la bonne approche. Je mettrai en place une approche plutôt comme ça :
   
   
   1. Lorsqu'on appui sur bouton de droite, on active un écouteur d’événement. Lorsque la bouton est relaché, l'écouteur est désactivé. Cette activation/désactivation peut se faire par enregistrement/désenregistrement de l'écouteur, ou par booléen. Perso, je choisirais la première solution
   2. L'écouteur d’événement en question écoute le bouton de gauche de la souris. Plus exactement l'évènement release de ce bouton : lorsque cet événement est entendu, on force un mousePress. Ainsi, chaque fois que l'humain qui manipule la souris va cliquer sur le bouton gauche, le bouton va redescendre.
   3. Maintenant, tu cherches à faire des clics répétés donc une succession de mousePress et mouseRelease, séparés chacun par un délai (press délai 1 release délai 2 press délai 1 release etc).
      donc en plus de forcer le mousePress, il s'agit de lancer une tâche à intervalle régulier (délai1 + délai2) qui fait :
      
      1. mousepress button1
      2. attendre délai1
      3. mouserelease button1
      
      Et lorsque le bouton droit est relaché, on tue cette tâche.
      Il faut également que le forçage de mousePress ne se fasse pas pendant que la tâche s'exécute (on peut utiliser le même mécanisme d'enregistrement/désenregistrement que pour la réaction au bouton de la souris, mais il faut avoir un booléen au moins pour savoir si le processus est actif.
      
      En résumé :
      
      1. écouteur rightButton :
         
         1. si rightButton pressed, alors processus=true + écouter leftButton release + scheduler tâche à intervalle délai1 + délai2
         2. si rightButton released, alors processus=false + arrêter écoute de leftButton release + tue tâche schédulée simulation clic gauche
      2. écouteur leftButton :
         
         1. si mouseRelease, simuler leftButton pressed
         
         
      3. la tâche =
         
         1. arrêter écoute leftButton
         2. simuler leftButton pressed
         3. attendre délai1
         4. simuler leftButton release
         5. relancer écoute leftButton
         
         ajouter simple que chacune de ses instructions ne doit être exécutée que si processus==true
      
      
      
   
   
   
   

Bonjour,

Merci pour toute ces precieuse information.


Je vais prendre bien le temps d'etudier tout cela.

Cordialement

Fred

Bonjour,

Encore moi XD,

Sur papier sa semblais assez facile, mais en realite...

Je patoge dans la semoule complet

J'ai essaye plusieur facon de faire mais rien concluant.

Je n'es pas assez de competence necessaire pour applique ce que vous m.avez propose.

Pouvez vous me guide avec quelque exemple pour que j.arrive a quelque chose?

Je vous remercie

Fred

Bonsoir,

Je reviens vers vous pour une autre solution envisageable( peu etre).

J.ai cru comprendre en parcpurant le net, en long, en large et travers que je pourrai peu etre au liei d.utilise la class robot, d.utilise directement une dll de windows.

D'apres mes lecture, si je venais a faire cela je perd la portabilite vers d.autre plate forme.
Point qui ne me derange pas puisque l.appli que je developpe est exclusivement pour moi suite a des probleme de mobilite.

Avant d.effectue mille recherche, je me demandais si effectivement c.etais possible.


Je vous remercie d.avance.

Cordialement


Fred