WD10 - HLitRecherchePremier()

Merci encore de cette précision sur la 5.5 que je ne connais pas.
Cette précision ajoutera du poids à ma requête chez PCS.

Bonne fin de journée!

Salut Réal,

il y a d'autres problèmes de ce genre que je crois PC Soft n'ont pas
voulu corriger. Peut-être parce qu'il y aurait trop de code qui ne
marcherais plus. Depuis, je me méfie de la position du
curseur et re-contrôle l'ID avant chaque modification. Voici
L'échange datant de 2003 (wd 7.5):

Salutations
Mat


NOTRE MESSAGE DU 27 JUILLET 2003
=========================== Dysfonctionnement de HLitRecherchePremier et HRetourPosition

Détail de la demande :
On utilise HSauvePosition (=1, le premier enregistrement), suivi par
HLitRecherchePremier qui ne trouve pas sa valeur de recherche (4). Le
curseur se déplace sur le premier enregistrement commençant avec la
même valeur (40238), même si l'aide dit ""L'enregistrement n'a pas été
trouvé (pas de déplacement)"". Ensuite, HRetourPosition ne retourne
pas au début du fichier !!!!!!!!
N.B. Dans ce cas la valeur est numérique, mais la rubrique est du
format texte.
...

Protocole de reproduction :
nPos=HSauvePosition(:cMasterTable,:cMasterIDFld) // ( = 1 )
SI HLitRecherchePremier(:cMasterTable,:cRecNameFld,vName) ALORS //
(valeur recherché = 4, mais se positionne sur ID 40238 ???)
vID = {:cMasterTable + "." + :cMasterIDFld,indRubrique}
vRes=True
SINON
vResúlse // (exécute correctement cette ligne)
FIN
HRetourPosition(nPos) // ( ne s'exécute pas. ID reste sur 40248 enregistrement n° 2266)


MESSAGE DE PC SOFT DU 30 JUILLET 2003
=============================== Nous sommes surpris par votre description et l'information est inexacte
"L'enregistrement n'a pas été trouvé (pas de
déplacement)". Pouvez-vous nous préciser l'entrée de l'aide qui vous a
permis d'obtenir cette information ? Nous la ferons
corriger.

Le fonctionnement est le suivant (valable quelque soit la version de
WINDEV) : en cas de recherche, si la valeur n'est pas
trouvé on est positionné dans le fichier sur le premier enregistrement
supérieur. Dans l'aide de HLitRecherchePremier, on
peut lire dans le tableau récapitulatif : "Dupuis n'existe pas.
Positionnement sur la première valeur supérieure (Durand)."

Veuillez nous excuser pour l'erreur de documentation qui vous a gêne
dans la mise au point de votre traitement.



NOTRE MESSAGE DU 31 JUILLET 2003
=========================== L'information se trouve dans l'aide de la commande même, voir le
fichier gif en annexe.
Ce que vous expliquez serait le résultat d'une lecture générique et
correspond avec celle de HLitRecherche. Ce comportement est clairement
FAUX pour une recherche à l'identique. Y-a-t-il un autre langage de
programmation dans lequel un curseur dans un fichier se déplace quand
une recherche n'aboutit pas? C'est totalement illogique et les
langages que je connais ne le font pas.

Dans l'aide, soit l'exemple pour "Dupuis" ou celui pour "Dupon" (sans
options) est faux. Pour moi, c'est le premier.

En outre ceci explique peut-être pourquoi HRetourPosition ne
fonctionne pas après HLitRecherchePremier. Windev pense que la
position n'a pas changé. De toute façon, le curseur reste sur
l'enregistrement (faux) et ne retourne pas sur celui sauvé par
HSauvePosition. C'est tellement grave que je ne peux presque pas
croire que c'est vrai !
....


MESSAGE DE PC SOFT DU 6 AOUT 2003
============================ Nous avons bien pris note de vos remarques. Notre précédente réponse
reste cependant valable.

Nous restons à votre disposition.

Salut Mat,

