Depuis WD 7.0 j'ai un problème que je n'ai jamais compris, mais toujours
réussi à contourner. C'est pourtant embêtant et puisqu'il s'est présenté
encore une fois j'aimerais savoir si quelqu'un a fait la même expérience
et trouvé la raison pour ce comportement:
Il s'agit d'une fenêtre avec une table fichier, alimenté par une
requête, sur le premier onglet et les données liées au fichier sur les
onglets 2 à 4. Afin de limiter le trafic réseau on ne lit le fichier que
pour raffraichir la requête et lorsqu'on veut accéder aux données sur
les onglets 2 à 4. L'ID est obtenu de la table.
On utilise des méthodes d'une classe pour se positionner dans le fichier
et envoyer les données vers l'écran
si HLitRecherchePremier(:cMasterTable, :cMasterIDFld, :nIDSQL) alors
FichierVersEcran (:cMasterWindow)
fin
HLitRecherche.. se positionne sur le bon enregistrement, mais
l'exécution de FichierVersEcran MODIFIE cette position sur un
enregistrement totalement différent, p.ex. de l'ID 41026 à 1474
(toujours vers le même pourtant, des fois différent suivant l'onglet
qu'on accède). Nous avons essayé avec toutes les formes de
FicherVersEcran, avec nom de la fenêtre plus nom de fichier, ainsi que
rien du tout. Le comportement reste le même. Un des onglets contient un
champ LookUp multi-fichier, tous les autres champs sont liés au même
fichier.
La recherche des données se fait dans "A chaque modification" de
l'onglet et il n'y a aucun autre traitement auparavant.
Le problème ne se pose pas lorsqu'on déplace la recherche des données
dans "Sélection d'une ligne" de la table sur le premier onglet. Mais
cette lecture est évidemment inutile juste pour se déplacer dans la table.
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
mat
mat wrote:
Bonjour,
Depuis WD 7.0 j'ai un problème que je n'ai jamais compris, mais toujours réussi à contourner. C'est pourtant embêtant et puisqu'il s'est présenté encore une fois j'aimerais savoir si quelqu'un a fait la même expérience et trouvé la raison pour ce comportement:
Il s'agit d'une fenêtre avec une table fichier, alimenté par une requête, sur le premier onglet et les données liées au fichier sur les onglets 2 à 4. Afin de limiter le trafic réseau on ne lit le fichier que pour raffraichir la requête et lorsqu'on veut accéder aux données sur les onglets 2 à 4. L'ID est obtenu de la table.
On utilise des méthodes d'une classe pour se positionner dans le fichier et envoyer les données vers l'écran
si HLitRecherchePremier(:cMasterTable, :cMasterIDFld, :nIDSQL) alors FichierVersEcran (:cMasterWindow) fin
HLitRecherche.. se positionne sur le bon enregistrement, mais l'exécution de FichierVersEcran MODIFIE cette position sur un enregistrement totalement différent, p.ex. de l'ID 41026 à 1474 (toujours vers le même pourtant, des fois différent suivant l'onglet qu'on accède). Nous avons essayé avec toutes les formes de FicherVersEcran, avec nom de la fenêtre plus nom de fichier, ainsi que rien du tout. Le comportement reste le même. Un des onglets contient un champ LookUp multi-fichier, tous les autres champs sont liés au même fichier.
La recherche des données se fait dans "A chaque modification" de l'onglet et il n'y a aucun autre traitement auparavant.
Le problème ne se pose pas lorsqu'on déplace la recherche des données dans "Sélection d'une ligne" de la table sur le premier onglet. Mais cette lecture est évidemment inutile juste pour se déplacer dans la table.
Je viens de trouver que le problème ne se produit non plus lorsque la méthode de recherche des données de la classe est appellé directement de "A chaque modification" de l'onglet au lieu d'être appellé par une autre méthode de la classe... Ceci ne m'explique pas la chose mais est au moins un contournement valable qui évite des lectures inutiles du fichier.
mat wrote:
Bonjour,
Depuis WD 7.0 j'ai un problème que je n'ai jamais compris, mais toujours
réussi à contourner. C'est pourtant embêtant et puisqu'il s'est présenté
encore une fois j'aimerais savoir si quelqu'un a fait la même expérience
et trouvé la raison pour ce comportement:
Il s'agit d'une fenêtre avec une table fichier, alimenté par une
requête, sur le premier onglet et les données liées au fichier sur les
onglets 2 à 4. Afin de limiter le trafic réseau on ne lit le fichier que
pour raffraichir la requête et lorsqu'on veut accéder aux données sur
les onglets 2 à 4. L'ID est obtenu de la table.
On utilise des méthodes d'une classe pour se positionner dans le fichier
et envoyer les données vers l'écran
si HLitRecherchePremier(:cMasterTable, :cMasterIDFld, :nIDSQL) alors
FichierVersEcran (:cMasterWindow)
fin
HLitRecherche.. se positionne sur le bon enregistrement, mais
l'exécution de FichierVersEcran MODIFIE cette position sur un
enregistrement totalement différent, p.ex. de l'ID 41026 à 1474
(toujours vers le même pourtant, des fois différent suivant l'onglet
qu'on accède). Nous avons essayé avec toutes les formes de
FicherVersEcran, avec nom de la fenêtre plus nom de fichier, ainsi que
rien du tout. Le comportement reste le même. Un des onglets contient un
champ LookUp multi-fichier, tous les autres champs sont liés au même
fichier.
La recherche des données se fait dans "A chaque modification" de
l'onglet et il n'y a aucun autre traitement auparavant.
Le problème ne se pose pas lorsqu'on déplace la recherche des données
dans "Sélection d'une ligne" de la table sur le premier onglet. Mais
cette lecture est évidemment inutile juste pour se déplacer dans la table.
Je viens de trouver que le problème ne se produit non plus lorsque la
méthode de recherche des données de la classe est appellé directement de
"A chaque modification" de l'onglet au lieu d'être appellé par une autre
méthode de la classe... Ceci ne m'explique pas la chose mais est au
moins un contournement valable qui évite des lectures inutiles du fichier.
Depuis WD 7.0 j'ai un problème que je n'ai jamais compris, mais toujours réussi à contourner. C'est pourtant embêtant et puisqu'il s'est présenté encore une fois j'aimerais savoir si quelqu'un a fait la même expérience et trouvé la raison pour ce comportement:
Il s'agit d'une fenêtre avec une table fichier, alimenté par une requête, sur le premier onglet et les données liées au fichier sur les onglets 2 à 4. Afin de limiter le trafic réseau on ne lit le fichier que pour raffraichir la requête et lorsqu'on veut accéder aux données sur les onglets 2 à 4. L'ID est obtenu de la table.
On utilise des méthodes d'une classe pour se positionner dans le fichier et envoyer les données vers l'écran
si HLitRecherchePremier(:cMasterTable, :cMasterIDFld, :nIDSQL) alors FichierVersEcran (:cMasterWindow) fin
HLitRecherche.. se positionne sur le bon enregistrement, mais l'exécution de FichierVersEcran MODIFIE cette position sur un enregistrement totalement différent, p.ex. de l'ID 41026 à 1474 (toujours vers le même pourtant, des fois différent suivant l'onglet qu'on accède). Nous avons essayé avec toutes les formes de FicherVersEcran, avec nom de la fenêtre plus nom de fichier, ainsi que rien du tout. Le comportement reste le même. Un des onglets contient un champ LookUp multi-fichier, tous les autres champs sont liés au même fichier.
La recherche des données se fait dans "A chaque modification" de l'onglet et il n'y a aucun autre traitement auparavant.
Le problème ne se pose pas lorsqu'on déplace la recherche des données dans "Sélection d'une ligne" de la table sur le premier onglet. Mais cette lecture est évidemment inutile juste pour se déplacer dans la table.
Je viens de trouver que le problème ne se produit non plus lorsque la méthode de recherche des données de la classe est appellé directement de "A chaque modification" de l'onglet au lieu d'être appellé par une autre méthode de la classe... Ceci ne m'explique pas la chose mais est au moins un contournement valable qui évite des lectures inutiles du fichier.
