J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel
d'une fonction API de Windows qui fonctionne avec une fonction de retour
("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la
fonction callback EnhMetaFileProc.
L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la
fonction EnhMetaFileProc par Windows.
Le problème est le suivant :
Le projet VBA, qui était dans Word, fonctionnait très bien.
Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps
d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.
Quelqu'un aurait-il une information sur la lenteur des fonctions API
callback dans Access?
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
A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access... Ta base access est située sur un disque local ? a+
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"LiR" a écrit dans le message de news:
Bonjour à tous,
J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel d'une fonction API de Windows qui fonctionne avec une fonction de retour ("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la fonction callback EnhMetaFileProc.
L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la fonction EnhMetaFileProc par Windows.
Le problème est le suivant : Le projet VBA, qui était dans Word, fonctionnait très bien. Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.
Quelqu'un aurait-il une information sur la lenteur des fonctions API callback dans Access?
Un grand merci pour votre aide.
Bonjour
A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access...
Ta base access est située sur un disque local ?
a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"LiR" <LiR@discussions.microsoft.com> a écrit dans le message de news: DD8AEC6C-2A6D-4CEB-80D4-3801B64431F0@microsoft.com...
Bonjour à tous,
J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel
d'une fonction API de Windows qui fonctionne avec une fonction de retour
("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la
fonction callback EnhMetaFileProc.
L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la
fonction EnhMetaFileProc par Windows.
Le problème est le suivant :
Le projet VBA, qui était dans Word, fonctionnait très bien.
Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps
d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.
Quelqu'un aurait-il une information sur la lenteur des fonctions API
callback dans Access?
A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access... Ta base access est située sur un disque local ? a+
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"LiR" a écrit dans le message de news:
Bonjour à tous,
J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel d'une fonction API de Windows qui fonctionne avec une fonction de retour ("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la fonction callback EnhMetaFileProc.
L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la fonction EnhMetaFileProc par Windows.
Le problème est le suivant : Le projet VBA, qui était dans Word, fonctionnait très bien. Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.
Quelqu'un aurait-il une information sur la lenteur des fonctions API callback dans Access?
Un grand merci pour votre aide.
LiR
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère près. Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback, il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
Bonjour
A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access... Ta base access est située sur un disque local ? a+
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"LiR" a écrit dans le message de news:
Bonjour à tous,
J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel d'une fonction API de Windows qui fonctionne avec une fonction de retour ("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la fonction callback EnhMetaFileProc.
L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la fonction EnhMetaFileProc par Windows.
Le problème est le suivant : Le projet VBA, qui était dans Word, fonctionnait très bien. Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.
Quelqu'un aurait-il une information sur la lenteur des fonctions API callback dans Access?
Un grand merci pour votre aide.
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère
près.
Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback,
il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans
Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
Bonjour
A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access...
Ta base access est située sur un disque local ?
a+
--
Arnaud
---------------------------------------------
infos, conseils et liens : http://www.mpfa.info
---------------------------------------------
"LiR" <LiR@discussions.microsoft.com> a écrit dans le message de news: DD8AEC6C-2A6D-4CEB-80D4-3801B64431F0@microsoft.com...
Bonjour à tous,
J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel
d'une fonction API de Windows qui fonctionne avec une fonction de retour
("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la
fonction callback EnhMetaFileProc.
L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la
fonction EnhMetaFileProc par Windows.
Le problème est le suivant :
Le projet VBA, qui était dans Word, fonctionnait très bien.
Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps
d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.
Quelqu'un aurait-il une information sur la lenteur des fonctions API
callback dans Access?
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère près. Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback, il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
Bonjour
A priori, il n'y a pas de raison que les performances soient bonnes dans word et mauvaises dans access... Ta base access est située sur un disque local ? a+
-- Arnaud --------------------------------------------- infos, conseils et liens : http://www.mpfa.info ---------------------------------------------
"LiR" a écrit dans le message de news:
Bonjour à tous,
J'ai un projet VBA de traitement de fichiers EMF ; ce projet utilise l'appel d'une fonction API de Windows qui fonctionne avec une fonction de retour ("Callback"), la fonction appelée étant en l'occurence EnumEnhMetaFile et la fonction callback EnhMetaFileProc.
L'appel de la fonction EnhMetaFileProc entraîne une suite d'appels de la fonction EnhMetaFileProc par Windows.
Le problème est le suivant : Le projet VBA, qui était dans Word, fonctionnait très bien. Puis, depuis que j'ai recopié intégralement ce projet dans Access, le temps d'exécution de l'appel de la fonction est 10 fois plus long qu'avant.
Quelqu'un aurait-il une information sur la lenteur des fonctions API callback dans Access?
Un grand merci pour votre aide.
Salut
eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))
trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate que le code se déroule trop vite pour rendre le résultat attendu.
Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)
a+ Arnaud
"LiR" a écrit dans le message de news:
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère près. Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback, il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
Salut
eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))
trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate
que le code se déroule trop vite pour rendre le résultat attendu.
Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access
et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)
a+
Arnaud
"LiR" <LiR@discussions.microsoft.com> a écrit dans le message de news: 999825E7-4CC0-4E56-8D6B-709AB20E85D1@microsoft.com...
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère
près.
Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback,
il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans
Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))
trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate que le code se déroule trop vite pour rendre le résultat attendu.
Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)
a+ Arnaud
"LiR" a écrit dans le message de news:
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère près. Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback, il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
LiR
En fait, comme je l'ai dit : Les 2 projets VBA sont identiques au caractère près : le doEvents était dans Word et fonctionnait très bien (il ne ralentissait pas l'exécution).
En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)...
C'est quand même étrange que cette instruction ait des répercussions si différentes dans Access et dans Word...
Salut
eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))
trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate que le code se déroule trop vite pour rendre le résultat attendu.
Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)
a+ Arnaud
"LiR" a écrit dans le message de news:
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère près. Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback, il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
En fait, comme je l'ai dit :
Les 2 projets VBA sont identiques au caractère près : le doEvents était dans
Word et fonctionnait très bien (il ne ralentissait pas l'exécution).
En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne
pas voir son écran se figer et aussi de prendre la main pour appuyer sur un
bouton "Annuler" afin de mettre fin à l'opération (malheureusement le
multithread n'existe pas en VBA)...
C'est quand même étrange que cette instruction ait des répercussions si
différentes dans Access et dans Word...
Salut
eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))
trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate
que le code se déroule trop vite pour rendre le résultat attendu.
Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access
et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)
a+
Arnaud
"LiR" <LiR@discussions.microsoft.com> a écrit dans le message de news: 999825E7-4CC0-4E56-8D6B-709AB20E85D1@microsoft.com...
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère
près.
Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback,
il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans
Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
En fait, comme je l'ai dit : Les 2 projets VBA sont identiques au caractère près : le doEvents était dans Word et fonctionnait très bien (il ne ralentissait pas l'exécution).
En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)...
C'est quand même étrange que cette instruction ait des répercussions si différentes dans Access et dans Word...
Salut
eh bien je dirais que le DoEvents marche bien dans Access et qu'il n'a aucun effet dans Word ? ;-))
trève de plaisanterie, lesdoevents permettent d'attendre la fin des processus en cours mais on ne les utilise que lorsqu'on constate que le code se déroule trop vite pour rendre le résultat attendu.
Il faudrait donc vérifier que DoEvents dans word => perfs identiques à Access et si tu les retire, s'assurer que tu ne crées pas une régression plus loin (code qui ne fonctionne plus correctement...)
a+ Arnaud
"LiR" a écrit dans le message de news:
Merci Anor de te pencher sur mon problème,
Les 2 codes VBA (Word et Access) sont rigoureusement identiques au caractère près. Ils sont exécutés sur la même machine en local.
Je vien en revanche de faire un test très utile : dans ma fonction callback, il y avait une instruction DoEvents.
Je l'ai retirée et les performances sont alors identiques dans Word et dans Access.
La question serait donc :
Quid des performances dans Microsoft Access lors de l'utilisation de DoEvents?
3stone
Salut,
"LiR" | En fait, comme je l'ai dit : | Les 2 projets VBA sont identiques au caractère près : le doEvents était dans | Word et fonctionnait très bien (il ne ralentissait pas l'exécution). | | En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne | pas voir son écran se figer et aussi de prendre la main pour appuyer sur un | bouton "Annuler" afin de mettre fin à l'opération (malheureusement le | multithread n'existe pas en VBA)... | | C'est quand même étrange que cette instruction ait des répercussions si | différentes dans Access et dans Word...
Pas tant que ca...
Access n'est pas Word. Et Access à la particularité de se réservé tout le temps processeur et de ne lacher que ce que Windows demande.
Et, sur Access en tout cas il "consomme" beaucoup de temps. Un simple test avec une boucle comprenant ou non un DoEvents montre une différence de temps d'exécution très importante.
L'utilité d'un DoEvents n'a pas seulement, comme tu dis :
"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"
Cela va beaucoup plus loin ! Le DoEvents rend explicitement la main au système, qui sans cela est incapable de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)
Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine vba monopolisant toutes les ressources.
"LiR"
| En fait, comme je l'ai dit :
| Les 2 projets VBA sont identiques au caractère près : le doEvents était dans
| Word et fonctionnait très bien (il ne ralentissait pas l'exécution).
|
| En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne
| pas voir son écran se figer et aussi de prendre la main pour appuyer sur un
| bouton "Annuler" afin de mettre fin à l'opération (malheureusement le
| multithread n'existe pas en VBA)...
|
| C'est quand même étrange que cette instruction ait des répercussions si
| différentes dans Access et dans Word...
Pas tant que ca...
Access n'est pas Word. Et Access à la particularité de se réservé tout le
temps processeur et de ne lacher que ce que Windows demande.
Et, sur Access en tout cas il "consomme" beaucoup de temps.
Un simple test avec une boucle comprenant ou non un DoEvents montre
une différence de temps d'exécution très importante.
L'utilité d'un DoEvents n'a pas seulement, comme tu dis :
"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer
et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de
mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"
Cela va beaucoup plus loin !
Le DoEvents rend explicitement la main au système, qui sans cela est incapable
de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)
Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement
parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine
vba monopolisant toutes les ressources.
"LiR" | En fait, comme je l'ai dit : | Les 2 projets VBA sont identiques au caractère près : le doEvents était dans | Word et fonctionnait très bien (il ne ralentissait pas l'exécution). | | En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne | pas voir son écran se figer et aussi de prendre la main pour appuyer sur un | bouton "Annuler" afin de mettre fin à l'opération (malheureusement le | multithread n'existe pas en VBA)... | | C'est quand même étrange que cette instruction ait des répercussions si | différentes dans Access et dans Word...
Pas tant que ca...
Access n'est pas Word. Et Access à la particularité de se réservé tout le temps processeur et de ne lacher que ce que Windows demande.
Et, sur Access en tout cas il "consomme" beaucoup de temps. Un simple test avec une boucle comprenant ou non un DoEvents montre une différence de temps d'exécution très importante.
L'utilité d'un DoEvents n'a pas seulement, comme tu dis :
"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"
Cela va beaucoup plus loin ! Le DoEvents rend explicitement la main au système, qui sans cela est incapable de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)
Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine vba monopolisant toutes les ressources.
Cela confirme bien ce que je pensais et c'est exactement la conclusion que j'en avais tiré, au détail près qu'en l'occurence DoEvents rend la main à Access (et non au "système" à qui, en outre, je l'ai donnée!).
Il y a cependant en pratique une diffférence entre un DoEvents localisé pour permettre à un thread de terminer sa tâche (mode asynchrone a priori) et une répétition de DoEvents pour "faire respirer" le système.
Je trouve juste étrange que passer la main au système revienne ici à parmettre à Access de détruire les performances pour rien!
En conclusion, je le sais désormais et j'en tiendrai compte pour la suite.
Un grand merci à vous deux pour vous être penchés sur mon problème.
Salut,
"LiR" | En fait, comme je l'ai dit : | Les 2 projets VBA sont identiques au caractère près : le doEvents était dans | Word et fonctionnait très bien (il ne ralentissait pas l'exécution). | | En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne | pas voir son écran se figer et aussi de prendre la main pour appuyer sur un | bouton "Annuler" afin de mettre fin à l'opération (malheureusement le | multithread n'existe pas en VBA)... | | C'est quand même étrange que cette instruction ait des répercussions si | différentes dans Access et dans Word...
Pas tant que ca...
Access n'est pas Word. Et Access à la particularité de se réservé tout le temps processeur et de ne lacher que ce que Windows demande.
Et, sur Access en tout cas il "consomme" beaucoup de temps. Un simple test avec une boucle comprenant ou non un DoEvents montre une différence de temps d'exécution très importante.
L'utilité d'un DoEvents n'a pas seulement, comme tu dis :
"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"
Cela va beaucoup plus loin ! Le DoEvents rend explicitement la main au système, qui sans cela est incapable de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)
Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine vba monopolisant toutes les ressources.
Cela confirme bien ce que je pensais et c'est exactement la conclusion que
j'en avais tiré, au détail près qu'en l'occurence DoEvents rend la main à
Access (et non au "système" à qui, en outre, je l'ai donnée!).
Il y a cependant en pratique une diffférence entre un DoEvents localisé pour
permettre à un thread de terminer sa tâche (mode asynchrone a priori) et une
répétition de DoEvents pour "faire respirer" le système.
Je trouve juste étrange que passer la main au système revienne ici à
parmettre à Access de détruire les performances pour rien!
En conclusion, je le sais désormais et j'en tiendrai compte pour la suite.
Un grand merci à vous deux pour vous être penchés sur mon problème.
Salut,
"LiR"
| En fait, comme je l'ai dit :
| Les 2 projets VBA sont identiques au caractère près : le doEvents était dans
| Word et fonctionnait très bien (il ne ralentissait pas l'exécution).
|
| En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne
| pas voir son écran se figer et aussi de prendre la main pour appuyer sur un
| bouton "Annuler" afin de mettre fin à l'opération (malheureusement le
| multithread n'existe pas en VBA)...
|
| C'est quand même étrange que cette instruction ait des répercussions si
| différentes dans Access et dans Word...
Pas tant que ca...
Access n'est pas Word. Et Access à la particularité de se réservé tout le
temps processeur et de ne lacher que ce que Windows demande.
Et, sur Access en tout cas il "consomme" beaucoup de temps.
Un simple test avec une boucle comprenant ou non un DoEvents montre
une différence de temps d'exécution très importante.
L'utilité d'un DoEvents n'a pas seulement, comme tu dis :
"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer
et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de
mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"
Cela va beaucoup plus loin !
Le DoEvents rend explicitement la main au système, qui sans cela est incapable
de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)
Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement
parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine
vba monopolisant toutes les ressources.
Cela confirme bien ce que je pensais et c'est exactement la conclusion que j'en avais tiré, au détail près qu'en l'occurence DoEvents rend la main à Access (et non au "système" à qui, en outre, je l'ai donnée!).
Il y a cependant en pratique une diffférence entre un DoEvents localisé pour permettre à un thread de terminer sa tâche (mode asynchrone a priori) et une répétition de DoEvents pour "faire respirer" le système.
Je trouve juste étrange que passer la main au système revienne ici à parmettre à Access de détruire les performances pour rien!
En conclusion, je le sais désormais et j'en tiendrai compte pour la suite.
Un grand merci à vous deux pour vous être penchés sur mon problème.
Salut,
"LiR" | En fait, comme je l'ai dit : | Les 2 projets VBA sont identiques au caractère près : le doEvents était dans | Word et fonctionnait très bien (il ne ralentissait pas l'exécution). | | En fait le DoEvents a pour seule utilité de permettre à l'utilisateur de ne | pas voir son écran se figer et aussi de prendre la main pour appuyer sur un | bouton "Annuler" afin de mettre fin à l'opération (malheureusement le | multithread n'existe pas en VBA)... | | C'est quand même étrange que cette instruction ait des répercussions si | différentes dans Access et dans Word...
Pas tant que ca...
Access n'est pas Word. Et Access à la particularité de se réservé tout le temps processeur et de ne lacher que ce que Windows demande.
Et, sur Access en tout cas il "consomme" beaucoup de temps. Un simple test avec une boucle comprenant ou non un DoEvents montre une différence de temps d'exécution très importante.
L'utilité d'un DoEvents n'a pas seulement, comme tu dis :
"pour seule utilité de permettre à l'utilisateur de ne pas voir son écran se figer et aussi de prendre la main pour appuyer sur un bouton "Annuler" afin de mettre fin à l'opération (malheureusement le multithread n'existe pas en VBA)"
Cela va beaucoup plus loin ! Le DoEvents rend explicitement la main au système, qui sans cela est incapable de la reprendre. On laisse donc au "programmeur" le soin de l'inserer en cas de besoin ;-)
Il arrive que l'interrogation d'un textbox pourtant alimenté soit NULL, simplement parce que le thread qui s'occupe de l'alimenter n'arrive pas a avoir la main, la routine vba monopolisant toutes les ressources.