Sous WD14, j'ai =E0 bosser sur une fen=EAtre de supervision qui r=E9cup=E8r=
e
des valeurs envoy=E9es par un programme externe (non Windev donc). Ces
valeurs sont affich=E9es dans des champs de saisie cr=E9=E9s =E0 partir de
ChampClone().
L'objectif est d'enregistrer chaque nouvelle valeur renvoy=E9e par le
programme externe dans une base de donn=E9es. Donc, en l'occurrence, =E0
partir des champs mis =E0 jour sur la nouvelle fen=EAtre.
Pour cela, je cherche =E0 conna=EEtre l'=E9v=E8nement Windows qui va bien q=
ui
indique le changement de valeur, d'=E9tat ou que sais-je de chaque champ
de la fen=EAtre.
Apr=E8s avoir mis une trace sur un Evenement 0, les =E9v=E8nements Windows
correspondants ne me parlent pas trop: 1741
(RPC_S_UNKNOWN_AUTHN_TYPE), 15 (WM_PAINT) et 312 (WM_CTLCOLORSTATIC).
En r=E9duisant la fen=EAtre de supervision, seul subsiste le 1741.
Je ne veux pas mettre en place un timer qui irait lire toutes les
500ms les champs, dans certains cas, seules sont envoy=E9es des
impulsions, qui ne seraient pas prises alors en compte.
Ma question est donc toute simple: comment d=E9tecter le changement de
valeur dans un champ de saisie dont l'utilisateur n'est pas ma=EEtre ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Albert P.
"Adrien A." a écrit dans le message de news:
Salut,
Sous WD14, j'ai à bosser sur une fenêtre de supervision qui récupère des valeurs envoyées par un programme externe (non Windev donc). Ces valeurs sont affichées dans des champs de saisie créés à partir de ChampClone().
L'objectif est d'enregistrer chaque nouvelle valeur renvoyée par le programme externe dans une base de données. Donc, en l'occurrence, à partir des champs mis à jour sur la nouvelle fenêtre. Pour cela, je cherche à connaître l'évènement Windows qui va bien qui indique le changement de valeur, d'état ou que sais-je de chaque champ de la fenêtre. Après avoir mis une trace sur un Evenement 0, les évènements Windows correspondants ne me parlent pas trop: 1741 (RPC_S_UNKNOWN_AUTHN_TYPE), 15 (WM_PAINT) et 312 (WM_CTLCOLORSTATIC). En réduisant la fenêtre de supervision, seul subsiste le 1741. Je ne veux pas mettre en place un timer qui irait lire toutes les 500ms les champs, dans certains cas, seules sont envoyées des impulsions, qui ne seraient pas prises alors en compte.
Ma question est donc toute simple: comment détecter le changement de valeur dans un champ de saisie dont l'utilisateur n'est pas maître ?
Merci de votre aide ! Adrien
Bonjour,
Sans être un expert, le RPC_S_UNKNOWN_AUTHN_TYPE (1741) ne me semble pas être le message windows que vous détectez mais un message d'erreur (pas vraiment la même chose) ... les messsages que l'on detecte avec évènement 0 sont du type WM_xxxxx (pas des messages d'erreurs) et le 1741 ne correspont à aucun des WM_xxxxx listés.
Une question, comment les valeurs du programme externe sont elle envoyées dans les champs de saisies ? et pourquoi tester l'évènement 1741 ne fait-il pas l'affaire, puisque semble t-il vous le détectez à chaque fois ?
Albert P.
"Adrien A." <gorguth@gmail.com> a écrit dans le message de news:
65d9cbbe-a1f5-4840-bff5-a5bd2285aff8@k23g2000yqa.googlegroups.com...
Salut,
Sous WD14, j'ai à bosser sur une fenêtre de supervision qui récupère
des valeurs envoyées par un programme externe (non Windev donc). Ces
valeurs sont affichées dans des champs de saisie créés à partir de
ChampClone().
L'objectif est d'enregistrer chaque nouvelle valeur renvoyée par le
programme externe dans une base de données. Donc, en l'occurrence, à
partir des champs mis à jour sur la nouvelle fenêtre.
Pour cela, je cherche à connaître l'évènement Windows qui va bien qui
indique le changement de valeur, d'état ou que sais-je de chaque champ
de la fenêtre.
Après avoir mis une trace sur un Evenement 0, les évènements Windows
correspondants ne me parlent pas trop: 1741
(RPC_S_UNKNOWN_AUTHN_TYPE), 15 (WM_PAINT) et 312 (WM_CTLCOLORSTATIC).
En réduisant la fenêtre de supervision, seul subsiste le 1741.
Je ne veux pas mettre en place un timer qui irait lire toutes les
500ms les champs, dans certains cas, seules sont envoyées des
impulsions, qui ne seraient pas prises alors en compte.
Ma question est donc toute simple: comment détecter le changement de
valeur dans un champ de saisie dont l'utilisateur n'est pas maître ?
Merci de votre aide !
Adrien
Bonjour,
Sans être un expert, le RPC_S_UNKNOWN_AUTHN_TYPE (1741) ne me semble pas
être le message windows que vous détectez mais un message d'erreur (pas
vraiment la même chose) ... les messsages que l'on detecte avec évènement 0
sont du type WM_xxxxx (pas des messages d'erreurs) et le 1741 ne correspont
à aucun des WM_xxxxx listés.
Une question, comment les valeurs du programme externe sont elle envoyées
dans les champs de saisies ? et pourquoi tester l'évènement 1741 ne fait-il
pas l'affaire, puisque semble t-il vous le détectez à chaque fois ?
Sous WD14, j'ai à bosser sur une fenêtre de supervision qui récupère des valeurs envoyées par un programme externe (non Windev donc). Ces valeurs sont affichées dans des champs de saisie créés à partir de ChampClone().
L'objectif est d'enregistrer chaque nouvelle valeur renvoyée par le programme externe dans une base de données. Donc, en l'occurrence, à partir des champs mis à jour sur la nouvelle fenêtre. Pour cela, je cherche à connaître l'évènement Windows qui va bien qui indique le changement de valeur, d'état ou que sais-je de chaque champ de la fenêtre. Après avoir mis une trace sur un Evenement 0, les évènements Windows correspondants ne me parlent pas trop: 1741 (RPC_S_UNKNOWN_AUTHN_TYPE), 15 (WM_PAINT) et 312 (WM_CTLCOLORSTATIC). En réduisant la fenêtre de supervision, seul subsiste le 1741. Je ne veux pas mettre en place un timer qui irait lire toutes les 500ms les champs, dans certains cas, seules sont envoyées des impulsions, qui ne seraient pas prises alors en compte.
Ma question est donc toute simple: comment détecter le changement de valeur dans un champ de saisie dont l'utilisateur n'est pas maître ?
Merci de votre aide ! Adrien
Bonjour,
Sans être un expert, le RPC_S_UNKNOWN_AUTHN_TYPE (1741) ne me semble pas être le message windows que vous détectez mais un message d'erreur (pas vraiment la même chose) ... les messsages que l'on detecte avec évènement 0 sont du type WM_xxxxx (pas des messages d'erreurs) et le 1741 ne correspont à aucun des WM_xxxxx listés.
Une question, comment les valeurs du programme externe sont elle envoyées dans les champs de saisies ? et pourquoi tester l'évènement 1741 ne fait-il pas l'affaire, puisque semble t-il vous le détectez à chaque fois ?
Albert P.
patrice
je comprends pas trop... pourquoi ne pas mettre une fonction sur le code "a chaque modification" du champ qui sert de source au clone. Une fonction genre GereModifie(moimeme..nom)
Adrien A. a écrit :
Salut,
Sous WD14, j'ai à bosser sur une fenêtre de supervision qui récupère des valeurs envoyées par un programme externe (non Windev donc). Ces valeurs sont affichées dans des champs de saisie créés à partir de ChampClone().
L'objectif est d'enregistrer chaque nouvelle valeur renvoyée par le programme externe dans une base de données. Donc, en l'occurrence, à partir des champs mis à jour sur la nouvelle fenêtre. Pour cela, je cherche à connaître l'évènement Windows qui va bien qui indique le changement de valeur, d'état ou que sais-je de chaque champ de la fenêtre. Après avoir mis une trace sur un Evenement 0, les évènements Windows correspondants ne me parlent pas trop: 1741 (RPC_S_UNKNOWN_AUTHN_TYPE), 15 (WM_PAINT) et 312 (WM_CTLCOLORSTATIC). En réduisant la fenêtre de supervision, seul subsiste le 1741. Je ne veux pas mettre en place un timer qui irait lire toutes les 500ms les champs, dans certains cas, seules sont envoyées des impulsions, qui ne seraient pas prises alors en compte.
Ma question est donc toute simple: comment détecter le changement de valeur dans un champ de saisie dont l'utilisateur n'est pas maître ?
Merci de votre aide ! Adrien
je comprends pas trop...
pourquoi ne pas mettre une fonction sur le code "a chaque modification"
du champ qui sert de source au clone.
Une fonction genre GereModifie(moimeme..nom)
Adrien A. a écrit :
Salut,
Sous WD14, j'ai à bosser sur une fenêtre de supervision qui récupère
des valeurs envoyées par un programme externe (non Windev donc). Ces
valeurs sont affichées dans des champs de saisie créés à partir de
ChampClone().
L'objectif est d'enregistrer chaque nouvelle valeur renvoyée par le
programme externe dans une base de données. Donc, en l'occurrence, à
partir des champs mis à jour sur la nouvelle fenêtre.
Pour cela, je cherche à connaître l'évènement Windows qui va bien qui
indique le changement de valeur, d'état ou que sais-je de chaque champ
de la fenêtre.
Après avoir mis une trace sur un Evenement 0, les évènements Windows
correspondants ne me parlent pas trop: 1741
(RPC_S_UNKNOWN_AUTHN_TYPE), 15 (WM_PAINT) et 312 (WM_CTLCOLORSTATIC).
En réduisant la fenêtre de supervision, seul subsiste le 1741.
Je ne veux pas mettre en place un timer qui irait lire toutes les
500ms les champs, dans certains cas, seules sont envoyées des
impulsions, qui ne seraient pas prises alors en compte.
Ma question est donc toute simple: comment détecter le changement de
valeur dans un champ de saisie dont l'utilisateur n'est pas maître ?
je comprends pas trop... pourquoi ne pas mettre une fonction sur le code "a chaque modification" du champ qui sert de source au clone. Une fonction genre GereModifie(moimeme..nom)
Adrien A. a écrit :
Salut,
Sous WD14, j'ai à bosser sur une fenêtre de supervision qui récupère des valeurs envoyées par un programme externe (non Windev donc). Ces valeurs sont affichées dans des champs de saisie créés à partir de ChampClone().
L'objectif est d'enregistrer chaque nouvelle valeur renvoyée par le programme externe dans une base de données. Donc, en l'occurrence, à partir des champs mis à jour sur la nouvelle fenêtre. Pour cela, je cherche à connaître l'évènement Windows qui va bien qui indique le changement de valeur, d'état ou que sais-je de chaque champ de la fenêtre. Après avoir mis une trace sur un Evenement 0, les évènements Windows correspondants ne me parlent pas trop: 1741 (RPC_S_UNKNOWN_AUTHN_TYPE), 15 (WM_PAINT) et 312 (WM_CTLCOLORSTATIC). En réduisant la fenêtre de supervision, seul subsiste le 1741. Je ne veux pas mettre en place un timer qui irait lire toutes les 500ms les champs, dans certains cas, seules sont envoyées des impulsions, qui ne seraient pas prises alors en compte.
Ma question est donc toute simple: comment détecter le changement de valeur dans un champ de saisie dont l'utilisateur n'est pas maître ?
Merci de votre aide ! Adrien
Romain PETIT
Le 31/12/2009, patrice a supposé :
je comprends pas trop... pourquoi ne pas mettre une fonction sur le code "a chaque modification" du champ qui sert de source au clone. Une fonction genre GereModifie(moimeme..nom)
Pas si simple. A priori c'est une appli externe qui met à jour le champ, donc le champ est modifié mais l'appli windev ne détecte pas la modif. C'est normalement géré par les évenements mais visiblement les champs de saisie Windev ne permettent pas de trapper ce type d'évenement (en tout cas pas celui qu'on serait en droit d'attendre).
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Le 31/12/2009, patrice a supposé :
je comprends pas trop...
pourquoi ne pas mettre une fonction sur le code "a chaque modification" du
champ qui sert de source au clone.
Une fonction genre GereModifie(moimeme..nom)
Pas si simple.
A priori c'est une appli externe qui met à jour le champ, donc le champ
est modifié mais l'appli windev ne détecte pas la modif.
C'est normalement géré par les évenements mais visiblement les champs
de saisie Windev ne permettent pas de trapper ce type d'évenement (en
tout cas pas celui qu'on serait en droit d'attendre).
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windev
http://www.mesnews.net/
http://fr.wikipedia.org/wiki/Newsgroup
je comprends pas trop... pourquoi ne pas mettre une fonction sur le code "a chaque modification" du champ qui sert de source au clone. Une fonction genre GereModifie(moimeme..nom)
Pas si simple. A priori c'est une appli externe qui met à jour le champ, donc le champ est modifié mais l'appli windev ne détecte pas la modif. C'est normalement géré par les évenements mais visiblement les champs de saisie Windev ne permettent pas de trapper ce type d'évenement (en tout cas pas celui qu'on serait en droit d'attendre).
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windev http://www.mesnews.net/ http://fr.wikipedia.org/wiki/Newsgroup
Adrien A.
Merci d'avoir réfléchi à la question. J'ai réglé tout ça en m'attaquant au programme qui envoie les donné es; comme le souligne Romain, rien ne permet de voir une modification dans ce cas de figure, seul est pris en compte l'action de l'utilisateur...
On 4 jan, 09:45, Romain PETIT wrote:
Le 31/12/2009, patrice a supposé :
> je comprends pas trop... > pourquoi ne pas mettre une fonction sur le code "a chaque modification" du > champ qui sert de source au clone. > Une fonction genre GereModifie(moimeme..nom)
Pas si simple. A priori c'est une appli externe qui met à jour le champ, donc le champ est modifié mais l'appli windev ne détecte pas la modif. C'est normalement géré par les évenements mais visiblement les cham ps de saisie Windev ne permettent pas de trapper ce type d'évenement (en tout cas pas celui qu'on serait en droit d'attendre).
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windevhttp://www.mesnews.net/http://fr.wik ipedia.org/wiki/Newsgroup
Merci d'avoir réfléchi à la question.
J'ai réglé tout ça en m'attaquant au programme qui envoie les donné es;
comme le souligne Romain, rien ne permet de voir une modification dans
ce cas de figure, seul est pris en compte l'action de l'utilisateur...
On 4 jan, 09:45, Romain PETIT <Vo...@Signature.fin> wrote:
Le 31/12/2009, patrice a supposé :
> je comprends pas trop...
> pourquoi ne pas mettre une fonction sur le code "a chaque modification" du
> champ qui sert de source au clone.
> Une fonction genre GereModifie(moimeme..nom)
Pas si simple.
A priori c'est une appli externe qui met à jour le champ, donc le champ
est modifié mais l'appli windev ne détecte pas la modif.
C'est normalement géré par les évenements mais visiblement les cham ps
de saisie Windev ne permettent pas de trapper ce type d'évenement (en
tout cas pas celui qu'on serait en droit d'attendre).
--
Romain PETIT
contact : rompetit chez free fr
+-+ posté sur Usenet avec MesNews et non depuis un forum web +-+
news:fr.comp.developpement.agl.windevhttp://www.mesnews.net/http://fr.wik ipedia.org/wiki/Newsgroup
Merci d'avoir réfléchi à la question. J'ai réglé tout ça en m'attaquant au programme qui envoie les donné es; comme le souligne Romain, rien ne permet de voir une modification dans ce cas de figure, seul est pris en compte l'action de l'utilisateur...
On 4 jan, 09:45, Romain PETIT wrote:
Le 31/12/2009, patrice a supposé :
> je comprends pas trop... > pourquoi ne pas mettre une fonction sur le code "a chaque modification" du > champ qui sert de source au clone. > Une fonction genre GereModifie(moimeme..nom)
Pas si simple. A priori c'est une appli externe qui met à jour le champ, donc le champ est modifié mais l'appli windev ne détecte pas la modif. C'est normalement géré par les évenements mais visiblement les cham ps de saisie Windev ne permettent pas de trapper ce type d'évenement (en tout cas pas celui qu'on serait en droit d'attendre).
-- Romain PETIT contact : rompetit chez free fr +-+ posté sur Usenet avec MesNews et non depuis un forum web +-+ news:fr.comp.developpement.agl.windevhttp://www.mesnews.net/http://fr.wik ipedia.org/wiki/Newsgroup
