bonjour tous le monde,
Est il possible d'integrer une feuille excel 2010 avec son ruban (le meme ruban que excel 2010) dans une winforms?
est ce que vous pouvez me mettre un lien sur une documentation.
Merci
bonjour tous le monde,
Est il possible d'integrer une feuille excel 2010 avec son ruban (le meme ruban que excel 2010) dans une winforms?
est ce que vous pouvez me mettre un lien sur une documentation.
Merci
Bonsoir,
Je me permet de commenter ce post malgrés son ancienneté.
Je voudrais savoir si tu avais trouvé une solution à ton problème parce que je souhaiterais pouvoir dans une application c# intégrér un fichier excel ou un fichier word pour pouvoir les modifier et les enregistrer. Mais je souhaiterais que mon fichier soit ouvert dans mon application et pas a par comme on peut le faire avec un File.open par exemple.
Merci d'avance
Bonjour,
je ne connais pas C# mais développant en VB.NET, les manipulations d'excel, entre autre, j'en fais à longueur de journées pour le boulot.
Je ne pense pas qu'il soit possible d'intégrer une fenêtre Excel dans un WindowsForm. Au mieux, vous aurez quelque chose d'équivalent à l'apperçu de classeurs Excel dans Outlook, c'est à dire simplement le contenu de la feuille. Un peu comme on peut intégrer IE dans une application sans pour autant avoir accès à son ruban, mais juste la fenêter de navigation.
Pour accéder à l'intégralité , il ne vous reste qu'une automation pour ouvrir Excel et écouter la fermeture de la fenêtre par l'utilisateur pour terminer l'automation.
Bonne chance !
Il y aurait peut-être aussi une solution avec un ADD-IN Office qui pourrait communiquer avec ton application.
Voir les Visual Studio Tools for Office (VSTO).
Hello,
J'avais pas mal recherché le concepte d'hebergé l'affichage d'un programme Office à l'intérieur d'une Winform. Et je n'ai jamais rien trouvé de concluant sur ce point (en tout cas à l'aide des composant fourni par Microsoft) alors que c'était possible avec les techno VB6 et Office 2003 (ça nous rend pas plus jeune ces histoires...).
Néanmoins, il est tout à fait possible de manipuler les applications Office par automation (en mode visible ou cacher) ce qui permet à peu près de faire tous ce que tu pourrais réaliser par des macros. Dans le cas d'Excel c'est aussi possible de traiter un fichier comme une base de donnée (feuille = table, colonne =colonne, ligne = enregistrement) pour des manipulations de lecture écritures des cellules avec des bonnes performance (l'automation péchant un peu sur la vitesse à mon avis)
Il est aussi possible de travailler directement sur le code XML des nouveaux fichiers Office (les xlsx, docx et pptx) et ceci sans avoir word qui tourne et sur une application serveur. Ce qui n'était pas possible (ou fortement déconseillé) à l'époque Office 2003. Ce qui ouvre la porte à la création d'un serveur de génération rapport sous la forme de document office.
Et il est bien entendu possible d'ouvrir un fichier par execution d'une ligne de commande dans l'application ad hoc et finalement je doute qu'on trouve une meilleure visionneuse que l'application Office dédiée à cette tâche :-) Il n'y a qu'à voir les dégats que font les visionneuses à l'implémentation plus ou moins foireuse de nos smartphones...
Je ferais l'impasse sous le VSTO et les nouveaux concept App de Office 2013 qui sont plutôt les descendants de nos bonnes veilles Macro VBA avec l'hébergement de contrôle oldschool au look rétro.
Alors oui on a perdu la possibilité kikoo de faire croire qu'on a recréer Office en bricolant une fenêtre à 2 balles autour d'un contrôle, mais bon on s'en porte pas plus mal...
Question performance des automations, j'attaque pas mal de bases de données Access, et d'autres traitements assez conséquents sous Excel, toujours par automation. Il faut juste penser à laisser l'application en invisible, et concernant excel plus particulièrement, désactiver le ScreenUpdate et gérer manuellement le calcul automatique des cellules si on manipule de grandes feuilles bourrées de formules de calculs.
C'est vrai qu'Excel pompe pas mal en affichage si on le laisse faire ce qu'il veut. Access est moins gourmand de ce côté car il n'affiche rien sans qu'on lui demande.
On boucle le tout dans un thread séparé avec un BackGroundWorker, et les performance sont équivalentes à l'application elle même.
Possibilité kikoo... ou contrôle des actions de l'utilisateur. J'ai le problème dans une bibliothèque de documents Word gérée par une application WindowsForm, et j'aimerais bien pouvoir afficher ma fenêtre Word comme MDIChild de mon Form Parent de manière à proposer l'apperçu avant impression de Word car recréer cette fenêtre de dialogue ne m'emballe vraiment pas.
On a peut-être surtout perdu quelque chose en fait.
Partager