Discussion :

[osfou]

Bonjour, je suis débutant avec windev et du coup je bute sur des choses je pense simple.
Voila mon souci, j'ai un fichier avec des noms et prénoms, avec ce fichier j'ai fait une requête qui classe par ordre alphabétique, je souhaite juste parcourir cette requête dans l'ordre alphabétique (par code bien sur). Le problème est que le parcours ce fait dans l'ordre de saisie du fichier et non dans l'ordre de la requête ce qui n'est pas du tout la même chose si l'on veux faire un bouton suivant ou précédent. Voila si une âme charitable pouvait me donner une piste à suivre !! je vous copie le bout de code qui me pose problème. D'avance merci à vous.

HLitRecherchePremier(REQ_nom_prenom_adhérent,IDAdérents,COMBO_adhérents,hRespecteFiltre)
HLitSuivant(REQ_nom_prenom_adhérent)
//test si dernier enregistrement
SI HEnDehors()=Vrai ALORS
//mise en place du premier enreegistrement
HLitPremier(REQ_nom_prenom_adhérent)
COMBO_adhérents=REQ_nom_prenom_adhérent.IDAdérents
ExécuteTraitement(COMBO_adhérents,trtSélection)
HExécuteRequête(REQ_nom_prenom_adhérent)
RETOUR
SINON
//mise en place du suivant
COMBO_adhérents=REQ_nom_prenom_adhérent.IDAdérents
ExécuteTraitement(COMBO_adhérents,trtSélection)
RETOUR
FIN

[Hemgé]

Bonjour et bienvenue osfou !

Tout d'abord un petit préliminaire.
Quand vous ouvrez une discussion, n'oubliez pas de renseigner le Préfixe, qui permet de savoir aux intervenants sur quelle version de Windev vous travaillez.
Les fonctionnalités de Windev s'enrichissent, voire évoluent avec les versions et les solutions peuvent donc dépendre de votre version.

Quand vous postez du code, utilisez la balise code : # (située dans le bandeau au-dessus de la zone d'encodage), ce qui rendra votre code plus lisible.

Maintenant votre problème.
Tout d'abord, s'il s'agit d'alimenter une Combo, je vous suggère d'aller dans l'aide : Combo, puis "Combo auto-alimentée" et ""Manipuler un champ combo par programmation".

Vous aurez au moins un exemple concret pour procéder.

Par ailleurs, une clé alphabétique sur le nom de l'adhérent (et pas adérent sans h) pourrait vous aider en utilisant les propriétés FichierParcouru, RubriqueParcourue etc (voir l'aide, "Manipuler un champ combo par programmation")

Concernant votre code tel qu'il est maintenant (et qui doit être complètement revu à mon sens), quelques informations :

1. Votre //test si dernier enregistrement
   Il faudrait le mettre le mettre avant HLitSuivant, puisque le HLitRecherchePremier pourrait échouer
2. IDAdérent est "Nom de la rubrique sur laquelle la recherche doit être effectuée. " et vous parcourez donc votre fichier dans l'ordre de IDAdérent qui est sans doute l'identifiant automatique et correspond donc à l'ordre de saisie.
3. hRespecteFiltre correspond à un filtre que vous devez vérifier ou à la clause ORDER BY de votre requête, mais comme vous avez renseigné IDAdérent comme rubrique de parcours, elle n'est plus prise en compte (voir l'aide sur HLitSuivant)

Bon courage et bon dimanche

Hemgé

[osfou]

