J'ai fait un sac de noeuds dans ma base (Access 95), et je ne suis plus
très sûr de savoir par où ça s'ouvre.
J'ai un état à afficher avec un peu plus de 18000 enregistrements. La
requête principale s'ouvre assez vite, mais pour chaque enregistrement
il y a une requête secondaire pour trouver l'identité du contact, et là
pour exécuter tout ça ça prend quand même un paquet de minutes, bien
assez pour se demander si la machine ne serait pas plantée.
J'ai un formulaire frmPatienter, qui comme son nom l'indique invite
l'utilisateur à patienter un peu. Seulement là, patienter un peu, ça ne
suffit pas, il faut y mettre la dose. Alors, je voudrais ajouter une
barre de progression sur frmPatienter, histoire qu'on s'aperçoive
qu'effectivement, il se passe quelque chose.
Voilà le hic : je me heurte à une erreur 2478, Repaint ne peut pas être
exécuté dans ce mode d'affichage. CurrentView vaut 1, c'est l'affichage
en mode formulaire, classique.
Alors voilà comment ça s'articule :
- dans un sous-formulaire du formulaire de menu, un bouton lance la
procédure OuvreEtat, avec en paramètre le nom qu'on trouve dans la liste
à côté
- OuvreEtat (qui est dans un module) commence par ouvrir l'état en mode
acDesign, pour lancer la procédure de traduction, puis le sauvegarde et
le ferme
- ensuite OuvreEtat ouvre frmPatienter et initialise les variables
globales qui servent pour la barre de progression, constituée de deux
traits (les traits, pour le déploiement, ça ne pose aucun problème) ;
ces variables sont Max et Pos
- OuvreEtat, pour finir, rouvre l'état, cette fois en mode acPreview
- dans l'état, en tête de groupe, un contrôle fait appel à une fonction
IdentiteIntervenant qui, d'après la clef du contact lue dans la requête
principale, va aller chercher l'identité dans la table de contacts, par
appel à une requête paramétrée ; IdentiteIntervenant en profite pour
incrémenter Pos dans frmPatienter
- par ailleurs une variable booléenne dans frmMenu indique que la barre
de progression doit être incrémentée.
Pour la mise à jour, j'ai essayé de déclencher le Repaint depuis trois
endroits :
- le Timer du frmPatienter
- une procédure Incremente dans frmPatienter, appelée depuis la fonction
IdentiteIntervenant
- la fonction IdentiteIntervenant elle-même, juste après l'incrémentation
Dans les trois cas, c'est un échec : la mise à jour de l'affichage ne se
fait que lorsque j'interromps le code. Ou alors je mets un MsgBox, tant
que l'utilisateur a le doigt pressé sur Entrée la progression
s'effectue, de temps en temps pour savoir où on en est on lâche la
touche. Bof.
J'ai bien essayé de bricoler avec SendMessage (WM_PAINT ; WM_PRINT
serait paraît-il plus adapté, en ayant le bon contexte de périphérique),
mais je n'y suis pas encore, et enfin bon, on est quand même sous Access ...
Je pourrais mettre une barre de progression dans la barre d'état
d'Access, c'est au moins quelque chose qui aurait l'intérêt de ne pas
être trop compliqué à faire je crois. Mais tant qu'à créer un formulaire
pour patienter, il me paraîtrait plus cohérent, du point de vue de la
présentation, que la barre de progression se trouve sur la fenêtre de ce
formulaire, surtout qu'il est en fenêtre indépendante.
Le fermer régulièrement pour le rouvrir ? Beurk, non ? Et pas forcément
plus rapide ...
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
Bonjour
"Gloops" a écrit dans le message de news: 43af76f0$0$18342$
J'ai un état à afficher avec un peu plus de 18000 enregistrements La lenteur dont tu parles suggère plutôt un problème de conception des requêtes à essayer de résoudre avant
de rajouter des rustines.
tu écris :
La requête principale s'ouvre assez vite, mais pour chaque enregistrement il y a une requête secondaire pour trouver l'identité du contact, et là pour exécuter tout ça ça prend quand même un paquet de minutes, bien assez pour se demander si la machine ne serait pas plantée.
Quel est le code de ta requête principale et quel est celui de la requête secondaire ?
Un contact peut-il avoir plusieurs identités ?? Si la réponse est non, alors une requête unique devrait être possible ....
-- A+ Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
Bonjour
"Gloops" <gloops@niark.fr> a écrit dans le message de news: 43af76f0$0$18342$8fcfb975@news.wanadoo.fr...
J'ai un état à afficher avec un peu plus de 18000 enregistrements
La lenteur dont tu parles suggère plutôt un problème de conception des requêtes à essayer de résoudre avant
de rajouter des rustines.
tu écris :
La requête principale s'ouvre assez vite, mais pour chaque enregistrement il y a une requête secondaire pour trouver l'identité du
contact, et là pour exécuter tout ça ça prend quand même un paquet de minutes, bien assez pour se demander si la machine ne serait
pas plantée.
Quel est le code de ta requête principale et quel est celui de la requête secondaire ?
Un contact peut-il avoir plusieurs identités ??
Si la réponse est non, alors une requête unique devrait être possible ....
--
A+
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"Gloops" a écrit dans le message de news: 43af76f0$0$18342$
J'ai un état à afficher avec un peu plus de 18000 enregistrements La lenteur dont tu parles suggère plutôt un problème de conception des requêtes à essayer de résoudre avant
de rajouter des rustines.
tu écris :
La requête principale s'ouvre assez vite, mais pour chaque enregistrement il y a une requête secondaire pour trouver l'identité du contact, et là pour exécuter tout ça ça prend quand même un paquet de minutes, bien assez pour se demander si la machine ne serait pas plantée.
Quel est le code de ta requête principale et quel est celui de la requête secondaire ?
Un contact peut-il avoir plusieurs identités ?? Si la réponse est non, alors une requête unique devrait être possible ....
-- A+ Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
Gloops
Bonsoir,
Apparemment il va me falloir un peu plus de temps que prévu pour regarder ça : je me rends compte que la requête principale fait appel à la fonction IdentiteIntervenant, et l'état va chercher le résultat dans les champs de la requête principale, donc ça me paraît encore plus bizarre, cette différence de délai entre l'affichage des résultats de la requête et celui de l'état.
Il faudra que je trouve un peu de temps là-dessus un matin ... ___________________________________ Anor a écrit, le 26/12/2005 09:53 :
Bonjour
"Gloops" a écrit dans le message de news: 43af76f0$0$18342$
J'ai un état à afficher avec un peu plus de 18000 enregistrements
La lenteur dont tu parles suggère plutôt un problème de conception des requêtes à essayer de résoudre avant de rajouter des rustines.
tu écris :
La requête principale s'ouvre assez vite, mais pour chaque enregistrement il y a une requête secondaire pour trouver l'identité du contact, et là pour exécuter tout ça ça prend quand même un paquet de minutes, bien assez pour se demander si la machine ne serait pas plantée.
Quel est le code de ta requête principale et quel est celui de la requête secondaire ?
Un contact peut-il avoir plusieurs identités ?? Si la réponse est non, alors une requête unique devrait être possible ....
Bonsoir,
Apparemment il va me falloir un peu plus de temps que prévu pour
regarder ça : je me rends compte que la requête principale fait appel à
la fonction IdentiteIntervenant, et l'état va chercher le résultat dans
les champs de la requête principale, donc ça me paraît encore plus
bizarre, cette différence de délai entre l'affichage des résultats de la
requête et celui de l'état.
Il faudra que je trouve un peu de temps là-dessus un matin ...
___________________________________
Anor a écrit, le 26/12/2005 09:53 :
Bonjour
"Gloops" <gloops@niark.fr> a écrit dans le message de news: 43af76f0$0$18342$8fcfb975@news.wanadoo.fr...
J'ai un état à afficher avec un peu plus de 18000 enregistrements
La lenteur dont tu parles suggère plutôt un problème de conception des requêtes à essayer de résoudre avant
de rajouter des rustines.
tu écris :
La requête principale s'ouvre assez vite, mais pour chaque enregistrement il y a une requête secondaire pour trouver l'identité du
contact, et là pour exécuter tout ça ça prend quand même un paquet de minutes, bien assez pour se demander si la machine ne serait
pas plantée.
Quel est le code de ta requête principale et quel est celui de la requête secondaire ?
Un contact peut-il avoir plusieurs identités ??
Si la réponse est non, alors une requête unique devrait être possible ....
Apparemment il va me falloir un peu plus de temps que prévu pour regarder ça : je me rends compte que la requête principale fait appel à la fonction IdentiteIntervenant, et l'état va chercher le résultat dans les champs de la requête principale, donc ça me paraît encore plus bizarre, cette différence de délai entre l'affichage des résultats de la requête et celui de l'état.
Il faudra que je trouve un peu de temps là-dessus un matin ... ___________________________________ Anor a écrit, le 26/12/2005 09:53 :
Bonjour
"Gloops" a écrit dans le message de news: 43af76f0$0$18342$
J'ai un état à afficher avec un peu plus de 18000 enregistrements
La lenteur dont tu parles suggère plutôt un problème de conception des requêtes à essayer de résoudre avant de rajouter des rustines.
tu écris :
La requête principale s'ouvre assez vite, mais pour chaque enregistrement il y a une requête secondaire pour trouver l'identité du contact, et là pour exécuter tout ça ça prend quand même un paquet de minutes, bien assez pour se demander si la machine ne serait pas plantée.
Quel est le code de ta requête principale et quel est celui de la requête secondaire ?
Un contact peut-il avoir plusieurs identités ?? Si la réponse est non, alors une requête unique devrait être possible ....