Désactiver Shift au démarrage

En cherchant, j'ai trouvé ceci et cette fois, ça marche pour moi:
http://bytes.com/topic/access/answers/683164-disable-enable-shift-key


Léila wrote:

Bonjour à tous et meilleurs voeux pour l'année 2010.
Je souhaite désactiver l'action de la touche MAJ au démarrage d'une
base et j'ai trouvé sur le site de 3stone le code suivant:
http://www.3stone.be/access/articles.php?lng=fr&pgh
Mais malheureusement ça ne fonctionne pas. Ce code utilise la macro
AutoExec pour son exécution mais on peut lire dans la partie
"REMARQUES" de cette page que le maintient de la touche MAJ enfoncée
ignore la macro AutoExec:
http://office.microsoft.com/fr-fr/access/HA103362391036.aspx Résultat: On
n'arrive finalement pas à empêcher l'action de la touche
MAJ. Or justement j'ai besoin d'empêcher cette action. Avez-vous une
astuce? Merci de votre aide.

Salut,

Léila wrote:

Je souhaite désactiver l'action de la touche MAJ au démarrage d'une
base et j'ai trouvé sur le site de 3stone le code suivant:
http://www.3stone.be/access/articles.php?lng=fr&pgh
Mais malheureusement ça ne fonctionne pas.

Balivernes ! Bien sûr que ce code fonctionne !

Tu penses vraiment être la première à l'utiliser ?!?

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

3stone wrote:

Salut,

Léila wrote:

Je souhaite désactiver l'action de la touche MAJ au démarrage d'une
base et j'ai trouvé sur le site de 3stone le code suivant:
http://www.3stone.be/access/articles.php?lng=fr&pgh
Mais malheureusement ça ne fonctionne pas.

Balivernes ! Bien sûr que ce code fonctionne !

Pardon, mon intention n'était nullement de t'offusquer. Je relate seulement
ce que j'ai constaté chez moi.
Tiens par exemple, j'ai trouvé un code pour arrêter Windows. Chez moi, il
fonctionne bien. Je l'ai testé sur 3 autres machines. Sur l'une il
fonctionne bien aussi mais sur les deux autres, rien à faire ça ne marche
pas. Et les deux avaient quelque chose en commun: Windows XP Edition Media
Center. Ainsi chez moi, la fenêtre de la base continue de s'afficher malgré
la présence de ton code et de la macro AutoExec telle que tu l'as indiquée,
lorsque j'appuie sur la touche MAJ au démarrage.

Tu penses vraiment être la première à l'utiliser ?!?

Il fonctionne certainement bien chez d'autres.

Léila a écrit, le 01/01/2010 22:34 :

En cherchant, j'ai trouvé ceci et cette fois, ça marche pour moi:
http://bytes.com/topic/access/answers/683164-disable-enable-shift-key

Finalement, la seule différence qui apparaisse lors d'un rapide survol,
est qu'avant de modifier la valeur d'une propriété on la détruit. ç a
doit être pour contourner un "bug" des dernières versions.

3stone a écrit, le 02/01/2010 13:21 :

Salut,

Léila wrote:

Je souhaite désactiver l'action de la touche MAJ au démarrage d'un e
base et j'ai trouvé sur le site de 3stone le code suivant:
http://www.3stone.be/access/articles.php?lng=fr&pg=68
Mais malheureusement ça ne fonctionne pas.

Balivernes ! Bien sûr que ce code fonctionne !

Tu penses vraiment être la première à l'utiliser ?!?

Ils ont dû se mélanger les pinceaux, chez Microsoft, pour que mainten ant
on ne puisse plus modifier la valeur d'une propriété, sans l'avoir
détruite au préalable. A moins qu'il y ait une raison "by design". Ou
que ça ait à voir avec le fait que la page Microsoft mentionnée par
Leila refuse de s'afficher si on n'a pas de produit Office d'installé,
ou qu'on ne laisse pas au script le temps de s'exécuter.

Au fait, 3stone, n'y a-t-il pas quelque chose de surprenant dans le
principe, à déclencher par autoexec un code qui vise à empêcher
l'exécution d'autoexec ? D'accord que c'est pour la session suivante .. .
N'empêche, ça doit faire charger la base une fois de plus, non ?

