begin process at 2010 02 10 09:27:46
  Trouver un code source :
 
dans
 
[ Dernières recherches ]
Accueil > 

Code

 > 

Divers

 > REGLER LE PROBLEME ENTRE VB ET EXCEL

REGLER LE PROBLEME ENTRE VB ET EXCEL


 Information sur la source

Note :
10 / 10 - par 1 personne
10,00 / 10

  • 1

  • 2

  • 3

  • 4

  • 5

  • 6

  • 7

  • 8

  • 9

  • 10
Catégorie :Divers Niveau :Débutant Date de création :10/08/2004 Vu :4 652
Auteur : le_chacal

Ecrire un message privé
Commentaire sur cette source (16)
Ajouter un commentaire et/ou une note

 Description

Quelquefois on a besoin d'ecrire des données ou faire des graphes sur Excel à partir d'une appli que l'on développe en VB... J'ai du faire ça et j'ai rencontré un p'tit probleme ... la première fois tout se passe bien mais les suivantes plantait en me disant "variable de block with non définie", et un process Excel residait en mémoire... la je me suis dis que j'allais trouver la solution sur Codes Sources ...mais non seul des pleurnichards se lamentaient d'avoir trouvé un bug incontournable..., faut se sortir les doits les gars... MSDN vous connaissez ??? donc voila comment régler ce petit probleme : IL FAUT ABSOLUMENT PASSER PAR DES VARIABLES DECLAREES MANUELLEMENT et non pas par les objes direct...sinon VB utilise des instances d'objet a lui et qui sont globale a l'appli et comme elles ne sont pas déclarée sont introuvable pour les tuer...
Donc faite comme suit...

Source

  • Option Explicit
  • Private Sub Command1_Click()
  • Dim xlApp As Excel.Application
  • Dim xlBook As Excel.Workbook
  • Dim xlSheet As Excel.Worksheet
  • Set xlApp = CreateObject("Excel.Application")
  • Set xlBook = xlApp.Workbooks.Add
  • Set xlSheet = xlBook.Worksheets("Sheet1")
  • xlSheet.Range(Cells(1, 1), Cells(10, 2)).Value = "Hello"
  • xlBook.Saved = True
  • Set xlSheet = Nothing
  • Set xlBook = Nothing
  • xlApp.Quit
  • Set xlApp = Nothing
  • End Sub 
 Option Explicit

      Private Sub Command1_Click()
         Dim xlApp As Excel.Application
         Dim xlBook As Excel.Workbook
         Dim xlSheet As Excel.Worksheet
         Set xlApp = CreateObject("Excel.Application")
         Set xlBook = xlApp.Workbooks.Add
         Set xlSheet = xlBook.Worksheets("Sheet1")
         xlSheet.Range(Cells(1, 1), Cells(10, 2)).Value = "Hello"
         xlBook.Saved = True
         Set xlSheet = Nothing
         Set xlBook = Nothing
         xlApp.Quit
         Set xlApp = Nothing
      End Sub

 Conclusion

ULR MSDN : http://support.microsoft.com/default.aspx?kbid=178 510
ou : http://support.microsoft.com/default.aspx?scid=kb; en-us;319832
------- tout en Anglais ...-------


 Sources de la même categorie

Source avec Zip Source avec une capture Source .NET (Dotnet) SPACE - UN SPACE MAC POUR WINDOWS par vbnino
Source avec Zip Source .NET (Dotnet) MULTI THREAD AVEC AFFICHAGE par jaknight007
Source avec Zip Source .NET (Dotnet) COMPILATEUR EN VB NET 2003 par alpha5
Source avec Zip Source avec une capture CRYPTER AVEC LE CHIFFRE DES NIHILISTES RUSSES par tresorsdevie
Source avec Zip Source avec une capture Source .NET (Dotnet) COMPTE_BANCAIRE.NET par Adn56
Toutes les sources de la catégorie Divers

Commentaires et avis

Commentaire de thedentiste le 10/08/2004 14:02:26

Merci beaucoup je suis tombé dessus par hasard et c'est pile poil ce qui vient de m'arriver dans mon appli vba j'avais plein de process excel en memoire

Thanks

Commentaire de le_chacal le 10/08/2004 14:59:38

ben de rien quand on peut aider... ;o)

Commentaire de Patrice99 le 11/08/2004 08:51:06