Merci de nous informer de cette autre faiblesse de WD. « Un homme
averti en vaut deux » comme on dit.

En fait, selon les quelques tests que je viens de faire - et si je
comprend bien, si la clef n'a rien de ressemblant avec la valeur
cherchée, la position ne changera pas. Mais si la valeur cherchée est
contenue dans le début de la clef, alors là le curseur se positionne
sur cet enregistrement.

Par exemple, on cherche "030" et il le trouve à HNumEnr()=10
On cherche ensuite "blabla" dont aucune clef ne commencent par cela et
HNumEnr() restera à cette position de 10.

Mais si on cherche par exemple "100" et qu'aucune clef ne contient
exactement "100" mais que une ou plusieurs clef commencent par "100"
(comme "1000", "100233" ou autres) alors là HNumEnr() ira se
positionner sur la première clef qui commence par cette valeur.

C'est assez spécial.

Le bug demeure mais comme "work around" est-ce que la solution serait
d'utiliser HNumEnr() au lieu de HSauvePosition() ?

Sachant qu'on doit utiliser autre chose que HSauvePosition(), j'aurais
tendance à utiliser HNumEnr() comme ci-dessous;

PosAvant est un entier=HNumEnr(Client)
// mes autres recherches ici qui risquent de changer la position
HLit(Client,PosAvant) // pour ne pas prendre de chance

Salut Réal

Je ne suis pas souvent sur le forum en ce moment....
Mais comme je suis passé par là...
Pour ton pb il y a peut être une soluce.
Étant donné que la taille de l'argument recherché doit être égal à la taille
de la chaîne saisie dans le champ de recherche, pourquoi ne pas essayé
d'utiliser la commande Complète() pour compléter la chaîne saisie avec le
caractère 032 de façon à obtenir la longueur de la rubrique dans laquelle
s'effectue la recherche ?
Mais pour que ça marche il te faudra peut être stocker les enregistrements
complétés eux aussi par des espaces à la taille maximale de la rubrique....
Ainsi la comparaison se fera sur des éléments qui seront de taille
équivalentes...
--
Cordialement,
André STASZEWSKI
(Gratuit) Photo Visu 3.1 sur www.PlaneteDev.fr.st
Pour me contacter cliquez ici : http://cerbermail.com/?OT0Wnwyzph

"Réal Phil" <realmip@yahoo.ca> a écrit dans le message de news:
1149047036.821929.5260@y43g2000cwc.googlegroups.com...
Salut Mat,

Merci de nous informer de cette autre faiblesse de WD. « Un homme
averti en vaut deux » comme on dit.

En fait, selon les quelques tests que je viens de faire - et si je
comprend bien, si la clef n'a rien de ressemblant avec la valeur
cherchée, la position ne changera pas. Mais si la valeur cherchée est
contenue dans le début de la clef, alors là le curseur se positionne
sur cet enregistrement.

Par exemple, on cherche "030" et il le trouve à HNumEnr()
On cherche ensuite "blabla" dont aucune clef ne commencent par cela et
HNumEnr() restera à cette position de 10.

Mais si on cherche par exemple "100" et qu'aucune clef ne contient
exactement "100" mais que une ou plusieurs clef commencent par "100"
(comme "1000", "100233" ou autres) alors là HNumEnr() ira se
positionner sur la première clef qui commence par cette valeur.

C'est assez spécial.

Le bug demeure mais comme "work around" est-ce que la solution serait
d'utiliser HNumEnr() au lieu de HSauvePosition() ?

Sachant qu'on doit utiliser autre chose que HSauvePosition(), j'aurais
tendance à utiliser HNumEnr() comme ci-dessous;

PosAvant est un entier=HNumEnr(Client)
// mes autres recherches ici qui risquent de changer la position
HLit(Client,PosAvant) // pour ne pas prendre de chance

Salut André!

