Application.ScreenUpdating : comment cela fonctionne ?

Je comprends parfaitement ta réponse, je me dis avec le recul que j’aurai probablement du regarder du coté d'Access...

D'ailleurs je compte regarder la cohabitation Excel avec Access en base de données. Mais là encore pour l'instant Access m'est totalement inconnu...

Mon application est sur les 8 PC des utilisateurs et marche de façon autonome sur chaque PC. Juste 3 classeurs sont "partagés" si on peut dire avec les limites d'Excel (contrôle et message d'erreur si le classeur est déjà ouvert)

Par ailleurs dans 90% des cas seuls 2 classeurs sont ouverts en même temps, ce qui limite les pb ...

Je vais donc me concentrer sur seulement 2 classeurs où les affichages sont assez gênant en suivant les conseils reçus.

Je reviendrai donner le résultat

Bonjour le file,

à une époque pas si lointaine j'avais mis en place à la demande de mon responsable un fichier maître qui récupérait des données sur des fichiers client(utilisateur) rangés dans un répertoire sur le réseau. Du coup j’avais le même problème quand au clignotement du à l'ouverture des fichiers.
Pour résoudre ce problème j'avais décidé d'ouvrir les fichiers dans une deuxième session d'excel Non graphique pilotée par mon fichier maître. Du coup plus de problème d'affichage ! c'est radicale et très efficace !

Quand à la discussion à propos de Application.ScreenUpdating = true ou pas, je suis complètement d'accord Pierre Fauconnier sauf dans la cas de gestion d'erreur qui oblige à une sortie direct qui ne passe pas par la fin de la procédure qui à débuté avec Application.ScreenUpdating = False. Dans ce cas si on ne gère pas on se retrouve surpris lors du retour sur le classeur.


A+

Bonjour Phil frre

Citation:

---

ouvrir les fichiers dans une deuxième session d'excel Non graphique pilotée par mon fichier maître

---

tu peux m'en dire un peu plus ou une piste d'une doc, je ne connais pas du tout cet aspect d'Excel

Salut Phil

Citation:

---

Envoyé par Phil Free

[...]
sauf dans la cas de gestion d'erreur qui oblige à une sortie direct qui ne passe pas par la fin de la procédure qui à débuté avec Application.ScreenUpdating = False. Dans ce cas si on ne gère pas on se retrouve surpris lors du retour sur le classeur.
A+

---

Justement, la gestion d'erreur, quand elle se place dans une bonne architecture, ne pose pas de problèmes de sortie directe. Encore une fois, tout est question d'architecture et la plupart des problèmes rencontrés proviennent d'une architecture non adaptée.

rebonjour Pierre

je suis prêt maintenant à revoir l'architecture de mon application pour régler pas mal de pb dont celui lié à cette discussion.

Je ne sais pas trop par quel bout commencer... Une doc (bonne) sur l'architecture me serait très utile

Voici une demo de pilotage d'une 2ieme session excel non graphique:

pour la demo je suppose que tu as un fichier nommé "Autrefichier.xlsx" dans un repertoire "c:\temp\"

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Sub demo() Dim ExcelAppli As Object, FichierDansAutreExcel As Workbook Dim MonFichier As String, Chemin As String   MonFichier = "Autrefichier.xlsx" 'le nom du fichier à ouvrir Chemin = "C:\temp\" 'le chemin du fichier à ouvrir Set ExcelAppli = CreateObject("Excel.Application") 'ici on creer la nouvelle session excel par défaut non graphique 'ExcelAppli.Visible = True 'on peu passer en mode graphique de cette façon DoEvents 'on donne la main au systeme pour qu'il ai les moyens d'ouvrir la deuxième session. Ok pas nécessaire mais préférable... de mon point de vu... With ExcelAppli Set FichierDansAutreExcel = .Workbooks.Open(Chemin & MonFichier) 'on ouvre le fichier End With With FichierDansAutreExcel .Worksheets("feuil1").Range("a1").Value = "test ok !" 'on ecrit un truc dans une cellule pour la demo .Close SaveChanges:=True 'on ferme et on suavegarde en même temps End With ' pour la demo je fais une operation simple sur un seul fichier mais à la place de ce commentaire tu peux faire tous ce qui est possible de faire sur et avec un ou plusieurs fichier(s) excel . ExcelAppli.Quit 'on ferme l'autre session d'excel 'on vide les variable object Set FichierDansAutreExcel = Nothing Set ExcelAppli = Nothing End Sub

---

Citation:

---

Envoyé par Pierre Fauconnier

Justement, la gestion d'erreur, quand elle se place dans une bonne architecture, ne pose pas de problèmes de sortie directe. Encore une fois, tout est question d'architecture et la plupart des problèmes rencontrés proviennent d'une architecture non adaptée.

---

oui je suis d'accord mais dans la pratique du forum il est en générale préférable de conseiller d'ajouter cette ligne car les débutants voir même de plus confirmé aurons un jour, comme cela mes arrivé, la mauvaise surprise d'avoir un affichage qui ne se met plus à jour. Enfin ce n'est que mon point de vu car je n'ai pas la prétention de maîtriser ce qu'est une bonne architecture même si je me soigne ;)

Citation:

---

Envoyé par Phil Free

[...]dans la pratique du forum il est en générale préférable de conseiller d'ajouter cette ligne[...]

---

Je ne sais pas de quelle ligne tu parles, mais si tu parles de ScreenUpdating = True, je ne conseillerai jamais d'ajouter une ligne inutile, et je suis rarement les "dans la pratique du forum il est en général préférable de...".

Indépendamment de ce que peuvent en penser les uns et les autres, je conseille ce que je considère comme le meilleur et je me fous des pratiques du forum comme un poisson d'une pomme ;). Je dis ce que je dis parce que ma longue expérience me dit de le dire... :aie: Et je pense que plus tôt on acquiert les bonnes pratiques de code (architecture, boucles en fonction de ce qu'on peut faire - un for next ne se remplace pas par un do while, pas de exit, une bonne gestion d'erreurs, ...), plus on s'évite des erreurs et des heures de galère à tenter de déboguer un code merdique sur une architecture merdique.

Il faut appliquer les bonnes méthodes non pas parce que je le dis, mais parce qu'elles sont bonnes, qu'elles ont été validées par des générations de programmeurs, qu'elles ont fait leurs preuves et qu'elles sont garantes d'un code stable, pérenne, évolutif et maintenable.

Je ne vais pas m'attirer des sympathies en disant cela, mais ça fait longtemps que je ne suis plus ici pour cela ;)

Si javais ton expérience je dirai la même chose...

Je ne l'ai pas mais je pense la même chose...

J'applique dans les limites de mes connaissances...