CreateObject sert si tu déclares un Objet, puisque là tu déclares un Excel.Application, tu peux directement faire un Set xlApp = New Excel.Application ou meme Dim xlApp As New Excel.Application

Qu'est-ce que tu veux dire par : IL FAUT ABSOLUMENT PASSER PAR DES VARIABLES DECLAREES MANUELLEMENT et non pas par les objes direct... ?
Tu veux dire qu'il ne faut pas oublier de faire Set xlApp = Nothing avant de quitter la fonction ? C'est vrai ! si tu laisses Excel visible en quittant la fonction et meme en quittant VB, Excel restera visible indéfiniment, ce qui veux bien dire que VB ne détruit jamais l'instance (sauf sous Access 97 : Excel disparait au bout de quelques secondes, mais pas avec Access 2000 ou XP !)
        

Commentaire de le_chacal le 11/08/2004 11:51:22

En fait le probleme se pose dans les cas ou apres avoir déclaré un Dim xlApp As New Excel.Application (qui fonctionne aussi bien que dans l'exemple que j'ai donné) , on utilise directement les objets fils de xlApp tels que :
With xlApp.Workbook.worksheet(1)
...
End With

au lieu de

Set xlBook = xlApp.Workbooks.Add
Set xlSheet = xlBook.Worksheets(1)

With xlSheet
       .cells(1, 1) = "Coucou"
end with

car la l'instance de workbook et de worksheet sont créés par Vb et donc on ne peux les détruire...car elle ne sont pas accessible du code ...et le process Excel reste en mémoire...et si tu rappelle la même fonction ca plante !

le fait de faire xlApp.Quit et Set xlApp = nothing reste en fonction de ton appli...si tu veux garder Excel ouvert, le fait pas...

J'espere avoir répondu a ta question...

Commentaire de Patrice99 le 11/08/2004 15:46:40

En changeant la ligne :

xlSheet.Range(Cells(1, 1), Cells(10, 2)).Value = "Hello"

en :

xlSheet.Range(xlSheet.Cells(1, 1), xlSheet.Cells(10, 2)).Value = "Hello"

cela corrige le problème comme indiqué dans MSDN. Le problème vient du fait que faire appel à Cells sans préciser xlSheet devant entraine la création d'une instance d'Excel qui risque de ne pas fonctionner dès le second appel de la fonction, conclusion : ne pas oublier de préfixer tous les objets par leur propriétaire afin d'éviter la création d'une instance parasite.

Commentaire de le_chacal le 11/08/2004 16:55:52

En fait ce qui se passe c'est que même préfixé par le propriétaire il ne faut pas utiliser les objets enfants tels quels comme

XlsApp.WorkBook.WorkSheets(1) .cell(1 ,1) = "hello"

car la, Vb crée une instance de WorkBook et une instance de WorkSheets qui lui sont propres et qui restent liés a l'appli malgré que l'on détruise le XlApp  par Set XlApp = Nothing

Il faut creer une variable XlBook qui contient le WorkBook (pareil pour le WorkSheets) et la on controle les instances et on peut ainsi les détruire ...

(pour eviter de tout declarer jusqu'a Cell , utilisez
With XlSheet
    ....
   .Cell(1.1)= "hello)
   ....
end With
)
Comme ca Excel peux se fermer, il n'est plus lié a l'appli car on ferme chaque objet manuellement

Commentaire de Patrice99 le 11/08/2004 17:20:02

Hé bien c'est faux !

la ligne suivante fonctionne toujours très bien :

xlApp.Workbooks(1).Worksheets(1).Range( _
        xlApp.Workbooks(1).Worksheets(1).Cells(1, 1), _
        xlApp.Workbooks(1).Worksheets(1).Cells(10,2)).Value = "Hello"

Commentaire de le_chacal le 11/08/2004 20:27:32

pas chez moi qd je fait ça il reste un process excel qui m'empeche même de réouvrir excel à partir de windows...
et c'etait comme ça que je faisais déjà quand j'ai rencontré ce problème....

bref maintenant c résolu tout fonctionne et c le principal !

Commentaire de Zigarn le 12/08/2004 10:42:30

Je viens de me lancer dans la liaison à Excel depuis VB et suis souvent tombé sur ce problème de processus Excel non terminé mais il m'a suffit de faire bien attention à fermer les objets et puis c'est tout :

Dim appExcel As New Excel.Application
Dim wbExcel As Excel.Workbook
Dim wsExcel As Excel.Worksheet

