Problème d'automation sur excel 2010

Bonjour à tous,

Dans un module général j'ai cette procédure que j'appelle par Call depuis le code dans des userform en renseignant le nom de la feuille concernée.

Code:

---

1 2 3 4 5 6 7 8 9 10

Public Sub affiche(nom) Application.ScreenUpdating = False With ThisWorkbook.Sheets(nom) If .Visible <> xlSheetVisible Then .Visible = xlSheetVisible .Activate .Range("A1").Select End With Application.ScreenUpdating = True End Sub

---

Cette procédure fonctionne parfaitement sur excel 2013 sur tous les PC mais sur 2010 elle produit très souvent une erreur d'automation qui plante excel irrémédiablement.
"Un objet s'est déconnecté" est parfois affiché : je ne vois pas ce qui cloche.
Microsoft signale sur 2003 qu'il faut libérer les objets mais je ne vois pas ce que je peux libérer.

Merci d'avance à ceux qui sauront m'expliquer le souci.

Bonjour
Ton erreur d'automation est ailleurs (aucune automation dans le code que tu montres).
Au passage :

Code:

---

If .Visible <> xlSheetVisible Then .Visible = xlSheetVisible

---

n'est jamais rien d'autre que :

Code:

---

.visible = True

---

Bonjour,

sur quelle ligne exactement se produit l'erreur ?
il est opportun de typer ton paramètre "nom" (nom As String) et d'être sûr que c'est bien un string que tu envoies (et non un objet feuille)
si tu ne travailles que sur des feuilles de calcul avec cette procédure (pas de feuille graphique), privilégie l'objet Worksheets plutôt que l'objet Sheets

est-ce que les modules des feuilles concernées par cette procédure possèdent du code ? Si oui, il faut les montrer

peut-on voir l'un de tes modules Userform, histoire de comprendre comment tu appelles ta procédure, et les traitement pré/post appel de cette procédure publique ?

Bonjour,

Tu ne fermerais pas ton UF tout de suite après cet appel des fois ?
Peut-être qu'excel 2010 (ou son PC) plus rapide arrive à le fermer avant d'avoir fini cette proc.
Si c'est le cas essayer d'ajouter une petite tempo avant cette fermeture.
eric

Bonsoir à tous et merci de vous être penché sur mon problème.

Citation:

---

Envoyé par unparia

Au passage : If .Visible <> xlSheetVisible Then .Visible = xlSheetVisible n'est jamais rien d'autre que : .visible = True

---

Ok c'est d'accord mais j'ai utilisé ce test car à l'open je masque les 40 feuilles et avec le test si les feuilles ont été sauvées masquées c'est nettement plus rapide.
Ce n'est pas une faute d'utiliser la bonne variable VBA ?

Citation:

---

Envoyé par unparia

Ton erreur d'automation est ailleurs (aucune automation dans le code que tu montres).

---

Citation:

---

Envoyé par joe.levrai

sur quelle ligne exactement se produit l'erreur ?

---

Et pourtant l'erreur se produit bien là. En principe le debug n'affiche aucune ligne car excel est planté mais en déroulant en pas à pas c'est .activate qui plante.

Citation:

---

Envoyé par joe.levrai

il est opportun de typer ton paramètre "nom" (nom As String) et d'être sûr que c'est bien un string que tu envoies (et non un objet feuille)
si tu ne travailles que sur des feuilles de calcul avec cette procédure (pas de feuille graphique), privilégie l'objet Worksheets plutôt que l'objet Sheets

---

C'est parfaitement vrai effectivement et j'ai corrigé mais sans résultat

Code:

---

1 2 3 4 5 6 7 8 9 10

Public Sub affiche(nom As String) Application.ScreenUpdating = False With ThisWorkbook.Worksheets(nom) If .Visible <> xlSheetVisible Then .Visible = xlSheetVisible Application.Wait Now + TimeValue("0:00:02") .Activate .Range("A1").Select End With Application.ScreenUpdating = True End Sub

---

Citation:

---

Envoyé par joe.levrai

est-ce que les modules des feuilles concernées par cette procédure possèdent du code ?
peut-on voir l'un de tes modules Userform, histoire de comprendre comment tu appelles ta procédure,
et les traitementde cette procédure publique ?

---

