compte tour sur ecran

On est donc d'accord...

8 datats en entrée en bidirectionel ça donne 8 datas en entrée monodirectionel !!! Purée ... on est fort ! ;-))
Reply to
GzavSnap
Loading thread data ...

"GzavSnap" a écrit dans le message de news: 4a4d06fa$0$22405$ snipped-for-privacy@news.free.fr...

ah oui, je suis long a la detente !

Reply to
jlp

Oui, le ralentir le plus possible, puis valider en faisant "entrée"...

Reply to
GzavSnap

Mais cela interdit l'utilisation de la souris lors de l'utilisation du "clique" à gauche ! ça va cliquer partout sur la fenêtre ! Le bouton de droite serai mieux...

Reply to
GzavSnap

GzavSnap se fendait de cette prose :

Pourquoi ? Il suffit de rester dans la config qui convient !

--
LeLapin
Reply to
LeLapin

GzavSnap se fendait de cette prose :

Ca va ouvrir des menus contextuels partout sur la fenêtre !

--
LeLapin
Reply to
LeLapin

Oui ! C'est pour celà que ce n'est pas le meilleur des choix. On peut aussi utiliser une deuxième souris... ... forcer le plein écran lors du compatage... mais il faut un inter pour isolé le capteur pour utiliser la souris seullement lors de l'utilisation.

Reply to
GzavSnap

Je pense que le coup de la souris, c'est carrément foireux. 'suffit que l'imprévisible (genre le screensaver se lance, un message de windows qui prend le focus, ou que sais-je..) s'en mêle et ça va foirer grave.

Utilisez un pic et le port série. Tout simplement. Ça fais quand même carrément moins bricolage !

-- cLx

Reply to
cLx

GzavSnap se fendait de cette prose :

Et pourquoi ne pas utiliser le troisième bouton ?

--
LeLapin
Reply to
LeLapin

i

me

Je suis d'accord, la gestion de la souris par le systeme est beaucoup moins controlable par un programme, donc moins fiable, que les infos en provenance d'un port I/O ...

Reply to
Jean-Christophe

Ca ne resoud pas le probleme : le systeme va gerer les messages de souris et eventuellement les rediriger vers une autre fenetre, le prog ne les recevra pas toujours, et ca va etre le souk.

Bien sur on peut contourner cela en capturant les messages systeme en provenance de la souris pour forcer leur redirection vers le prog avec les fonctions SetCapture() et ReleaseCapture() mais on va finir par monter une usine a gaz ... c'est pas tip-top.

De plus un message souris n'a pas vraiment une priorite realtime, donc on risque de carrement perdre des pulses ... ca craint !

Je donne quand meme le detail de ces fonctions:

SETCAPTURE : The SetCapture function sets the mouse capture to the specified window belonging to the current thread. Once a window has captured the mouse, all mouse input is directed to that window, regardless of whether the cursor is within the borders of that window.

RELEASECAPTURE : The ReleaseCapture function releases the mouse capture from a window in the current thread and restores normal mouse input processing.

Reply to
Jean-Christophe

J'y pense jamais à celui là ! mdr... j'en ai pas sur ma souris !

Surtout que notre Windows met en buffer les cliques lors de l'attente d'affichage/accès disque ... C'est pas trop bon pour un programme de gestion direct... Pour le comptage c'est moins grave.

En Direct input. Et ça complique tout! Pour une appli. Vb... avec une gestion du "sub fom1_click ( ) ", le résultat est aléatoire et dépend des temps d'attente au niveau des rafraîchisement de cette fenêtre. ( avec des DoEvents partout!)

Je ne pense pas vu que les données sont tomponnées... mais ça risque de décaller un bon nombre de donnée reçues.

Reply to
GzavSnap

Oui... Mais utiliser une souris permet d'addapter le montage sous diffèrents protocols... série, USB, PS2 ... sans changer la programmation... car le driver s'occupe du reste. On n'a pas à intervenir sur les IRq de chaque port. C'est le plus simple en programmation. Et le cahier des charges n'implique pas de connaissances en électronique... seulement courcircuiter un contact sec NO Le déporter sur une prise Jack sur la souris... Il est même plus simple que les boutons d'un joystick! en prise joystick/USB

Reply to
GzavSnap

Jean-Christophe se fendait de cette prose :

Attends mais tu vas où là ? On écrit une appli de dix lignes en n'importe quel langage dans un gros bouton qui incrémente à chaque fois qu'on clique, et on affiche le tout en très gros, point !

--
LeLapin
Reply to
LeLapin

ut en

Zut, tu veux dire que j'aurai saute des lignes ? Si c'est le cas : desole ... si, si.

