[Bug] [Contexte HF indépendant et HFiltre()]
Jean Cherche
Il y a une semaine j'avais posté un message ( voir en fin de ce
message ) dans lequel je proposai un projet exemple pour découvrir un
bug bien pénible si on utilise HFiltre().
Une seule personne m'a demandé de lui envoyé le projet...
Hier, j'ai eu une réponse de PCSoft comme quoi ils avaient noté le
problème, etc, etc.....
Faites donc attention si vous utilisez ( ou pas ) le contexte
indépendant et surtout HFiltre()
A +
Jean Kooooooooool
Bonjour à tous,
Voilà, c'est moi Jean Cherche....
Mes enfants m'appellent aussi Papa Gogo,
Mes amiEs m'appelaient il y a quelques années Joli Coeur - mais c'est
du passé.
Donc, pour en revenir au vif du sujet, c'est simple : ( en vrac... )
1) j'utilise WinDev 7.5 : il y a du bon, il y a du très mauvais mais
je ne le dénigre pas, je m'énerve quand ca va pas...
2) j'aime WinDev MAIS je regrette tous les problèmes que j'ai à cause
de bug lié au 4LG et SURTOUT à la base de donnée HF 7
3) ces derniers temps, j'ai bossé comme un fou d'ou ma réponse tardive
4) demandez moi le projet + Protocole de reproduction + liste des
points ouverts/fermés ( 64 ) avec PCSoft : adresse E-Mail
tr...@mpisa.ch
Allez, le monde est assez pourri pour que l'on se tape dessus. Keep
Cool and Peace...
Gauthier TREU ( aujourd'hui : Jean Doute )
Fabrice Burghgraeve
;-)
"Jean Cherche" <tr...@mpisa.ch> a écrit dans le message de news:
ea9d0f1.03040...@posting.google.com...
> Bonjour à tous,
>
> Il y a une semaine j'avais posté un message ( voir en fin de ce
> message ) dans lequel je proposai un projet exemple pour découvrir un
> bug bien pénible si on utilise HFiltre().
>
> Une seule personne m'a demandé de lui envoyé le projet...
>
> Hier, j'ai eu une réponse de PCSoft comme quoi ils avaient noté le
> problème, etc, etc.....
>
> Faites donc attention si vous utilisez ( ou pas ) le contexte
> indépendant et surtout HFiltre()
>
> A +
>
> Jean Kooooooooool
>
>
>
Nous avons etudie votre probleme avec attention :)
Nous avons bien enregistre votre ....
Nan je deconne....
Tu sais, moi, ce que j'en pense du ST ?
Ben je le dis pas sinon je risque une attaque en justice...
Mais c'est pas parce que l'immense competence du ST te dit qu'il y a un bug
qu'il y en a vraiment un....
Quand il y en a, il ne savent pas le reproduire.
Quand il y en a, pas, ils savent...
Tu dois etre mieux vu que moi....
Bon c'est pas que je veuille t'embeter, mais franchement, en regardant ton
projet, je ne vois pas d'erreur (de windev)...
Je vois par contre des erreurs de toi......
En effet :
Ce que tu decris comme etant un probleme n'en est pas un comme je
l'expliquais dans un message precedent.
Quand tu ouvres ta deuxieme fenetre, le filtre est toujours actif et il est
copie du precedent....
Donc tu peux enregistrer tes donnees, mais quand tu les lis le filtre est
actif....
Donc *ce* probleme n'en est pas vraiment un...
Viens la suite.
Donc tu fais ca une premiere fois, tu dis que c'est un probleme, tu vides
ton jeu de test, tu recomences...
La deuxieme fois, tu sais lire tes enregs, donc tu dis qu'il n'y a plus de
probleme.....
Outre le fait que si probleme il y avait, ce serait la deuxieme fois (filtre
inactif) et pas la premiere, il y a autre chose qui est bancale dans ton
projet...
(excuse moi si je te fais mal, c'est pour ton bien :) )
En effet, regarde le code que tu as mis pour vider le jeu de test :
hcreation(ope) !!!!!!
Ah mais ca c'est pas logique.
Tu definit un fichier.
Tu crees un filtre dessus (contexte hyperfile sur ce fichier)
et puis apres tu detruits le fichier et tu en recree un nouveau avec les
memes carac .
C'est pas logique...
Soit windev remet le contexte a zero, soit il considere que ce n'est plus le
meme fichier.
J'ai change ton code en ca :
(le tein est entre parentheses pour les lecteurs qui ont pas le projet)
//hcreation(OPE)
//TableAffiche(TF_OPE,taDébut)
TANTQUE Vrai
HLitPremier(OPE)
SI HEnDehors ALORS SORTIR
HSupprime()
FIN
TableAffiche(TF_OPE,taDébut)
Bon c'est peut-etre pas tres beau c'est mon premier c ode hyperfile :)
Et ben la tout se passe suivant la logique...
Si le filtre est actif, le parcours ne supprime pas les enregs filtres bien
sur...
Il faudrait donc soit :
1) desactiver et reactiver le filtre avant de tout supprimer
2) ou encore parcourir le fichier suivant une autre clef de parcours et la
ca marche, ce qui donne ca :
POUR TOUT OPE sur IDOPE_PERE
Trace("IDOPE = " + OPE.IDOPE)
HSupprime()
FIN
TableAffiche(TF_OPE,taDébut)
Voila.
Ca c'etait bien sur dans le cas ou les contextes independants sont
actives...
Dans la mesure ou l'aide dit que si il ne sont pas actives ca fait n'importe
quoi, j'ai pas teste la deuxieme partie,
mais bon ca fait surement n'importe quoi :)
(Dans l'aide c'est pas ecrit comme ca mais c'est ce que ca veut dire)
Ma conclusion est donc que j'avais raison et que tu avais tord :)
( ahhh j'aime bien dire ca he he he)
Ma deuxieme conclusion est que la preuve de la competence du ST n'est plus a
faire,
mais elle est faite un fois de plus sur ce coup la...
Ma troisieme conclusion c'est que Herve s'est tout autant plante que toi,
mais que lui a ete desagreable avec Peter et moi,
donc la prochaine fois il devra bien reflechir avant de m'insulter parce que
la il a l'air con...
Allez !!!!
A plus et bonne prog...
--
Fabrice Burghgraeve
Computer & Services
f_pas_de_spa...@computeretservices.com
(enlevez le _pas_de_spam_ pour me répondre en privé)
(P.S. : si t'utilisais une vraie base de donnee, tu serais pas emmerde avec
toutes ces conneries...)
Jean Cherche
Donc tu as raison mais pas totalement car ... c'est difficile à
expliquer.
Le comportement avec ou sans contexte HF indépendant n'est pas clair
dans le cas d'un filtre.
Je cherche dès que je peux (la semaine prochaine) et je vous tiens au
courant.
Merci
Jean Comprendplu
"Fabrice Burghgraeve" <f_pas_de_spa...@computeretservices.com> wrote in message news:<b6ut3p$cj0$1...@news.nordnet.fr>...
Fabrice Burghgraeve
"Jean Cherche" <tr...@mpisa.ch> a écrit dans le message de news:
ea9d0f1.03040...@posting.google.com...
> Bien vu pour le HCréation().
> Donc tu as raison mais pas totalement car ... c'est difficile à
> expliquer.
Bah pas tellement...
ou plutot si...
C'est difficile a expliquer dans la mesure ou on n'a pas les source de
windev, et que PCSOFT ne fait pas toujours preuve de beaucoup de
transparence donc on n'est pas pret d'avoir la "vraie" explication...
Le fait c'est qu'en tant que programmeur windev, on manipule les fichiers
(avec les variables d'etats correspondantes) par leur nom...
Mais en interne, c'est surement pas le cas...
Dans "le fond" de windev, les fichiers se manipulent avec des entiers (file
descriptor) et les variables d'etats sont probablement geres dans une
structure associee a chaque fichier..
Il y a fort a parier que quand tu fait un hcreation du meme fichier, il
remette les variables d'etats a 0.
C'est logique...
Et en tout cas c'est pas logique de definir un filtre (dans ton cas) sur
quelque chose (le fichier),
puis apres de definir un nouveau fichier avec le meme nom et de penser que
le filtre est toujours actif...
Si on fait une analogie "papier", disons que ton fichier c'est une feuille
de papier avec des cases.
T'as un stylo et une gomme pour ecrire et effacer.
Alors donc tu prends une feuille blanche.
Tu dessines des cases dessus pour ranger ton tableau (c'est le fichier tu
viens de faire un hcreation)
Dans ta tete, ou dans la marge de la feuille, il y a les variables d'etats
qui te disent si par exemple quand tu cherche un nom dans la feuille il y
est...
Ou si tu parcours tous les noms dans la liste, fais des petites croix dans
la marge jusqu'a ce qu'il n'y ait plus de ligne a traiter (hendehors)
Apres tu remplis les cases etc... (hajoute)
Si tu veux effacer ta feuille de papier (ton fichier donc),
alors tu prends ta gomme et t'efface tout.... Tu te retrouve avec le meme
fichier, mais vide... (avec juste les cases)
Ce que t'as fait avec ton hcreation, c'est que t'as jete la feuille dans la
corbeille a papier, t'as pris une nouvelle feuille, et t'as redessine les
cases dessus...
> Le comportement avec ou sans contexte HF indépendant n'est pas clair
> dans le cas d'un filtre.
Maintenant, c'est vrai que la gestion des contextes independants, c'est pas
clair... (a fortiori pour moi qui n'y connais rien)
Ce qui est pas facile a comprendre, c'est que le contexte independant est en
fait une copie du contexte precedent...
Donc avec le filtre...
C'est un choix qu'a fait PCSOFT.
Ils auraient pu faire le choix de dire : "quand le contexte est independant,
on cree un contexte vierge" plutot que de dire :
"quand le contexte est independant, on recopie le contexte precedent"...
Mais imagine les consequences :
le contexte etant vierge, il te faudrait le rebatir en ouvrant ta
fenetre.........
C'est a dire re-ouvrir tous les fichiers, refaire les htrouve si tu suppose
arriver dans ta nouvelle fenetre en etant positionne sur le meme enreg que
precedemment etc etc..... (Comme on fait quand on a deux programmes lances
en parallele... On ouvre les fichiers dans chaque programme bien evidement)
Il y a bien une troisieme voie, qui peut-etre leverait ces ambiguites ...
Ce serait de recopier tout le contexte, puis de systematiquement effacer les
filtres.
Et de documenter la fonctionnalite comme ca...
Le probleme, si ils font ca maintenant, c'est que ceux qui utilisent le fait
que le contexte recopie le filtre pourraient se trouver avec un programme
qui ne fonctionne plus apres avoir fait la mise a jour de windev....
Donc en fait, a mon avis, il faut bien integrer le fait que les filtres sont
recopies avec le contexte, et faire avec dans les programmes...
Dans ton cas (et dans le cas general), le plus simple est peut-etre de
systematiquement supprimer les filtres en ouvrant une fenetre avec contexte
independant... (sur les fichiers qui seront accedes dans la fenetre...)
Tu aura alors le comportement auquel tu t'attends...
(parce que *a priori*, quand une fenetre est ouverte, elle peut l'etre de
n'importe quelle autre, et comment alors savoir quel est le filtre actif ???
Ce qui veut dire que la fenetre fille peut avoir un comportement different
suivant la fenetre qui l'a appelee,
et que un jour en l'appelant d'une nouvelle fenetre (ou d'un autre projet)
ca va planter et il faudra perdre du temps a chercher pourquoi )
> Je cherche dès que je peux (la semaine prochaine) et je vous tiens au
> courant.
> Merci
Y'a pas de quoi.
Et merci a toi de passer du temps a essayer de comprendre ces trucs
compliques et a ainsi debroussailler le terrain pour ceux qui se lancent...
(y'a du boulot, le jardinier est en vacances, il vend de la soupe sur une
plage ensoleillee avec un meuf en maillot de bain :) )
>
> Jean Comprendplu
>
>
>
(...)
A+
Et pour terminer sur une note humoristico-philosophique appropriee a la
situation ;-)
Medite cette loi de Murphy :
"L'ordinateur ne fait pas ce qu'on veut qu'il fasse. L'ordinateur fait ce
qu'on lui dit de faire..."
Jean Cherche
Alors, j'ai eu le temps de refaire un test selon mon projet test
(envoyé à PCSoft) et la procédure à suivre (en format PDF - qu'il faut
suivre sinon on y comprend rien...).
J'ai modifié selon conseil de Fabrice (merci encore Fabrice !) le code
du bouton "BP_ViderTest". Voici le nouveau code :
LOCAL
rqDelOPE est une Source de Données
Trace("Enleve filtre avant DELETE : " + HDésactiveFiltre(OPE))
HExécuteRequêteSQL(rqDelOPE,hRequêteDéfaut,"DELETE FROM OPE")
HAnnuleDéclaration(rqDelOPE)
ExécuteTraitement(CC_FiltreActif, trtInit)
//hcreation(OPE)
TableAffiche(TF_OPE,taDébut)
La différence avec le code de Fabrice (une boucle sur le fichier OPE
pour supprimer les records en tenant compte du filtre actif ou non) :
- je désactive le filtre AVANT
- je passe par une requête SQL (tellement simple)
CONCLUSION :
Le comportement que j'ai décris dans le fichier PDF n'a pas bougé d'un
pouce (homris la valeur des ID qui ne sont pas réinitialisés à 1 du
fait que je ne fais pas de HCreation(OPE) !
Donc, le problème signalé à PCSoft est d'actualité, j'en suis de plus
en plus persuadé. Maintenant, c'est à PCDur de définir si :
- il y a un problème avec leur L8G
- il y a un problème avec leur aide sur les fonctions du L8G
- il y a un problème sur leur site de téléchargement de nouvelles
versions où il est écrit : Régressions : pas de régressions détéctée à
ce jour (il faudrait peut-être arréter les copier-coller SVP)
Jean Aiduboulot
"Fabrice Burghgraeve" <f_pas_de_spa...@computeretservices.com> wrote in message news:<b71728$hce$1...@news.nordnet.fr>...
Jean Cherche
Nouvelle loi de Murphy (actualisée pour le 3ème millénaire) :
"Quand l'ordinateur ne fait pas ce qu'on veut qu'il fasse, on change
d'ordinateur..."
Jean PoetePouet
Fabrice Burghgraeve
eh eh
Mais quand est-ce que tu va dire que j'avais raison ???
"Jean Cherche" <tr...@mpisa.ch> a écrit dans le message de news:
ea9d0f1.03040...@posting.google.com...
> Re-re-re-bonjour,
>
> Alors, j'ai eu le temps de refaire un test selon mon projet test
> (envoyé à PCSoft) et la procédure à suivre (en format PDF - qu'il faut
> suivre sinon on y comprend rien...).
>
> J'ai modifié selon conseil de Fabrice (merci encore Fabrice !) le code
y'a pas de quoi...
> du bouton "BP_ViderTest". Voici le nouveau code :
>
> LOCAL
> rqDelOPE est une Source de Données
>
> Trace("Enleve filtre avant DELETE : " + HDésactiveFiltre(OPE))
> HExécuteRequêteSQL(rqDelOPE,hRequêteDéfaut,"DELETE FROM OPE")
> HAnnuleDéclaration(rqDelOPE)
> ExécuteTraitement(CC_FiltreActif, trtInit)
>
> //hcreation(OPE)
> TableAffiche(TF_OPE,taDébut)
>
>
> La différence avec le code de Fabrice (une boucle sur le fichier OPE
> pour supprimer les records en tenant compte du filtre actif ou non) :
> - je désactive le filtre AVANT
> - je passe par une requête SQL (tellement simple)
>
T'es vraiment pas en forme :)
Faut bosser moins :)
La difference avec mon code (qui n'est certes pas beau mais comme c'est mon
premier code hyperfile je fais ce que je peux :) ) c'est que le comportement
du mien suit la logique...
Il y a une autre difference, qui est beaucoup plus fondamentale :
QU'est-ce qui fait-y ton code :
ExécuteTraitement(CC_FiltreActif, trtInit)
???
Il fait ca :
MoiMême = Faux
CS_Cle = ""
C'est a dire qu'il change la valeur d'une variable, et la valeur d'un
interrupteur...
Faudrait peut etre penser a reactiver le filtre si tu voulais qu'il soit
actif...
Transforme ton code en ce code : (rien a moi la dedans, que de ton code)
ExécuteTraitement(BP_EnlevFiltre, trtClic)
HExécuteRequêteSQL(rqDelOPE,hRequêteDéfaut,"DELETE FROM OPE")
HAnnuleDéclaration(rqDelOPE)
ExécuteTraitement(BP_PoseFiltre, trtClic)
et tu verra que ca marche...
>
> CONCLUSION :
> Le comportement que j'ai décris dans le fichier PDF n'a pas bougé d'un
> pouce (homris la valeur des ID qui ne sont pas réinitialisés à 1 du
> fait que je ne fais pas de HCreation(OPE) !
ma conclusion : ce qui n'a pas bouge, c'est que tu t'es encore trompe :)
Mais on peut pas t'en vouloir.
Il reste tellement de beubeugs dans windev 7.5, que perso, quand mon prog
fait n'importe quoi,
je me dis d'abord : "mais qu'est-ce qu'il fait en core ce windev ?!?"
plutot que : "Mais ou me suis-je trompe ?"
>
> Donc, le problème signalé à PCSoft est d'actualité, j'en suis de plus
> en plus persuadé. Maintenant, c'est à PCDur de définir si :
> - il y a un problème avec leur L8G
si seulement il n'y en avait qu'un !!!
Mais sur ce coup la c'est pas le cas tu devrais t'en persuader aussi :)
> - il y a un problème avec leur aide sur les fonctions du L8G
Disons que le comportement est surprenant, donc pas facile a saisir.
Il faudrait que l'aide soit plus claire avec un gros triangle rouge :
"ATTENTION les filtres sont toujours actifs quand on ouvre une fenetre a
contexte independant"
> - il y a un problème sur leur site de téléchargement de nouvelles
> versions où il est écrit : Régressions : pas de régressions détéctée à
> ce jour (il faudrait peut-être arréter les copier-coller SVP)
Le bug de l'image etire en fond d'ecran c'est une regression : ca marchait
en 7.0
>
>
> Jean Aiduboulot
>
>
>
Jean Passedénuiblanche :)
(ce qui est bien c'est qu'on peut en faire plein comme ca :) )
A+
Hervé KOCH
> mais que lui a ete desagreable avec Peter et moi,
> donc la prochaine fois il devra bien reflechir avant de m'insulter parce
que
> la il a l'air con...
>
m'expliquer en détail.
Mais là, je ne peux pas laisser passer de tels propos sans réagir
J'ai pris le temps de tester le projet de Jean Cherche et pas seulement en
suivant la procédure indiquée. Ce que tu n'a apparemment pas fait.
Il y a bien un bug, donc je ne pense pas être celui qui a l'air le plus con
de nous deux.
Je vous laisse avec la loi des bugs en cascade :
"Résoudre un bug rend apparent une dizaine d'autres bugs qu'il masquait. "
Fabrice Burghgraeve
"Hervé KOCH" <hk...@gtinformatique.com> a écrit dans le message de news:
b73eh0$nvb$1...@news-reader11.wanadoo.fr...
> > Ma troisieme conclusion c'est que Herve s'est tout autant plante que
toi,
> > mais que lui a ete desagreable avec Peter et moi,
> > donc la prochaine fois il devra bien reflechir avant de m'insulter parce
> que
> > la il a l'air con...
> >
> Je n'ai insulté personne jusqu'à présent, et je n'ai pas eu le temps de
> m'expliquer en détail.
Alors disosn que j'ai mal pris que tu dises que j'etais bien gentil mais que
ne m'interessait qu'a la forme et pas au fond.
C'est peut etre pas une insulte mais ca fait pas plaisir...
>
> Mais là, je ne peux pas laisser passer de tels propos sans réagir
> J'ai pris le temps de tester le projet de Jean Cherche et pas seulement en
> suivant la procédure indiquée. Ce que tu n'a apparemment pas fait.
Si bien sur...
Apparement ou ?
Dans les explications que j'ai donnees ?
Tu crois que j'ai pu les donner sans regarder dans le projet ?
>
> Il y a bien un bug, donc je ne pense pas être celui qui a l'air le plus
con
> de nous deux.
Bien...
Explique moi en quoi le comportement decrit est un bug alors...
C'est bien possible que je soit passe a cote de quelque chose.
Ce ne serait pas la premiere fois...
Mais pour l'instant mes arguments me semblent plus convaicants que les tiens
(qui sont inexistants).
Comme j'ai deja dit, je ne crois pas sans verifier ce que je lis sur les
NGs...
Tu affirmes que ce que decris Jean Cherche est un bug de windev...
D'accord pourquoi pas.... Il n'y a rien a priori qui dit que j'ai plus
raison que toi...
Mais explique...
Moi j'ai explique pourquoi c'etait pas un bug de windev, et j'ai trouve ou
etait l'illogisme dans le programme de Jean Cherche.
De ton cote, explique en quoi c'est un bug de windev et pourquoi son code
est logique.
Et alors on pourra confronter nos points de vue...
(Je propose egalement une treve dans les insultes ca apporte pas grand chose
au debat... Revenons en aux faits !!)
>
> Je vous laisse avec la loi des bugs en cascade :
>
> "Résoudre un bug rend apparent une dizaine d'autres bugs qu'il masquait. "
>
Jean Cherche
C'est à nouveau moi....
Alors, pour tout vous dire, Fabrice a raison quand au mot clé
HCréation() qui est un problème à part entière.
Donc, j'ai remplacé dans le bouton BP_ViderTest "Vider le jeu de test"
:
------------
1)
------------
//hcreation(OPE)
TableAffiche(TF_OPE,taDébut)
PAR
LOCAL
rqDelOPE est une Source de Données
Trace("Enleve filtre avant DELETE : " + HDésactiveFiltre(OPE))
HExécuteRequêteSQL(rqDelOPE,hRequêteDéfaut,"DELETE FROM OPE")
HAnnuleDéclaration(rqDelOPE)
ExécuteTraitement(CC_FiltreActif, trtInit)
TableAffiche(TF_OPE,taDébut)
ET j'ai reproduit le Protocole de reproduction : le traitement et le
résultat sont QUAND MEME illogiques !
------------
2)
------------
//hcreation(OPE)
TableAffiche(TF_OPE,taDébut)
PAR
// Partie de Fabrice Burghgraeve...
LOCAL
rqDelOPE est une Source de Données
ExécuteTraitement(BP_EnlevFiltre, trtClic)
HExécuteRequêteSQL(rqDelOPE,hRequêteDéfaut,"DELETE FROM OPE")
HAnnuleDéclaration(rqDelOPE)
ExécuteTraitement(BP_PoseFiltre, trtClic)
ET j'ai reproduit le Protocole de reproduction : le traitement et le
résultat sont EGALEMENT QUAND MEME illogiques !
Surtout que si on clic sur vider jeu de test, alors le filtre est
toujours ACTIF après donc heureusement que j'ai mis un bouton
BP_PoseFiltre !
CONCLUSION : problème il y a - soit dans la documentation ( j'en suis
également persuadé ) ; soit dans le L99G ( absolument sûr mais ou
exactement, je ne sais plus parceque je suis TRES fatigué... )
CONCLUSION 2 : je n'utilise plus les filtres dans mon application de
45'000 lignes et 210 objets.
CONCLUSION 3 : merci à Hervé et Fabrice pour le temps passé sur ce
problème, je bosse sur Genève, si jamais vous passez par là,
n'hésitez-pas, je vous offre une pression ( même un sérieux,
formidable ou botte ) pour en rigoler un bon coups et nous dé-strésser
un peu.
Bon WE ( je bosse jamais le Vendredi, Kooooool )
Jean Aiterminé
Avec mes meilleures salutations
######################################
NEW : changement e-mail : tr...@mpisa.ch
NEW : visitez notre site : www.mpisa.ch
######################################
M P I S A
Management de Projets Informatiques
Solutions et gestion pour la Prévoyance Institutionnelle
Gauthier TREU
Direction projets AS/400, WinDev
mailto:tr...@mpisa.ch
http://www.mpisa.ch
Tél. : 004122 / 345 66 44
Fax : 004122 / 344.76.06
Hervé KOCH
là ou on le croit, démonstration :
Je propose le petit test suivant (en utilisant le projet de Gauthier)
Ajouter un bouton 'Lire' sur la fenêtre principale contenant le code suivant
:
//------------------------Début du code Clic sur Lire
Trace("Début lecture POUR TOUT sur IDOPE_PERE :")
POUR TOUT OPE sur IDOPE_PERE
Trace("IDOPE = " + OPE.IDOPE)
FIN
Trace("")
Trace("Début lecture POUR TOUT sur IDOPE :")
POUR TOUT OPE sur IDOPE
Trace("IDOPE = " + OPE.IDOPE)
FIN
Trace("")
Trace("Début lecture POUR TOUT sur IDINTITULE")
POUR TOUT OPE sur IDINTITULE
Trace("IDOPE = " + OPE.IDOPE)
FIN
Trace("")
//--------------------------Fin du code
Vider le fichier de test
Créer un jeu d'enregistrements dans le fichier test.
Poser le filtre
Cliquer sur Lire
Trier la table sur IDOPE
Cliquer sur Lire
Trier la table sur INTITULE
Cliquer sur Lire
Trier la table sur IDOPE_PERE
Cliquer sur Lire
L'aide de HFiltre dit :
"Après l'exécution de la fonction HFiltre, le parcours du fichier doit
obligatoirement être effectué sur la rubrique renvoyée par la fonction
HFiltre. Si une autre rubrique est utilisée pour le parcours du fichier, le
filtre ne sera pas pris en compte."
Or le filtre est toujours pris en compte pour IDOPE_PERE (normal, c'est la
clé renvoyée par HFiltre !). Par contre, il est pris en compte également sur
la rubrique de tri de la table ce qui n'est pas correct (comme si
hRespecteFiltre était forcé).
Il y a donc bien un bug dans ce satané Windev !
Je crois que je vais m'empresser de faire un rapport au ST !
A+
PS : je propose également la trève ;-)
Fabrice Burghgraeve
"Hervé KOCH" <hk...@gtinformatique.com> a écrit dans le message de news:
b74431$754$1...@news-reader12.wanadoo.fr...
> J'ai pu passer plus de temps sur le problème et le bug n'est pas forcément
> là ou on le croit, démonstration :
>
> Je propose le petit test suivant (en utilisant le projet de Gauthier)
>
(...)
>
> L'aide de HFiltre dit :
> "Après l'exécution de la fonction HFiltre, le parcours du fichier doit
> obligatoirement être effectué sur la rubrique renvoyée par la fonction
> HFiltre. Si une autre rubrique est utilisée pour le parcours du fichier,
le
> filtre ne sera pas pris en compte."
>
> Or le filtre est toujours pris en compte pour IDOPE_PERE (normal, c'est la
> clé renvoyée par HFiltre !). Par contre, il est pris en compte également
sur
> la rubrique de tri de la table ce qui n'est pas correct (comme si
> hRespecteFiltre était forcé).
>
> Il y a donc bien un bug dans ce satané Windev !
Oui oui je confirme ce comportement...
J'ai meme verifie en triant les tables par programmation, en rajoutant un
bouton "Lance le test" qui fait :
ExécuteTraitement(BP_ViderTest,trtClic);
ExécuteTraitement(BP_CreerJeuTest,trtClic);
ExécuteTraitement(BP_EnlevFiltre,trtClic); // pour etre bien sur... Le
bouton vidertest active le filtre avec ma modif
ExécuteTraitement(BP_PoseFiltre,trtClic); // mais ces deux ligne sne servent
a rien
ExécuteTraitement(lister,trtClic)
TableTrie(TF_OPE,TF_OPE.IDOPE);
ExécuteTraitement(lister,trtClic)
TableTrie(TF_OPE,TF_OPE.IDINTITULE);
ExécuteTraitement(lister,trtClic)
TableTrie(TF_OPE,TF_OPE.IDOPE_PERE);
Et c'est pareil..... (On sait jamais... des fois que...)
Donc effectivement, sur ce point la on est d'accord, il y a un bug...
(Du moins ca y ressemble dans l'etat actuel de mes connaissances)
(D'ailleurs, c'est surement pas moi qui ai dit qu'il n'y avait aucun bug
dans windev ;-) )
Mais ca a pas grand chose a voir avec le "probleme" de depart (filtre actif
apres ouverture de fenetre avec contexte independant)
Qui lui n'est pas un bug...
>
> Je crois que je vais m'empresser de faire un rapport au ST !
>
> A+
>
> PS : je propose également la trève ;-)
>
Oui faisons ca :)
On va mieux avancer en s'entraidant qu'en se tirant dans les pattes...
C'est deja pas evident les rapports avec le ST, alors si ca devient pas
evident non plus entre les gens de la communaute, on va plus avancer d'un
iota :)
Donc je m'excuse de la durete de mes propos a ton egard... (mais bon fallait
pas m'enerver apres je mords :) )
En tout cas, si d'aventure le ST ne sait pas reproduire ton probleme, moi
j'y arrive...
On est donc 2 pour l'instant.....
A l'occasion, il faudrait qu'on ecrive une version "simplifiee" du protocole
de reproduction du bug pour que tout le monde sache exactement de quoi on
parle :)
Parce que la on est "à 3"...
(meme si je suis sur que gauthier voudra bien envoyer son projet a qui le
demande)
en tout cas, ca fait 4 bugs trouves sur les tables en 4 jours.... :(
pas bien fini tout ca... :(
A+