Il y a dans l'open le masquage sus-mentionné, puis un seul module pour lancer les formulaires, et masquer ou afficher les onglets feuilles, aucun code dans les feuilles et les formulaires sont assez simples en permettant la saisie des données.
L'appel est basique et aucun traitement "pré/post appel" : le seul but est d'avoir la feuille concernée sous les yeux.

Code:

---

1 2 3

Private Sub btndonées_Click() Call affiche("Ma base de données") End Sub

---

Citation:

---

Envoyé par eriiic

Tu ne fermerais pas ton UF tout de suite après cet appel des fois ?
Peut-être qu'excel 2010 (ou son PC) plus rapide arrive à le fermer avant d'avoir fini cette proc.
Si c'est le cas essayer d'ajouter une petite tempo avant cette fermeture.

---

Bien vu mais pas de fermeture comme dit ci-dessus. Les PC testés ont 2010 et 2013 et tout fonctionne sur 2013 et plante sur 2010.
J'ai testé ta tempo comme tu peux le voir avant l'instruction de plantage mais c'est de même.

J'ai aussi essayé de mettre directement la procédure dans le clic du bouton mais le résultat est identique.

La feuille est bien visible lorsque l'activate plante : c'est un mystère pour moi et j'espère que vous serez plus inspirés.

Bonjour,

Prise au pied de la lettre, ton message d'erreur dit que la connection OLE s'est rompue à quelque part en chemin.

Ceci dit, ce n'est pas le "bon" message pour ce qui va suivre, mais cela arrive des fois que le "mauvais" message d'erreur sorte au mauvais moment. De toutes façons le pire qui peut arriver c'est que ce ne soit pas cela:

as-tu jeté un œil dans outils-références sur le "malade" pour vérifier s'il n'y a pas des références manquantes ou en conflit ?

Ou bien, y a-t-il un Excel à 32 bits qui essaie de mâter un Excel à 64 bits, ou l'inverse ?

La tempo je la voyais dans l'autre procédure, celle qui ferme l'UF pour la retarder. Mais si tu dis qu'il ne se ferme pas dans la foulée...

Code:

---

Public Sub affiche(nom)

---

Pourquoi Public ?
Si c'est parce qu'elle est dans un module de classe (Feuil ou autre) tu peux tester en la mettant dans un module Standard ?

Lors de l'erreur examine Err dans la fenêtre espion des fois que tu aies plus de précisions, il y a beaucoup de codes erreur Automation (+ de 300)

Bonjour à tous,

Citation:

---

Envoyé par clementmarcotte

as-tu jeté un œil dans outils-références sur le "malade" pour vérifier s'il n'y a pas des références manquantes ou en conflit ?

Ou bien, y a-t-il un Excel à 32 bits qui essaie de mâter un Excel à 64 bits, ou l'inverse ?

---

Les références sont identiques sur les versions 2010 et les 2013 qui, je le rappelle fonctionnent parfaitement.
Pièce jointe 219057

Citation:

---

Envoyé par eriiic

Pourquoi Public ?
Si c'est parce qu'elle est dans un module de classe (Feuil ou autre) tu peux tester en la mettant dans un module Standard ?

---

Cela ne change rien et c'est normal car cela plante aussi quand je mets le code, comme signalé au-dessus dans le clic du bouton.

Citation:

---

Envoyé par eriiic

Lors de l'erreur examine Err dans la fenêtre espion des fois que tu aies plus de précisions, il y a beaucoup de codes erreur Automation (+ de 300)

---

Là, je voudrais bien mais c'est totalement impossible car excel n'est plus là il est parti pour se récupérer.

Bonjour,

à la rigueur, en remplaçant le .Activate par un .Select, ça va pas mieux ?

Bonjour

Questions :
1) as-tu un seul classeur ou plusieurs classeurs ouverts par ton appli ?
2) si plusieurs classeurs :
-- a) dans quel classeur se trouve le UserForm qui appelle cette procédure ?
-- b) dans quelle classeur se trouve la feuille que tu veux activer ? (celle que tu passes à ta procédure) ?
3) question subsidiaire (sans rapport vraiment direct avec le problème) : dans quel but actives-tu cette feuille et y sélectionnes-tu la cellule A1 ?

EDIT : ah oui : et dans quel classeur se trouve le module qui contient ta procédure ?

Bonjour

Citation:

---