En réponse à ta suggestion, c'est ce que je faisais depuis toujours
quand je travaillais en Foxpro (c'est à dire compléter les variables
pour comparer la variable et la rubrique de mêmes longueurs). Ça ne
rate jamais mais c'est plus de travail. Mais comme Windev est sensé
être un langage plus évolué, on ne devrait pas avoir à faire tout
ce travail.

D'autant plus que Windev gère très bien les recherches en général.
C'est seulement cette particularité qui semble ne pas fonctionner.

As-tu testé toi le code que j'ai soumis sur ta version 10 ?

Je suis un peu comme mélangé. Un utilisateur a testé le code sur la
version 10 et dit que ça ne fonctionne toujours pas (comme la 7.5 et
la 8 en fait) mais par contre Pc Soft me répond qu'ils ont testé sur
Windev 10 de leur côté et que ça fonctionne bien...!!??

Je vais resoumettre le code du problème sur un prochain message sur ce
forum pour inviter plusieurs personnes à vérifier sur la 10.

@+

Réal Phil avait soumis l'idée :

Je suis un peu comme mélangé. Un utilisateur a testé le code sur la
version 10 et dit que ça ne fonctionne toujours pas (comme la 7.5 et
la 8 en fait) mais par contre Pc Soft me répond qu'ils ont testé sur
Windev 10 de leur côté et que ça fonctionne bien...!!??

A moins que cela ne soit changé depuis la version 40k, je confirme que le comportement est toujours le même en V10. Peut être que
le ST n'a pas fait avec une chaine plus longue que la taille de la clé? Si quelqu'un faisait l'essai en 50o, le doute serait
levé. Mais il m'est arrivé de nombreuses fois d'avoir le même genre de réponse du ST, et après envoi d'un projet reproduisant le
signalement qu'il reconnaisse le bug dans le cas décrit. Mais à chaque fois c'est une perte de temps pour faire un projet exemple
:-@

--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre

Pascal F a écrit :

A moins que cela ne soit changé depuis la version 40k, je confirme que le comportement est toujours le même en V10. Peut être que
le ST n'a pas fait avec une chaine plus longue que la taille de la clé? Si quelqu'un faisait l'essai en 50o, le doute serait
levé. Mais il m'est arrivé de nombreuses fois d'avoir le même genre de réponse du ST, et après envoi d'un projet reproduisant le
signalement qu'il reconnaisse le bug dans le cas décrit. Mais à chaqu e fois c'est une perte de temps pour faire un projet exemple

Salut Pascal,

Tu n'as pas envie de mettre ton propre Windev 10 à jour avec la
dernière version 50o ?
Tu pourrais ensuite tester et voir si le problème est réglé.

Qu'en penses-tu?

Réal Phil a émis l'idée suivante :

Pascal F a écrit :

A moins que cela ne soit changé depuis la version 40k, je confirme que le comportement est toujours le même en V10. Peut être
que le ST n'a pas fait avec une chaine plus longue que la taille de la clé? Si quelqu'un faisait l'essai en 50o, le doute
serait levé. Mais il m'est arrivé de nombreuses fois d'avoir le même genre de réponse du ST, et après envoi d'un projet
reproduisant le signalement qu'il reconnaisse le bug dans le cas décrit. Mais à chaque fois c'est une perte de temps pour
faire un projet exemple

Salut Pascal,

Tu n'as pas envie de mettre ton propre Windev 10 à jour avec la
dernière version 50o ?
Tu pourrais ensuite tester et voir si le problème est réglé.

Qu'en penses-tu?

Je ne souhaite pas pour l'instant passer en 050o, parce que dans la 45 la gestion des masques d'affichage monétaires à encore une
fois changée!! Il me faut reprendre une partie de mes codes et j'ai autre chose à faire que de tout modifier pour gérer les
monétaires à chaque modif de version. Comme il n'y a pour l'instant aucune correction aux bugs que j'ai de signalés (certains
depuis 1 1/2 ans) je ne vois pas l'interet.

--
Pascal
N0.pascal.SPAM@efpe.biz
Ne garder que le prénom pour me joindre