Salut,

Léila wrote:

Pardon, mon intention n'était nullement de t'offusquer. Je relate

Je ne suis pas "offusqué" ;-)

Mais ton message laisse croire que le code est boiteux !
Or, c'est ta version qui est boiteuse et beuguée - ce qui est très différent!

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Salur Gloops,

Gloops wrote:
[...]

Ils ont dû se mélanger les pinceaux, chez Microsoft, pour que
maintenant on ne puisse plus modifier la valeur d'une propriété, sans
l'avoir détruite au préalable. A moins qu'il y ait une raison "by
design". Ou que ça ait à voir avec le fait que la page Microsoft
mentionnée par Leila refuse de s'afficher si on n'a pas de produit
Office d'installé, ou qu'on ne laisse pas au script le temps de
s'exécuter.

MS a l'habitude de pousser les utilisateurs vers là ou il le souhaite ;-)
Certains beugs/disfonctionnements/incohérences sont connus très
rapidement et ne sont pourtant jamais corrigés.
Ils sont alors effectivement classés "by disign" ;-)

Perso, je n'ai pas la nécessité de suivre ce mouvement, Access
n'ayant jamais (dû) contribué à me faire vivre... j'utilise donc une version
qui me donne satisfaction.

Au fait, 3stone, n'y a-t-il pas quelque chose de surprenant dans le
principe, à déclencher par autoexec un code qui vise à empêcher
l'exécution d'autoexec ? D'accord que c'est pour la session suivante
... N'empêche, ça doit faire charger la base une fois de plus, non ?

Il y a erreur...
le code empêche (entre autres) l'utilisation de la touche Shift et non
pas le déclenchement de l'autoexec !

Par ailleurs, la macro autoexec est la seule "fonction" qui permet
d'effectuer une action au démarrage d'une base Access.
Pour cela, elle est la seule macro qui est justifiée, voir indispensable,
et tout le reste devrait se faire exclusivement via le code (idéalement)

Or, vu les choix de MS, ils ont été quasiment obligé de mettre en avant
ces macros que je considère d'un autre age :-(
C'est une des raisons, parmis d'autres, qui fait que je n'ai pas adopté
A2k7 comme version de travail pour mon propre usage.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

Salutations à tous et meilleurs voeux

Je vais retenir la dernière phrase : « C'est une des raisons, parmis
d'autres, qui fait que je n'ai pas adopté A2k7 comme version de travail pour
mon propre usage. »
* pour mon propre usage *

Oui, et on travaille parfois pour des sociétés *bizarres* où l'informatique
est sous-traitée par une société tierce ou fille, soeure ou cousine qui
oblige le saut A2Kx vers A2K7, sans assurer le SÀV (ils en sont incapables
!).

Heureusement, "on" commence à voir que la sous-traitance entraine une
dépendance et surtout un manque de maitrise sur le futur.
Accepteriez-vous, dans votre maison, qu'un tiers engagé pour résoudre vos
problèmes de chauffage, vous impose par exemple une chaudière avec tel ou
tel combustible en changeant tous les trois ou quatre ans ?, par son bon
vouloir ?

cdt,
Blaise

"3stone" <home@sweet_home.be> a écrit dans le message de news:
e4k07gVjKHA.4048@TK2MSFTNGP06.phx.gbl...

Salur Gloops,

Gloops wrote:
[...]

Ils ont dû se mélanger les pinceaux, chez Microsoft, pour que
maintenant on ne puisse plus modifier la valeur d'une propriété, sans
l'avoir détruite au préalable. A moins qu'il y ait une raison "by
design". Ou que ça ait à voir avec le fait que la page Microsoft
mentionnée par Leila refuse de s'afficher si on n'a pas de produit
Office d'installé, ou qu'on ne laisse pas au script le temps de
s'exécuter.

MS a l'habitude de pousser les utilisateurs vers là ou il le souhaite ;-)
Certains beugs/disfonctionnements/incohérences sont connus très
rapidement et ne sont pourtant jamais corrigés.
Ils sont alors effectivement classés "by disign" ;-)

Perso, je n'ai pas la nécessité de suivre ce mouvement, Access
n'ayant jamais (dû) contribué à me faire vivre... j'utilise donc une
version
qui me donne satisfaction.