Envoyé par joe.levrai

à la rigueur, en remplaçant le .Activate par un .Select, ça va pas mieux ?

---

Même avec select, la punition est la même : 2010 ne sait pas changer de feuille.

Citation:

---

Envoyé par unparia

1) as-tu un seul classeur ou plusieurs classeurs ouverts par ton appli ?
2) si plusieurs classeurs :
-- a) dans quel classeur se trouve le UserForm qui appelle cette procédure ?
-- b) dans quelle classeur se trouve la feuille que tu veux activer ? (celle que tu passes à ta procédure) ?
3) question subsidiaire (sans rapport vraiment direct avec le problème) : dans quel but actives-tu cette feuille et y sélectionnes-tu la cellule A1 ?
EDIT : ah oui : et dans quel classeur se trouve le module qui contient ta procédure ?

---

1) un seul classeur
2) pas concerné et j'ai précisé ci-dessus le contenu du classeur

Citation:

---

Envoyé par anasecu

Il y a dans l'open le masquage sus-mentionné, puis un seul module pour lancer les formulaires, et masquer ou afficher les onglets feuilles, aucun code dans les feuilles et les formulaires sont assez simples en permettant la saisie des données.

---

3)comme précisé

Citation:

---

Envoyé par anasecu

le seul but est d'avoir la feuille concernée sous les yeux.

---

Citation:

---

Envoyé par anasecu

Bonjour à tous,

Les références sont identiques sur les versions 2010 et les 2013

---

Faux

2013 utilise la version 15 des objets d'Office et 2010 utilise la version 14 des objets d'Office. Commence par vérifier si dans ton Office 2013, tu n'as pas utilisé quelque chose qui n'est pas disponible sur 2010. Dans l'aide de VBA, tu as une rubrique qui traite des modifications apportées au modèle-objet d'Excel

Tu dis aussi :

Citation:

---

Cette procédure fonctionne parfaitement sur excel 2013 sur tous les PC mais sur 2010 elle produit très souvent une erreur d'automation qui plante excel irrémédiablement.

---

Est-ce que c'est toujours sur le(s) même(s) 2010 ?

Ma question sur les versions 32 bits ou 64 bits, à laquelle tu n'as pas daigné répondre, n'était pas la pour faire intelligent ou pour le plaisir. Depuis Office 2010, Office est disponible en version 32 bits et en version 64 bits. Et la compatibilité entre les versions 32 bits et 64 bits n'est pas complète.

Donc, si tes Office 2013 sont tous à 64 bits et que tes Office 2010 sont en partie à 32 bits et en partie à 64 bits, c'est extrêmement possible que ton programme tourne sans problème sur un Office 2010 à 64 bits et plante sur un Office 2010 à 32 bits.

Le corollaire est aussi vrai. Si tous tes Office 2013 sont à 32 bits et que tes Office 2010 sont en partie à 32 bits et en partie à 64 bits, c'est extrêmement possible que ton programme tourne sans problème sur un Office 2010 à 32 bits et plante sur un Office 2010 à 64 bits.

Et puis, en prime, voici la solution que je vois pour les parcs hétéroclites d'Office à 32 bits et d'Office à 64 bits et que personne ici ne voudra appliquer. Attention, cela va faire ouille. Devant des parcs hétéroclites d'Office, il faut oublier VBA et faire le pas qui fait peur, passer à VB.net (ou à C#, out tout autre langage .net, cela revient au même avec un code et un langage différents).