Set wbExcel = appExcel.Workbooks.Open("essai.xls")

For Each wsExcel In wbExcel.Worksheets
  wsExcel.Cells(1, 1).Value) = "tentative"
Next

wbExcel.Close
appExcel.Quit

Et il faut aussi faire attention de toujours fermer même si on quitte inopinement la procédure.

Voilà !

Commentaire de Zigarn le 12/08/2004 10:44:07

Désolé pour la parenthèse en trop.

Commentaire de cyrilp le 12/08/2004 15:47:37

D'accord avec Zigarn,

Le tout n'est pas de faire un "Set Nothing", cela detruit l'objet mais pas EXCEL.

EXCEL doit être fermé via un .QUIT !!!
En respectant cela, je n'ai jamais eu de souci de EXCEL restant en mémoire !

Commentaire de Zigarn le 13/08/2004 16:02:28

Par contre il y a toujours le problème que en cas de bug, il n'y a, semble-t-il, pas d'appel à ma procédure de fermeture et donc non fermeture de Excel. Si je le fais dans mon handler d'erreur appelé par On Error, et bien si le bug est arrivé avant l'ouverture, il me dit qu'il peut pas fermer quelque chose qui n'est pas ouvert (et je le comprends !). Y a-t-il un moyen de tester l'existence d'un objet du coup ?

Commentaire de cyrilp le 13/08/2004 16:42:20

je n'ai pas compris ce que tu voulais dire exactement Zigarn....

Mais avec le code suivant :
If Not <Mon Objet> Is Nothing Then
      ' destruction des variables
End If

Commentaire de Zigarn le 13/08/2004 16:48:34

Ca marche le "object is nothing" si il n'y a pas eu de "object.open" ?
A vrai dire j'ai pas pensé à essayer ...

Commentaire de abbassi_omar le 08/06/2006 04:12:58

merci pour votre aide
mais j'ai un prblm dans une application.
j'utilise un classeur exel existe pour imprimer des etats,quand j'appel le classeur  pour la premier fois ca marche bien mais si je le demande pour une deuxieme fois les cellule vienne vide.
pour avoir la possibilite d'imprimer une 2eme fois il me faut quitter l'application du tout!!! et ca marche pas dans des application proff

Commentaire de amalcon le 06/09/2006 17:02:53

Je cherchais désepérement pourquoi excel continuait à tourner alors que j'avais tout fermé correctement, sans trouver mon problème.
Merci infiniment pour ces explications.

Pour abbassi_omar, tu as essayé de ne déclarer que
         Dim xlApp (sans le As Excel.Application )
         Dim xlBook (sans le As Excel.Workbook )
         Dim xlSheet (sans le As Excel.Worksheet )
et de ne pas oublier les xlSheet. devant chaque Cell, Range et autre Rows/Columns ?
J'avais le même pb : excel qui ne se ferme pas bien. Cela a été résolu grace à ca : je peux maintenant faire 2 fois la même action, sans qu'il me dise que le serveur est introuvable ou autre erreur bizarre.

 Ajouter un commentaire

Nos sponsors


Sondage...

CalendriCode

Février 2010
LMMJVSD
1234567
891011121314
15161718192021
22232425262728

Consulter la suite du CalendriCode
 
Développement réalisé par Nicolas SOREL (Nix) avec l'aide de : Cyril DURAND et Emmanuel (EBArtSoft), Merci à Vincent pour ses précieux conseils.
CodeS-SourceS.com© Toute reproduction même partielle est interdite sauf accord écrit du Webmaster
CodeS-SourceS.com© est une marque déposée tous droits réservés

Google Coop CodeS-SourceS Google Coop CodeS-SourceS
Temps d'éxécution de la page : 0,764 sec (4)

Nous contacter | Annoncer sur CodeS-SourceS | Mentions légales
Outils Convertisseur VB/C# Snippets et scripts Outils en ligne La ToolBox
Communauté Programmation Photographie Technologie Newsgroups Emploi Forum Blogs
Guide d'achat Téléphonie mobile Image et son Informatique Bureautique Jeux vidéo
Logiciels Internet & Réseau Développement Market Android Jeux & Loisirs Graphisme Multimédia Sécurité Pilotes
Loisirs Cartes virtuelles Vidéos droles Jeux en ligne Géoguide AndroLib (Android Market)