Au fait, 3stone, n'y a-t-il pas quelque chose de surprenant dans le
principe, à déclencher par autoexec un code qui vise à empêcher
l'exécution d'autoexec ? D'accord que c'est pour la session suivante
... N'empêche, ça doit faire charger la base une fois de plus, non ?

Il y a erreur...
le code empêche (entre autres) l'utilisation de la touche Shift et non
pas le déclenchement de l'autoexec !

Par ailleurs, la macro autoexec est la seule "fonction" qui permet
d'effectuer une action au démarrage d'une base Access.
Pour cela, elle est la seule macro qui est justifiée, voir indispensable,
et tout le reste devrait se faire exclusivement via le code (idéalement)

Or, vu les choix de MS, ils ont été quasiment obligé de mettre en avant
ces macros que je considère d'un autre age :-(
C'est une des raisons, parmis d'autres, qui fait que je n'ai pas adopté
A2k7 comme version de travail pour mon propre usage.

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)

3stone a écrit, le 04/01/2010 17:09 :

Au fait, 3stone, n'y a-t-il pas quelque chose de surprenant dans le
principe, à déclencher par autoexec un code qui vise à empêche r
l'exécution d'autoexec ? D'accord que c'est pour la session suivante
... N'empêche, ça doit faire charger la base une fois de plus, non ?

Il y a erreur...
le code empêche (entre autres) l'utilisation de la touche Shift et no n
pas le déclenchement de l'autoexec !

Je me suis (un peu ?) loupé sur l'expression, je m'en suis rendu compte
après et puis je me suis dit ... que le lecteur allait corriger :)

En fait, le code vise à empêcher ... d'empêcher, l'exécution d'au toexec,
non ?
Donc on pourrait dire, avec disons un meilleur style, à obliger
l'exécution d'autoexec (c'est-à-dire que l'autoexec s'exécutera que la
touche shift soit enfoncée ou pas). On peut utiliser la touche shift,
simplement elle n'empêche pas l'autoexec de s'exécuter :)

Ce que je voulais dire, c'est que si tu mets ton code dans l'autoexec,
il faudra redémarrer la base pour changer la variable, pour que
l'exécution de l'autoexec soit obligatoire la fois d'après. Pas vrai ?

Enfin à moins de taper autoexec dans la fenêtre d'exécution, mais d ans
ce cas un autre nom aurait aussi pu faire l'affaire.

Une fois que la variable (enfin ... la propriété de la base) a été
changée, elle garde sa valeur jusqu'à ce qu'on intervienne explicitem ent
en sens inverse, non ? Donc, l'exécution du code une bonne fois pour
toutes est suffisante, me semble-t-il ?

Salut,

Gloops wrote:
[...]

Ce que je voulais dire, c'est que si tu mets ton code dans l'autoexec,
il faudra redémarrer la base pour changer la variable, pour que
l'exécution de l'autoexec soit obligatoire la fois d'après. Pas vrai ?

Enfin à moins de taper autoexec dans la fenêtre d'exécution, mais dans
ce cas un autre nom aurait aussi pu faire l'affaire.

Une fois que la variable (enfin ... la propriété de la base) a été
changée, elle garde sa valeur jusqu'à ce qu'on intervienne
explicitement en sens inverse, non ? Donc, l'exécution du code une
bonne fois pour toutes est suffisante, me semble-t-il ?

Si l'on prévoit une méthode de basculement de la propriété
dans la base, cela permet de ne jamais oublié son activation ;-)

Ceci dit, ma macro autoexec ne fait (habituellement) qu'une
seule chose... appeler une fonction !

Là, sont géré les barres d'outils, les backups si nécessaire,
les liens vers la dorsale, les vérifications de versions, etc...
le tout avec gestion et sauvegarde des éventuelles erreurs.
La gestion de quelques propriétés n'y est que accessoire ;-)

Tout cela est impossible à réaliser avec des macros Access.

Ce qui aurait été bien, est un enregistreur de macro (code vba)
comme le fait Excel, mais...

--
A+
Pierre (3stone) Access MVP
Perso: http://www.3stone.be/
MPFA: http://www.mpfa.info/ (infos générales)