Discussion :

[Hemgé]

Bonjour,

Je cherche le moyen le plus propre et le plus efficace pour intercepter la flèche vers le haut (VK_UP) et son "équivalent" shift + TAB.

La solution classique consiste en deux étapes :
- détecter l'appui sur une touche avec une fonction Evénement qui intercepte WM_KEYDOWN (256), puis à
- identifier la touche enfoncée ou la combinaison de touches enfoncées via la fonction ToucheEnfoncée.
Certains utiilsent aussi _EVE.WPARAM.

Le "surcharge" système est donc double :
- WM_KEYDOWN intercepte toutes les frappes clavier ;
- ToucheEnfoncée teste donc également toutes les frappes.

Idéalement, la fonction Evénement ne devrait réagir qu'à VK_UP.

L'idéal serait donc d'avoir une fonction globale du type :
Evénement(NomProcédure, "*.*", VK_UP)

Apparemment, le message VK_UP n'est pas traité par la fonction Evénement.
Je précise que les deux fichiers de constantes KEYCONST.wl et WINCONST.wl sont bien déclarés.

Curieux de savoir si Evénement n'utilisait que le fichier WINCONST.wl, j'ai enrichi ce dernier des valeurs VK_UP et VK_TAB, mais sans succès.

Confirmez-vous qu'effectivement VK_UP ne peut-être intercepté directement?

L'un(e) de vous dispose-t-il d'informations plus complètes sur le fonctionnement de la fonction Evénement et sur ce qu'elle intercepte ?

De même, à votre connaissance, Evénement peut-elle traiter une combinaison de messages autrement que via une combinaison du style ToucheEnfoncée(teShift) ET ToucheEnfoncée(VK_TAB) ?

Déjà merci

Hmgé

[jimmypage]

Salut,

VK_UP n'est pas un message windows mais une constante correspondant à la valeur héxa de la touche "haut".

