Je sais qu'avec Sendkeys on mime les événements claviers mais quelle est la chaine de caractère qui correspond à la touche "Windows" du clavier ?

Ctrl + Echap
 
(en tout cas, ça fait pareil)

ça fait pareil niveau utilisateur pour la pression simple sur la touche Win, mais si tu fais Ctrl+Esc+E t'as pas l'explorateur, alors que Win+E tu l'as

Mais nan, mais c'est parceque t'es pas assez rapide
 
A priori, doit pas y avoir de code derrière la touche windows, je pense que c'est plutôt une macro géré par le processeur du clavier. (oui oui, y'a un processeur dans un clavier)

 
parce que tu y arrives, toi ?  
 
Je pense pas que ce soit géré par le clavier, c'est comme les touches multimedia, ce sont des codes différents des touches habituelles...

Ben nan, j'y arrive pas, mais moi non plus je suis pas assez rapide
 
Sinon, ouais, pour les codes différents...
 
Mais euh... Normalement, un clavier, ça envoie bien un code ASCII non ?
Hors, un clavier standard permet déjà de couvrir l'intégralité du ASCII étendu (soit 1 byte), sans pour autant en générer un seul de plus.
 
Donc j'ai du mal à concevoir que les contrôlleurs claviers de 386 par exemple aient prévu de passer sur 2 bytes pour gérer des touches qui n'existaient pas à l'époque. Hors un clavier Windows/multimédia fonctionne très bien sur un tel PC.

Sinon tu peux utiliser AutoIt ou AutoItX (controle Active X) pour simuler cette touche !
 
http://www.hiddensoft.com/AutoIt/

Minute là papillon, les codes ne sont pas les même suivant si tu intercepte KeyPress (code ascii) ou KeyUp/KeyDown (code touche clavier)
 
Le code clavier renvoyés pour la touche Windows de gauche est 91 (puis 92 et 93 pour les touches de droite: Windows et menu contextuel).

Ne t'emmerde pas et utilise AutoItX
Tu peux simuler les touches Windows via les paramètres LWIN et RWIN, y'a 2 vbs d'exemples livrés avec !

 
Aucune idée... En tout cas sous Windows tu reçois plus qu'un byte... t'as un int contenant le n° de la touche + une partie d'un autre param pour des infos supplémentaires
 
edit: bah voilà, c'est ce que dit Drasche, y a deux events différents

OK. Ben en regardant de plus près à quoi ressemble la table ASCII, on voit que 91 = [
Hors, [ = ESC + 40h
Hors, CTRL, si mes souvenir sont bon, c'est bien un offset de 40h (et shift de 20h)
 
Donc c'est bien ça.
 
Seulement, lorsqu'on appuie sur les touches shift, ctrl, alt et alt gr, ça envoie un second byte contenant leurs status. (en fait, quand on appuie sur une touche, le clavier envoie 2 bytes, un pour la touche du clavier, et l'autre pour les touches de contrôle).
 
Donc le drivers clavier, pour faire la différence entre le pressage d'une touche à la con ou d'une combinaisont normale, il a juste à vérifier si une touche de contrôle a été appuiée.
 
Ca fait combien le code ASCII de Windows + E ?
Moi je vote pour c0h

 
t'avais dit 141h

La touche Windows n'a pas l'air d'être détectée par le OnKeyPress, mais juste par le OnKeyDown/OnKeyUp où on a les codes 91 & 92
 
Par contre [ donne OnKeyPress = 91 (ASCII), mais OnKeyDown = 221 (du moins sur clavier belge, sur le clavier français il est sur une autre touche donc le code sera différent)
la valeur élevée est due à la présence du ctrl & alt (= altgr) je suppose

Vi, mais je m'étais planté
 
J'avais fait un offset avec ctrl et puis j'avais écrit en décimal au lieu d'héxa

j'arrive pas à intercepter le code du ctrl+esc

Bah... Chais pas.
 
EN tout cas, certain, ESC = 27 (ou 1Bh) et il me semble que CTRL = offset de 40h mais j'en suis pas certain.
 

 
j'ai la même chose avec ou sans Ctrl

ha ? ben alors ça fait pas d'offset
 
je croyais
 
doit y avoir que shif qui fait un eoffset en fin de compte

Ouais parce que le code ASCII de 'a' est pas le même que 'A', c'est comme '^A' qui vaut 1, c'est son code ASCII, donc y a un décalage au niveau de l'ASCII mais c'est tout, dans le KeyDown Shift+A = A