Bonjour, tout d'abord merci pour la réponse rapide, je vais essayer d’être plus explicite sur mon problème car la réponse ne correspond pas vraiment à mon souci ou alors je n'ai rien compris (ce qui n'est pas exclu).

J'ai un fichier avec une rubrique 'Nom' et 'Prénom', j'ai fais une requête pour avoir une rubrique 'Nom Prénom' triée par ordre alphabétique, cette requête renseigne une liste Combo, je souhaite faire un bouton 'suivant' en récupérant la valeur sélectionnée dans la liste Combo et lire l'enregistrement suivant de la requête (qui est triée par ordre alphabétique), le souci est que la lecture de l'enregistrement suivant se fait dans l'ordre de saisie de mon fichier et non dans l'ordre de trie de la requête. Voila j’espère avoir été plus clair et j’espère également que quelqu'un à une réponse à me donner.
D'avance merci et bonne journée.

PS: j'ai bien renseigné le préfixe (WD15) et je ne savais pas qu'il fallait mettre une balise code avant le code (c'est ma première discussion).

[frenchsting]

Ta requête est bien :

Code :

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

1
2
3
SELECT IdAdherents,Nom,Prenom
FROM Adherents
ORDER BY Nom,Prenom

?

[EDIT] PS :
Ceci est juste :

Code :

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

1
2
3
HLitSuivant(REQ_nom_prenom_adhérent)
//test si dernier enregistrement
SI HEnDehors()=Vrai ALORS

Mais je préfére écrire ceci

Code :

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

1
2
3
HLitSuivant(REQ_nom_prenom_adhérent)
//test si dernier enregistrement
SI HEnDehors(REQ_nom_prenom_adhérent) ALORS

1 : Mettre le REQ_nom_prenom_adhérent permet d'être sûr que c'est bien de cette requête/fichier dont on parle.
2 : hendehors et htrouve renvoient des booléens (vrai ou faux). Je péfére écrire à la façon de l'algébre booléen (pas htrouve est la même chose que htrouve = faux).

[osfou]

Merci de me répondre, je cherche depuis un certain temps et je commence à saturé.
Voici le code de ma requête:

Code :

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

1
2
3
4
5
6
7
SELECT 
	CONCAT(Adhérents.Nom,' ',Adhérents.Prénom) AS Nom_Prénom,	
	Adhérents.IDAdhérents AS IDAdhérents
FROM 
	Adhérents
ORDER BY 
	Nom_Prénom ASC

je suis d'accord sur le fait qu'il est préférable de mettre REQ_nom_prenom_adhérent mais je ne comprends pas pourquoi le parcours se fait dans l'ordre du fichier et non dans l'ordre de la requête avec la fonction hlitsuivant ???

[Nicolas_Jeanneau]

Bonjour,

la combo est liée à la requête. Cette requête envoie des données triées mais si la combo à une clef de parcours qui est l'ID d'adhérents alors le tri sera remplacé par celui sur l'ID. Mettre le parcours en automatique et il ne devrait plus changer celui de la requête.

à bientôt,

Nicolas

[frenchsting]

Si tu simplifies ta requête :

Code :

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

1
2
3
4
5
6
7
8
SELECT 
	Adhérents.Nom AS Nom,
	Adhérents.Prénom AS Prénom,	
	Adhérents.IDAdhérents AS IDAdhérents
FROM 
	Adhérents
ORDER BY 
	Nom,Prénom ASC

Qu'est ce que ça donne ?

Je pense que le tri sur le concat ne doit pas fonctionner.
D'expérience, en requête SQL windev, il vaut mieux faire le plus simple possible et retravailler en code après...

Code :

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

1
2
Nom_Prénom est une chaine
Nom_Prénom = REQ_nom_prenom_adhérent.Nom + " " + REQ_nom_prenom_adhérent.Prénom

[osfou]

Bonjour, la rubrique de parcours est déjà sur 'automatique', je suis en train de faire des essais avec un code le plus simple possible mais je ne comprends toujous pas.

Code :

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

1
2
3
4
HLitRecherchePremier(REQ_nom_prenom_adhérent,IDAdhérents,COMBO_adhérents) //recherche dans la requete en fonction de la selection dans la liste Combo
Info(REQ_nom_prenom_adhérent.Nom_Prénom) //recup de la valeur en cours
HLitSuivant(REQ_nom_prenom_adhérent)
Info(REQ_nom_prenom_adhérent.Nom_Prénom) //recup de la valeur aprés lecture du suivant

même comme ça la lecture se fait dans l'ordre de saisie du fichier et non dans l'ordre de la requête.
Tout en tapant le message ci-dessus j’étais en train de réfléchir au message de frenchsting et je viens de tester ça

Code :

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

1
2
3
4
HLitRecherchePremier(REQ_nom_prenom_adhérent,Nom_Prénom,COMBO_adhérents..ValeurAffichée) //recherche dans la requete en fonction de la selection dans la liste Combo
Info(REQ_nom_prenom_adhérent.Nom_Prénom) //recup de la valeur en cours
HLitSuivant(REQ_nom_prenom_adhérent)
Info(REQ_nom_prenom_adhérent.Nom_Prénom) //recup de la valeur aprés lecture du suivant

pour le moment ça a l'air de fonctionner !! je continu à faire des test et si c'est concluant je le note comme résolu.
Merci beaucoup pour vos réponse à tous.

[Nicolas_Jeanneau]

Si tu fais un HLitRecherchePremier, je crois qu'il optimise en changeant la clef de parcours pour la mettre sur le champ si possible.
Ce qui pourrait expliquer le changement de tri.

[Hemgé]

Bonjour,

Je vous renvoie à mon message d'hier :

...
Concernant votre code tel qu'il est maintenant (et qui doit être complètement revu à mon sens), quelques informations :

1. Votre //test si dernier enregistrement
   Il faudrait le mettre le mettre avant HLitSuivant, puisque le HLitRecherchePremier pourrait échouer
2. IDAdérent est "Nom de la rubrique sur laquelle la recherche doit être effectuée. " et vous parcourez donc votre fichier dans l'ordre de IDAdérent qui est sans doute l'identifiant automatique et correspond donc à l'ordre de saisie.
3. hRespecteFiltre correspond à un filtre que vous devez vérifier ou à la clause ORDER BY de votre requête, mais comme vous avez renseigné IDAdérent comme rubrique de parcours, elle n'est plus prise en compte (voir l'aide sur HLitSuivant)

N'oubliez pas de remonter votre test si dernier enregistrement, parce que cela n'a pas été traité par les autres intervenants

Quant à votre questionnement sur la raison de ce mauvais ordre de parcours, je vous avais renvoyé à l'aide sur vos deux instructions : HlitRecherchePremier et HLitSuivant.

<Résultat> = HLitRecherchePremier(<Nom du fichier> , <Nom de la rubrique> , <Valeur recherchée> [, <Options>])
<Résultat> : Booléen …

<Nom du fichier> : Chaîne de caractères (avec ou sans guillemets)
<Nom de la rubrique> : Chaîne de caractères (avec ou sans guillemets)
Nom de la rubrique sur laquelle la recherche doit être effectuée. Cette rubrique peut être une clé de parcours ou non.
<Valeur recherchée> : Type correspondant à la valeur
Valeur de la rubrique recherchée.
<Options> : Constante ou combinaison de constantes optionnelle
…
hRespecteFiltre Le parcours prendra en compte le filtre mis en place avec la fonction HFiltre, même si la clé de parcours utilisée n'est pas optimisée pour le filtre. Rappel : la fonction HFiltre renvoie la clé de parcours optimisée pour le filtre.
Attention : dans ce cas, sur des fichiers de données de taille importante, des problèmes de performances peuvent survenir.

Vous aviez utilisé AdérentID (a priori l'identifiant automatique) qui est une clé de parcours de votre fichier, mais pas de votre requête.
Vous auriez dû utiliser - comme maintenant, dans votre dernier essai - Nom_Prénom qui est la "clé" de votre requête suite à l'ORDER BY.
A mon sens, le paramètre hRespecteFiltre est inutile, mais il faudrait tester.

Ensuite, le HLitSuivant :

<Résultat> = HLitSuivant([<Nom du fichier> [, <Nom de la rubrique de parcours>] [, <Options>]])
<Résultat> : Booléen …
<Nom du fichier> : Chaîne de caractères optionnelle (avec ou sans guillemets)
Nom du fichier de données, de la vue ou de la requête manipulé. …

<Nom de la rubrique de parcours> : Chaîne de caractères optionnelle (avec ou sans guillemets)
Nom de la rubrique utilisée pour parcourir le fichier de données, la vue ou la requête. Si ce nom n'est pas spécifié, la fonction HLitSuivant va utiliser :

• Dans le cas d'un fichier de données : la dernière rubrique de parcours utilisée sur ce fichier de données par la dernière fonction de gestion HyperFileSQL (fonction commençant par la lettre H). Si cette rubrique n'existe pas, la meilleure rubrique de parcours est automatiquement utilisée.
• Dans le cas d'une requête : le ORDER BY de la requête si il existe, sinon selon la dernière rubrique utilisée.
• Dans le cas d'une vue : la rubrique de tri de la vue (si elle existe), sinon sur la dernière rubrique utilisée.

Là, je vous avoue ne pas avoir de réponse, si ce n'est un constat :
Initialement, vous aviez traité le HliRecherchePremier comme une lecture sur un fichier en renseignant une clé valable pour le fichier sousjacent à la requête.
Ensuite, vous n'aviez pas mentionné le <Nom de la rubrique de parcours>, qui est optionnel et bizarrement alors que vous parcouriez une requête, la lecture continuait selon le mode par défaut dévolu à la lecture de fichiers, soit la dernière rubrique de parcours.

Dans votre dernière version, vous avez renseigné la bonne clé de parcours pour le HLitRecherchePremier, vous avez omis cette même rubrique (optionnelle) dans la cas du HLitSuivant et il continue bien selon le ORDER BY de la requête si il existe, sinon selon mais qui est en même temps la dernière rubrique utilisée, ce qui laisse subsister un petit doute quant à un éventuel problème de comportement de Windev dans ce cas de figure d'instructions qui manquaient de cohérence par rapport à l'organisation des données.

Il n'est donc plus étonnant que cela fonctionne maintenant.

Hemgé