Je croyais qu'il s'agissait de compter des impulsions en utilisant la souris comme organe d'entree, oui ? Si c'est le cas, alors mes remarques sont valables : il faut capturer les messages de la souris pour forcer leur destination vers le programme qui va compter les impulsions, sinon le systeme dirige les messages de la souris vers la fenetre qui se trouve sous le curseur de la souris, et le prog ne les recoit pas. Et dans ce cas, autant utiliser un autre organe d'entree. (port I/O)

Reply to
Jean-Christophe

Jean-Christophe se fendait de cette prose :

Si tu mets ton appli en plein écran et que tu détectes la souris sur le fond de la fenêtre ça marche aussi ! Sinon tu peux même utiliser des trucs genre setfocus et lostfocus, pour que le focus ne sorte jamais de ta fenêtre.

--
LeLapin
Reply to
LeLapin

le

que

Ok, je pensais qu'il voulait injecter un signal tout-ou-rien via un hack du hard de la souris ... autant pour moi. Dans le cas d'un click souris alors tout ca devient trivial ;-)

Reply to
Jean-Christophe

que

Heu... moi aussi je le pensais ! Bon, désolé Jean-Christophe.... pas de PIC. Mais je parle aussi du "via un hack du hard de la souris ", On met un interrupteur en parallèle avec le micro-switch de la souris... et c'est twické... Ca simule l'appuie phisique du bouton avec un doigt ! ... ça fait comme si que ... quoi ! Le sytème y croit qui c'est nous ... mais bon... c'est l'aimant de l'interrupteur magnétique! (en faît !!!!) Mais, sur le focus de la fenêtre... pas de problème. Il se gère avec l'intercéption de l'événement :

sub form1.MouseDown(...) si appuie sur bouton#2 alors compter=compter+1 end sub (c'est tout simple!)

Pas besoin de passer par l'IRQ, c'est le driver qui s'occupe du reste!

Reply to
GzavSnap

Ca y est ! J'ai fait un programme d'exemple avec la clique droite de la souris... ... et c'est loin d'être simple. C'est plus compliqué que ça en a l'air. Le Vb renvoie tous les doubles cliques vers une routine qui de donne pas l'orgine de l'action... tous les bouton en double clique sont renvoyé vers form_dblclick() ! Résultat, il faut utiliser Direct input ! Mais, là encore un autre problème. A chaque scan du clique, le compteur va s'incrémenter. Tout comme le joystick, un appuie sur le bouton pendant 1 seconde va donner un "5215" au compteur. Il faudra ruser un peut, capturer le front montant et invalider l'info lors d'un relachement de la souris. L'exemple sous gdi est dispo ici :

formatting link

J'ai aussi retrouver un exemple de PcTeam avec le "inpout32.dll" en RS232 :

formatting link
(Il y a la les doc sur les branchements de la Rs232) Cet exemple pourra visualiser le changement d'état des registres sur la RS323.

Reply to
GzavSnap

Bonjour =E0 tous,

suite =E0 mon premier exemple, en VB, utilisant le port COM comme entr=E9e (voir plus haut dans ce thread), voici un exemple complet (3 compteurs) sur le m=EAme principe

formatting link
(avec sources, dll et executable),

o=F9 j'ai ajout=E9 des boutons "start" et "stop" qui lancent et arr=EAtent le chrono et les comptages, ainsi qu'un champ de saisie "tours" qui permet de d=E9finir le nombre de tours...

lorsque l'on appuie sur "start", cela re-initialise =E0 z=E9ro le chrono et les compteurs, puis lance le chrono et les comptages...

lorsqu'un compteur arrive au nbr de tours =E0 faire, il s'affiche, en dessous du compteur, son temps/chrono...

lorsque les 3 compteurs sont arriv=E9s au nbr de tours, ou bien lorsque l'on clique sur "stop", le chrono s'arr=EAte...

il faut connecter les 3 boutons poussoirs (des compteurs) au port com/rs232 ainsi:

- compteur 1 : BP entre les pins 1 (DCD) et 3 (TXD)

- compteur 2 : BP entre les pins 4 (DTR) et 6 (DSR)

- compteur 3 : BP entre les pins 7 (RTS) et 8 (CTS)

sans =E7a, c'est sur, le chronom=E9trage n'est pas exact* (d=E9pend des ressources du PC...entre autres...), mais la marge d'erreur est commune aux 3 compteurs... on pourrait s=FBrement am=E9liorer la pr=E9cision, en, par exemples, utilisant l'horloge interne du PC comme base de temps pour les secondes...ou en augmentant le "Thread Priority"....ou en n'affichant pas le d=E9filement des centi=E9mes pendant le chronom=E9trage...

bon'soir=E9e, vede ;O]

  • ne correspondra pas =E0 l'affichage d'un chrono temps r=E9=E9l...
Reply to
vede

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.