Je sens venir la question pourquoi, que certains se posent pour mieux la réfuter ;) . C'est tout simplement que l'automation à la sauce .net (ce n'est pas de la vraie automation au sens strict du mot) n'a rien à cirer que l'Office soit à 32 ou à 64 bits, ni même que ce soit Office 2003 (peut-être même 2002), Office 2007, Office 2010, Office 2013 ou Office 2016; pour autant que vous vous limitiez à ce qui reste commun aux versions qui vous concernent. C'est tout simplement parce .net n'accède pas directement aux objets COM (OLE) comme Office, mais passe par un intermédiaire (un wrapper, dans le jargon .net). Quand vous n'avez pas le wrapper sous la main, VB vous en crée un au moment opportun, et c'est transparent. Dans le cas de Office, Microsoft fournit gratuitement les Primary Interop Assemblies, et c'est toujours la dernière version disponible sur votre machine qui est utilisée.

Bonjour clementmarcotte,

Citation:

---

Envoyé par clementmarcotte

Faux 2013 utilise la version 15 des objets d'Office et 2010 utilise la version 14 des objets d'Office.

---

Effectivement, mais cela me parait normal que chaque version utilise la sienne.J'ai l'impression d'ailleurs que chacune inclus les versions précédentes mais c'est peut-être une erreur de ma part.

Citation:

---

Envoyé par clementmarcotte

Est-ce que c'est toujours sur le(s) même(s) 2010 ?

---

Je viens d'essayer sur un nouveau PC 2010 avec seulement 2010 32 bits qui plante aussi dès qu'on lance cette procédure. Je précise que la procédure peut aussi être lancée pour d'autres feuille sans que le formulaire soit ouvert et dans ce cas elle fonctionne.

Citation:

---

Envoyé par clementmarcotte

Ma question sur les versions 32 bits ou 64 bits, à laquelle tu n'as pas daigné répondre,

---

Désolé ! Effectivement il y avait beaucoup de questions et j'ai zappé celle-là : tous les Offices que j'ai utilisé sont en 32 bits car en ayant plusieurs versions, je n'ai pas voulu mélanger.

Je vais essayer de préparer un exemple pour vous permettre de tester.

Bonjour, bonjour !

La mini usine à gaz postée initialement peut être remplacée par deux lignes de code : une pour afficher la feuille,
l'autre se positionnant directement sur la cellule de la feuille via la méthode Application.Goto !
(Et à ne pas confondre avec l'instruction Goto …)

Voilà, voilà !

_________________________________________________________________________________________________________

Je suis Paris, Nice, Bruxelles, Charlie, …

Bonjour à tous,

Citation:

---

Envoyé par Marc-L

La mini usine à gaz postée initialement peut être remplacée par deux lignes de code : une pour afficher la feuille,
l'autre se positionnant directement sur la cellule de la feuille via la méthode Application.Goto

---

Merci pour l'appréciation agréable et j'attends le code précis en 2 instructions pour se positionner sur une cellule en feuille masquée.

Voilà l'exemple pour vous permettre de tester. La procédure initiale a été supprimée mais se retrouve en fin de procédure "Ouvrir" utilisée pour toutes les feuilles.
Ce classeur fonctionne parfaitement sous 2013 et plante excel 2010 lorsque l'on lance un formulaire avec les objets "F x" puis le bouton "Aller à BD" alors que les affichages des autres feuilles fonctionne avec les autres objets cliquables même "Bd I" "BdH" "BdC" qui font le même traitement.

Citation:

---

Envoyé par anasecu

j'attends le code précis en 2 instructions pour se positionner sur une cellule en feuille masquée.

---

Bien relire mon précédent message alors ‼

Comme pourtant écrit noir sur blanc en deux lignes de code :
la première rendant visible la feuille (l'instruction étant déjà présente dans le code initial !) et
la seconde via Application.Goto comme indiqué dans l'aide VBA interne, suffit de la consulter … :roll:
Sans compter les exemples dans les discussions de ce forum !

En supposant les directives Microsoft ayant bien été suivies (màj, suppression des fichiers temporaires de Windows & de la session, etc …)
autre voie : avec une version 2010, supprimer l'UserForm (ou pour les moins courageux juste les objets posant problème) puis recréer …
Si cela fonctionne sur toutes les versions 2010, tester ensuite sur les versions 2013.

Bonsoir à tous,

Citation:

---

Envoyé par Marc-L

autre voie : avec une version 2010, supprimer l'UserForm (ou pour les moins courageux juste les objets posant problème) puis recréer …

---

J'ai supprimé les UserForm j'en ai créé un nouveau avec le seul bouton qui pose problème (visualiser une feuille masquée) et le résultat est le même : erreur automation et excel se ferme.

Je rappelle que j'essaie sur plusieurs PC et seul excel 2010 plante, 2003, 2007 et 2013 fonctionnent tout à fait correctement.

Bonjour à tous,

J'ai remplacé activate par la "méthode Application.Goto" mais cela ne fonctionne toujours pas sur 2010.

Comme c'est la seule version qui plante je me demandes si cela n'est pas un bug provoqué par une mise à jour d'Office 2010 ?