Tu ne peux intercepter par la fonction que des messages windows (par exemples ceux de la liste (non exhaustive) fournie dans le WINCONST.wl .

Je ne pense pas que ToucheEnfoncée teste toutes les frappes clavier mais elle te renvoie l'état de la touche à un moment t.
Donc par la combinaison de ton Evenement et de toucheEnfoncée tu dois pouvoir attraper les évènements que tu souhaite!

un exemple à la viteufé

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Evenement("ProcedureKEYDOWN","MaFenetre.*",WM_KEYDOWN)
 
 
PROCEDURE ProcedureKEYDOWN ()
  SI _Eve.wParam=VK_UP _OU_ _Eve.wParam=VK_TAB _OU_ _Eve.wParam=VK_SHIFT ALORS
    SI _Eve.wParam=VK_UP ALORS procedureAction()
    SI _Eve.wParam=VK_TAB ALORS
      SI ToucheEnfoncée(shift) ALORS procedureAction()
    FIN
    SI _Eve.wParam=VK_SHIT ALORS
      SI ToucheEnfoncée(tab) ALORS procedureAction()
    FIN
  FIN
FIN

[DelphiManiac]

Voilà comment je procède :

Dans le code d'initialisation de la fenêtre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Evénement(_appuiTouche, ".*", WM_KEYUP)

et la procédure qui gère ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
PROCEDURE _appuiTouche(MessageWindows, wParam, lParam)
touche est un entier = wParam
shift est un booléen = AppelDLL32("USER32", "GetAsyncKeyState", VK_SHIFT) <> 0
control est un booléen = AppelDLL32("USER32", "GetAsyncKeyState", VK_CONTROL) <> 0
SI ((touche = VK_F4 _ET_ PAS shift _ET_ PAS control) _OU_ 
	(touche = Asc("R") _ET_ PAS shift ET control)) ALORS
	_executeF4(ChampEnCours())
	RENVOYER 0
FIN

[jimmypage]

Voilà comment je procède :

Dans le code d'initialisation de la fenêtre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Evénement(_appuiTouche, ".*", WM_KEYUP)

et la procédure qui gère ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
PROCEDURE _appuiTouche(MessageWindows, wParam, lParam)
touche est un entier = wParam
shift est un booléen = AppelDLL32("USER32", "GetAsyncKeyState", VK_SHIFT) <> 0
control est un booléen = AppelDLL32("USER32", "GetAsyncKeyState", VK_CONTROL) <> 0
SI ((touche = VK_F4 _ET_ PAS shift _ET_ PAS control) _OU_ 
	(touche = Asc("R") _ET_ PAS shift ET control)) ALORS
	_executeF4(ChampEnCours())
	RENVOYER 0
FIN

Bon bein en gros "GetAsyncKeyState" c'est le ToucheEnfoncée

[DelphiManiac]

C'est fort possible, mais vu que je connaissais, GetAsyncKeyState et pas toucheenfoncée, j'ai pas cherche plus loin :p

Il est vrai que j'ai juste donner un bout de code qui fonctionne dans mon cas et qui me semblait adapté à la demande et j'ai pas regardé plus loin. Désolé.

[jimmypage]

C'est fort possible, mais vu que je connaissais, GetAsyncKeyState et pas toucheenfoncée, j'ai pas cherche plus loin :p

Il est vrai que j'ai juste donner un bout de code qui fonctionne dans mon cas et qui me semblait adapté à la demande et j'ai pas regardé plus loin. Désolé.

Ya pas de mal !
Au moins moi je connaissais pas GetAsyncKeyState et ça pourra certainement me servir un jour !

[Hemgé]

Merci à tous deux pour vos codes, mais je me débrouille très bien avec ceci :

Dans le code d'initialisation du projet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
EXTERNE "KEYCONST.wl"
EXTERNE "WINCONST.wl"

Evénement(UpArrow, "*.*", WM_KEYDOWN)
//Evénement(UpArrow, "*.*", VK_UP)

Et la procédure associée, globale au projet :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
PROCEDURE UpArrow()
 
SI ToucheEnfoncée(VK_UP) _OU_ (ToucheEnfoncée(teShift) ET ToucheEnfoncée(VK_TAB)) ALORS
...
FIN

La demande est de type [Généralités].

Mais jimmypage m'a déjà fourni la réponse de base :

VK_UP n'est pas un message windows mais une constante correspondant à la valeur héxa de la touche "haut".

Par contre et il suffit de mettre un point d'arrêt à au hauteur de l'instruction dans le code ci-dessus pour l'illustrer,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

3. SI ToucheEnfoncée(VK_UP) _OU_

je confirme que toutes les frappes clavier y compris shift-lock sont interceptées.
Je n'avais pas testé cela à fond au moment de mes essais et il y a donc peut-être / sans doute des exceptions.

Ce que j'aurais aimé pouvoir coder est la remarque codée en rouge ci-dessus et n'ayant aucune connaissance de "bas-niveau" (en fait de haut niveau ) à propos de Windows, j'ai fourgué tous les VK_ et WM_ dans le même sac dans l'attente de leur consacrer quelques heures.

Je trouverais a priori plus "beau", moins "consommateur" (mais nos PC peuvent y faire face) et surtout plus efficace de
- ne pas développer une énorme routine pour gérer l'interception de WM_KEYDOWN, avec un tas de conditions en fonctions des événements à traiter,
- mais de plutôt développer des unités de code indépendantes.

A la réflexion cependant, un gros module à installer partout avec des réflexes identiques, ce n'est pas plus mal et même très bien, mais au départ, cela fait "Grosse Bertha".

A titre académique ou "généralités", je suppose qu'on ne peut effectivement pas tester de combinaisons, si ce n'est au second étage comme je l'ai illustré.

Si quelqu'un possède des informations plus approfondies et notamment sur les empilements ainsi que sur FinEvénement, je reste intéressé.

Un bon Topic vaut mieux que des essais à la lumière d'une bougie et tant l'aide que la lecture des forums habituels ne sont pas très instructives.

Encore merci et bonne soirée

Hemgé

PS : j'attendrai encore un peu avant de passer le sujet en Résolu

[DelphiManiac]

Windows est construit autour d'un système d'envoi de messages aux applications et fenêtres, les fameux WM_

Au tout début sous windows, et c'est toujours le cas maintenant, mais masqué par nos outils de développement, le coeur d'une application étais une seule boucle qui avait pour but de récupérer les messages envoyés par le système et de dispatcher ces messages aux différentes routine interne.

Donc on ne peut on mieux qu'intercepter/traiter qu'un message de type WM_ (y'en a quelques uns qui ne commence pas par WM_ pour informations)

[jimmypage]

Par contre et il suffit de mettre un point d'arrêt à au hauteur de l'instruction dans le code ci-dessus pour l'illustrer,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

3. SI ToucheEnfoncée(VK_UP) _OU_

je confirme que toutes les frappes clavier y compris shift-lock sont interceptées.

Oui bien sûr toutes les frappes sont interceptées par ton Evenement puisque tu as mis un Evenement sur WM_KEYDOWN.
A chaque fois que tu appuie sur une touche de ton clavier, windows envoie un WM_KEYDOWN (avec pour paramètre le code de la touche) à l'application en cours (ce n'est pas seulement valable pour windev mais pour toutes les applis)

Donc la frappe clavier, du fait de ton code, va automatiquement appeler ta procédure "UpArrow" que tu as branchée a ton évènement. Charge à toi après dans UpArrow de récupérer le paramètre pour savoir quelle touche a été frappée et de faire les traitements appropriés

Par contre cela n'a rien a voir avec la fonction ToucheEnfoncée.. Elle n'intercepte aucun message de windows ! Elle te retourne juste l'état de la touche

Ce que j'aurais aimé pouvoir coder est la remarque codée en rouge ci-dessus et n'ayant aucune connaissance de "bas-niveau" (en fait de haut niveau ) à propos de Windows, j'ai fourgué tous les VK_ et WM_ dans le même sac dans l'attente de leur consacrer quelques heures.

Je ne pense pas que ce soit possible de mettre un evenement sur une frappe d'une touche spécifique.

[Hemgé]

Bonjour jimmypage

Comme souvent, les débats dérivent (gentiment ici) et s'égarent sur des détails, notamment du fait qu'on perd un peu le fil de la discussion, ou sur des imprécisions relatives.

J'avais initialement écrit ceci :

Le "surcharge" système est donc double :
- WM_KEYDOWN intercepte toutes les frappes clavier ;
- ToucheEnfoncée teste donc également toutes les frappes.

Idéalement, la fonction Evénement ne devrait réagir qu'à VK_UP.

Dans le fil de votre réaction, vous m'avez répondu :

Je ne pense pas que ToucheEnfoncée teste toutes les frappes clavier mais elle te renvoie l'état de la touche à un moment t.

A quoi j'ai réagi en proposant de mettre un point d'arrêt à la première instruction de la procédure, qui se trouve justement - mais par hasard - être ToucheEnfoncée.

Dans l'absolu,
- WM_KEYDOWN intercepte toute frappe (peu importent ici d'éventuelles exceptions)
- ToucheEnfoncée teste toute frappe qu'on lui soumet et uniquement celle-là.

Dans la situation étudiée, comme on soumet toutes les frappes (via WM_KEYDOWN) à ToucheEnfoncée, cette dernière teste toutes les frappes.
De là mon commentaire de double "surcharge"

Et ma réaction à votre commentaire, dans le contexte où nous étions.

Nous avons donc bien la même interprétation tant de Evénement que de ToucheEnfoncée.
Il s'agissait simplement d'une petite confusion dans la discussion.

En conclusion, ce qui nous manque, c'est une fonction équivalente à ToucheEnfoncée qui nous permettrait d'intercepter - au même niveau qu'Evénement - toute frappe clavier d'une touche, voire même d'une combinaison de touches "système" (shift + , control + shift +, alt + ...)

Cela nous permettrait de "surcharger" un certain nombre d'événements clavier de manière très intéressante et beaucoup plus souple que ce que nous pouvons faire actuellement.

Je suis loin d'être le seul à vouloir contrôler notamment les flèches Up et Down, ainsi que Tab et shift + Tab, puis les CTRL et F keys.
Et cela en serait grandement simplifié, dans la pure perspective IHM de Windev.

Bonne journée !
Hemgé

[frenchsting]

Je ne pense pas que ce soit possible de mettre un evenement sur une frappe d'une touche spécifique.

De mémoire et de ce que j'ai fait jusqu'à présent, je n'ai jamais vu.

Par contre, je ne sais plus trop pourquoi, mais il vaut mieux coder la touche relachée (WM_KEYUP) que la touche enfoncée WM_KEYDOWN.

@HEMGE : Effectivement, la documentation sur les forums pour les événements/messages/API est souvent floue...

[DelphiManiac]

...
Je suis loin d'être le seul à vouloir contrôler notamment les flèches Up et Down, ainsi que Tab et shift + Tab, puis les CTRL et F keys.
Et cela en serait grandement simplifié, dans la pure perspective IHM de Windev.

Bonne journée !
Hemgé

Je ne crois pas qu'il y ai eu de dérive quand à la question initiale, et le code que j'ai posté en exemple (je ne suis pas le seul à avoir poster un code fonctionnel) répond à la demande exprimée, à savoir, connaître les touches enfoncée ainsi que le statut des touches shift et ctrl.

La particularité entre ton code et les autres, c'est la manière de tester la touche :

Tu utilise

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SI ToucheEnfoncée(VK_UP) _OU_ (ToucheEnfoncée(teShift) ET ToucheEnfoncée(VK_TAB))

Ce test ne tiens pas compte de la touche réellement enfoncé pour lequel le message WM_KEYDOWN ou WM_KEYUP a été généré, mais ce test vérifie les touches enfoncé au moment ou le code est exécuté, ce qui n'est pas tout à fais la même chose.

En gros, le système détecte l'appui sur une touche, il génère un message WM_KEYDOWN, et envoi cet évènement à la fenêtre qui a le focus, ce message est intercepté par la fenêtre et dans le code de traitement, si tu utilises ToucheEnfoncée, il est probable que la touche qui déclenché l'évènement ne soit plus enfoncée, voir même que ce soit une ou plusieurs autres touches qui soient enfoncées.
De plus le test avec toucheenfoncé fait autant d'appel a l'api de windows correspondante qu'il y a de test toucheenfoncé alors que la récupération du paramètre wParam du message indique quelle est la touche qui a été enfoncée sans aucun appel supplémentaire à une api.


Pour la touche alt c'est un peu plus compliqué et ce n'étais pas la demande initiale.

[jimmypage]

Tu parles donc d'une commande Windev qui permette de faire ceci ?

Alors je suis d'accord !
Mais, au fond, ce ne serait rien d'autre qu'une fonction qui en toute transparence intercepterait l’évènement WM_KEYDOWN ou WM_KEYUP et qui testerait l’équivalent de ToucheEnfoncee ...

... A savoir le code que tu peux avoir déjà dans ta fenêtre.

Il n'y a pas d'autre moyen à moins que Microsoft fournisse un API qui le fasse

[Hibernatus34]

Bonjour,

Je n'ai pas tout compris/lu, mais sachez que :
- GetAsyncKeyState renvoie l'état d'une touche au moment de son appel
- GetKeyState renvoie l'état d'une touche lors de la réception du dernier message clavier reçu
- ToucheEnfoncée correspond à GetKeyState

GetAsyncKeyState ne doit pas être utilisé dans un événement, ToucheEnfoncée est plus cohérent et ne dépend pas du timing.

PS. Notez que pour que ToucheEnfoncée fonctionne il faut justement être passé par la boucle de messages, donc Multitâche(-1) ou Multitâche(1) si on est dans un traitement bloquant. (pas Multitâche(), encore une incohérence de WD...) (attention, je parle pas d'un événement cette fois)

PPS. Notez qu'un bouton avec raccourci clavier hors écran et en mode Interruption fait souvent l'affaire.
Sinon, vous pouvez donc intercepter WM_KEYDOWN et tester ToucheEnfoncée sur Ctrl, Shift, Alt (la touche elle-même c'est _EVE.wParam), et renvoyer une valeur uniquement si vous avez traité l'événement et ne souhaitez pas laisser WinDev le faire.
Enfin, n'oubliez pas qu'un champ peut ne pas être accessible automatiquement par TAB.

[Hibernatus34]

Voilà comment je procède :

Dans le code d'initialisation de la fenêtre :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Evénement(_appuiTouche, ".*", WM_KEYUP)

et la procédure qui gère ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
PROCEDURE _appuiTouche(MessageWindows, wParam, lParam)
touche est un entier = wParam
shift est un booléen = AppelDLL32("USER32", "GetAsyncKeyState", VK_SHIFT) <> 0
control est un booléen = AppelDLL32("USER32", "GetAsyncKeyState", VK_CONTROL) <> 0
SI ((touche = VK_F4 _ET_ PAS shift _ET_ PAS control) _OU_ 
	(touche = Asc("R") _ET_ PAS shift ET control)) ALORS
	_executeF4(ChampEnCours())
	RENVOYER 0
FIN

Re-Bonjour,

Ces lignes sont fausses, GetAsyncKeyState renvoie 2 flags, l'un pour indiquer l'état actuel et l'autre pour indiquer un changement d'état depuis le dernier appel. Donc il faut pas tester "différent de zéro".

[Hemgé]

Pour reprendre et conclure,

Lorsque j'ai ouvert ce sujet, je n'avais pas de besoin opérationnel pratique.
Je l'ai d'ailleurs ouvert sous la rubrique [généralités] et j'avais pris la précaution d'indiquer le principe des solutions généralement mises en œuvre.

Je m'interrogeais sur la meilleure manière de faire et je déplorais notamment la nécessité de devoir enchaîner deux instructions, alors qu'une seule devrait faire l'affaire surtout devant un besoin tellement récurrent.
Personnellement, comme exposé, je préférerais développer une collection de procédures indépendantes plutôt qu'une grande procédure avec KEYDOWN comme point d'entrée et qui collationne une série de sous-procédures dont le seul point commun est qu'elles ne sont invocables qu'après que KEYDOWN a intercepté les événements spécifiques que chacune d'entre elles doit gérer.

Cela débouche sur la suggestion d'une nouvelle instruction à implémenter dans Windev pour intercepter les événements clavier.

Avec un peu de chance, cette instruction serait plus rapide en exécution (mais est-ce indispensable avec les machines actuelles ?), que les solutions actuelles.
Surtout, elle améliorerait la lisibilité des programmes tout en diminuant le risque d'erreur (puisqu'on utiliserait une seule instruction au lieu d'en enchaîner deux au moins).

Pour le reste, de manière définitive, je n'avais pas demandé de code et si je devais adopter un nouveau code, ce ne serait qu'à la condition que ce code soit
- plus compact que le mien (qui n'est que la solution classique exposée dans de nombreux topics) ;
- ou plus efficace en charge machine (ce qui devrait être testé et démontré)
ET surtout
- parfaitement compréhensible par tout programmeur Windev de niveau raisonnable, faute de quoi ce programme ne serait plus 'maintenable'.

Je ne crois pas qu'il soit indiqué de farcir des programmes Windev avec des appels à des dll et api si le langage standard offre une solution acceptable et pas désespérément lente ou tordue.

Bon week-end

Hemgé

[DelphiManiac]

Mon ressenti en lisant ton message de clôture, c'est ; pourquoi vous m'....... avec tout votre baratin, moi ce que j'aimerais c'est que windev fasse ça.

Si tu veux que windev soit adapté à ton besoin, c'est pas ici qu'il faut poster.

Si tu pose des questions ouvertes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
L'un(e) de vous dispose-t-il d'informations plus complètes sur le fonctionnement de la fonction Evénement et sur ce qu'elle intercepte ?
 
De même, à votre connaissance, Evénement peut-elle traiter une combinaison de messages autrement que via une combinaison du style ToucheEnfoncée(teShift) ET ToucheEnfoncée(VK_TAB) ?

il faut t'attendre à ce qu'on apporte des réponses ouvertes qui peuvent sûrement déraper.

Si maintenant ta question était, est ce que windev peut, avec un seul appel de méthode, me dire si une touche a été appuyé, il fallait être plus concis.

On a tous essayé de te donner des éléments de réponse sur la raison de cette façon de faire et du pourquoi. Ça ne t’intéresse pas ? soit, mais personnellement je trouve dommage de dire qu'un code n'est valable, intéressant ou tout adjectif que tu veux bien accolé, seulement dans le cas où un programmeur Windev de niveau raisonnable peut le comprendre.

Désolé d'avoir dérapé sur des explications système du haut de mes maigres moyens.

[Hemgé]

Votre ressenti …

Le mien aussi ?

Comme informaticien, vous agissez en qualité de fournisseur de solutions à des clients directs ou institutionnels, suivant que vous travaillez en indépendant ou au sein d’une société.
Si vous assumez une autre fonctionnalité, vous êtes de toute manière fournisseur d’autres intervenants.

Vous savez donc qu’il faut écouter les clients et en ouvrant un sujet sur le forum, je suis le client des intervenants sur ce sujet.
Alors, tenez compte du spectre raisonnable de ma question et aussi, des précisions que j’ai apportées ultérieurement suite aux premières réponses que vous-même et jimmypage m’avez apportées.

Quant aux deux questions ouvertes que vous citez dans votre dernier message, personne n’y a justement répondu de manière circonstanciée.

Vous me prêtez des intentions et comportements que je récuse. J’ai (longuement) réexpliqué mes motivations et j’ai (longuement toujours) reprécisé ce qui m’intéressais.

En clôturant le message sur le constat qu’une fonction supplémentaire serait la bienvenue, je pointais un souhait qu’apparemment d’autres partagent et je suis certain que PC soft suit attentivement ce Forum. Le message est donc passé.

Quant aux solutions accessibles à un développeur raisonnablement formé, c’était la manière la plus diplomatique possible me semblait-il de vous rappeler à une certaine réalité :

1. choisissant de travailler avec un langage de « haut niveau », il vaut mieux rester cohérent et ne pas faire plus d’incursions ou plutôt d’excursions que nécessaire vers ces langages de « bas niveau » qui nous amusent et valorisent notre niveau technique.
2. considérant le nombre restreint de développeurs Windev, il ne m’apparaît pas raisonnable d’ajouter des critères non indispensables pour le recrutement éventuel de collaborateurs sur des projets Windev, cet aspect de la question étant encore accentué par le petit drapeau belge qui flotte à côté de mon pseudo.
   Question non subsidiaire : combien de développeurs Windev en France ? Et en Belgique ?

Ne prétendez pas maintenant que j’ai demandé du code. Je ne l’ai pas fait et ai cru bon d’y revenir.
Vous connaissez le principe du Forum : « aide-toi et le Forum t’aidera ».
J’ai ouvert un sujet général et je me réservais d’exploiter les pistes qui me seraient suggérées.
Mais je ne suis pas fou non plu, tout bon code est le bienvenu et j’ai déjà écumé le Forum à de multiples reprises.

Pour en venir à ce que j'aurais préféré éviter surtout vu l'évolution de la discussion, je dois critiquer votre code en ce qu’il ne répond pas aux attentes du « client ».
Outre le fait qu’il demandait de l’information générale, le client insistait sur une solution à la « surcharge » système imposée par l’enchaînement de deux instructions Windev.

Si je décompte le nombre de variables que vous mettez en jeu, leurs affectations respectives, les appels aux dll et les tests bien plus nombreux que vous effectuez, je suis persuadé que votre proposition consomme beaucoup plus de ressources que la solution classique que j’ai adoptée.
Donc, je ne vois pas en quoi votre proposition prend en considération cet aspect primordial et d’emblée souligné de ma demande.

Accessoirement, Hibernatus a émis des critiques techniques, mais nous aurions pu y remédier.

J’avais épinglé un début de dérive du topic, en ce sens que comme fréquemment, on passait du sujet général à UN des aspects particuliers et que la discussion allait se focaliser sur ce point particulier, aux dépens du point de vue général.

Cela ne vous avait pas convenu et vous avez réagi.
Revoyez le topic et vous verrez que les interventions portent essentiellement sur du code.

Maintenant, vous évoquez votre ressenti et me prenez à partie.
J’en conclus que cela commence à déraper et vous propose d’éventuellement continuer cet aspect de la discussion par MP. Il n’y a pas lieu de polluer le Forum et je garantis que je ne me déroberai pas.

J’espère que vous ne me tiendrez pas rigueur outre mesure de la présente réaction et que nous pourrons nous côtoyer à l’avenir sur ce Forum sans devoir recourir à l’émoticone du cowboy qui dégaine des deux mains …

J'espère aussi qu'à l'avenir vous resterez motivé à essayer de me prêter main forte.

Bon week-end

Hemgé