VBXL : Programmation efficace d'Excel en VBA, VB6 et VB .Net
https://codes-sources.commentcamarche.net/source/17783
Documentation : vbxl.html
Code source : VBXL.vbproj.html
http://patrice.dargenton.free.fr/CodesSources/index.html
Date de mise à jour : 02/06/2011
Pour programmer efficacement Excel dans une feuille Visual Basic, il faut... ne pas utiliser Excel ! mais plutôt le contrôle tableur Office Web Component (OWC) de type Spreadsheet : il est conçu pour être initialisé via un modèle html purement Excel (notamment pour le format de présentation des cellules). Il peut traiter les événements (essayez par exemple le double clic) dans le conteneur du contrôle tableur, c'est-à-dire une feuille VB ou autre (formulaire Access, page HTML, ...), et cela contrairement, à ma connaissance, aux autres solutions déjà vu sur le site VBFrance.com pour afficher une feuille Excel en VB. Par ailleurs, on peut charger le tableur avec les valeurs d'une requête instantanément (via ADODB) en une seule instruction : 1 000 enregistrements en moins d'une seconde ! Et il n'y a plus besoin de la base de données après : tous les enregistrements sont chargés en mémoire vive (c'est le principe du mode déconnecté). Cela reste un vrai tableur : les champs calculés sont mis à jour quand on édite une cellule.
Mots clés : OWC, Office Web components, VB6, VBA, VB .Net, DotNet, Tableur, Feuille de calcul, Excel, Web parts.
Tables des matières
Bug
OWC 9 : lenteur sur certaine configuration.
Solution
palliative au bug de lenteur OWC 9
Distribuer
une application VB6 avec OWC
Gestion
des événements en DotNet pour OWC 10
Fonctionnalités
ajoutées dans OWC 10
Procédure
pour remplacer le tableur OWC 9 par OWC 10.
Procédure
pour remplacer le grapheur OWC 9 par OWC 10.
Procédure
pour repasser OWC en version 9
Erreur
lors de la migration de VS 2003 à VB 2005
Erreur
lors de la migration de VB 2005 à VB 2008
Déplacer
les dll dans un sous-dossier de l'application
Composants
d'accès aux données : ADO
Différences
entre AdoDb et OleDb
Le
composant Open Source XmlSS.NET Spreadsheet
Le
composant tableur SpreadsheetGear
Convertir
des fichiers Excel au format xaml
Version Silverlight de XmlSS.NET
Spreadsheet
Autre
composant DotNet à tester : Farpoint
Version
1.02 du 28/01/2007 en VB .Net
Identifiants
des classes (ClsID) et des programmes (ProdID)
Liens tirés de "The Microsoft
Office Web Components Black Book with .NET"
O.W.C. Outside of Internet Explorer
Security vulnerability white paper
Binding charts to xml datasource
Handling events for the O.W.C.
Handling events in windows forms
Convert ADO.NET dataset to ADO
recordset
Streaming Excel to the browser
Pivot Table Cloned Member issue
resolution
Pivot Table List View Programming
Pivot Table List in Access form
Creating cubes from relational
datasources
Registration free COM components
Connecting to XML Web Services
VBXL requiert que les composants suivants soient installés :
- OWC Spreadsheet 11/12 (téléchargeable gratuitement sur le web : OWC11.EXE) ;
- Microsoft ActiveX Data Objects 2.x Library, afin de remplir rapidement le contrôle tableur via une requête ADO (ADO est normalement présent sur tous les Windows XP, mais la version 2.6 au minimum est requise en DotNet, voir la rubrique correspondante) ;
- Version en VB .Net : Plateforme DotNet 2 (Framework .Net 2), c'est un composant optionnel proposé par Windows Update ;
- Version en VB6 : OWC 9 (livrée avec MS-Office 2000 ou XP) ;
- Versions OWC 10 et 11 : Contrairement à OWC 9, les versions OWC 10 et 11 requièrent que le contrôle MSComCTL.OCX soit enregistré pour que la barre d'outils soit visible (sinon la barre n'est pas visible, mais cela ne plante pas). Il est normalement installé sur un poste Windows XP (notamment via OWC11.exe) ;
- Version OWC 11 : Interop.MSComctlLib.dll doit être présent pour éditer le formulaire contenant le tableur, mais à priori cette dll n'est pas requise à l'exécution ;
- Modèles html pour le tableur : il faut utiliser une version d'Excel antérieur à 2007, les classeurs Excel sauvés en html avec Excel 2007 ne fonctionnent plus avec OWC.
Sous Windows vista, l'instanciation des contrôles ActiveX OWC pose problème, on obtient l'erreur suivante, aussi bien en mode Design qu'à l'exécution :
Tentative
de lecture ou d'écriture de mémoire protégée. Cela indique souvent qu'une autre
mémoire est endommagée.
à
System.Windows.Forms.UnsafeNativeMethods.IOleObject.DoVerb(Int32 iVerb, IntPtr
lpmsg, IOleClientSite pActiveSite, Int32 lindex, IntPtr hwndParent, COMRECT
lprcPosRect)
à
System.Windows.Forms.AxHost.DoVerb(Int32 verb)
à System.Windows.Forms.AxHost.InPlaceActivate()
Lors des premiers tests, j'ai cru qu'il fallait simplement recompiler les sources depuis un poste de
développement sous Vista, car dans ce cas, une mise à jour de Visual Studio
2008 spécifique pour Vista est proposée et doit être installée : elle permet de
produire des exécutables compatibles Vista (et rétro-compatibles XP bien sûr).
Mais ensuite, dès que l'on essaie d'autres modifications, l'application cesse
de fonctionner, comme si la première compilation de l'exécutable avait été
enregistrée quelque part, et impossible de savoir où. Après avoir envisagé
toutes les hypothèses (DEP : Data exec. protection, Application Compatibility
Database, Microsoft Application Verifier, Administrative Dependencies, Registry
Virtualization, requestedExecutionLevel, User Account Control (UAC), ActiveX
Installer Service), j'ai renoncé à trouver la cause du problème : le phénomène
n'est pas rationnel, cela ne fonctionne tout simplement pas. En désespoir de
cause, j'ai tout de même testé la version OWC 11. Cette fois, on peut utiliser
normalement le contrôle ActiveX, aussi bien compilé sous XP ou Vista ou
inversement, la compilation et l'exécution fonctionne dans tous les cas : il
s'agissait bien d'un problème de licence. Il ne
reste juste qu'à corriger 2 ou 3 anomalies avec
les graphes dans les versions d'OWC >=10.
On peut faire fonctionner OWC avec Windows 7 64 bits, et sans pour autant utiliser le mode XP contraignant (machine virtuelle), mais en utilisant WoW64 : il s'agit de simples dll (standards, déjà installées) permettant d'utiliser les programmes conçus en 32 bits depuis Windows 64 bits : pour cela il faut indiquer une option de compilation dans Visual Studio :
<PlatformTarget>AnyCPU</PlatformTarget>
->
<PlatformTarget>x86</PlatformTarget>
de façon à indiquer que le programme va utiliser par exemple des contrôles ActiveX 32 bits, et donc qu'il doit utiliser une virtualisation 32 bits de la base de registre, sans quoi le logiciel indiquera que le composant n'est pas installé (dans le registre 64 bits, alors qu'il l'est dans le registre 32 virtuel de compatibilité !)
Cette option de compilation n'est pas disponible dans l'interface de la version Express (gratuite) de Visual Studio, mais en comparant avant et après le changement de l'option dans une version complète de Visual Studio, on retrouve sans difficulté l'option, et il suffit de la rajouter à la main dans le fichier .vbproj (une pour le PropertyGroup Debug, et une autre pour le Release) et de recompiler.
Les options de PlatformTarget sont : AnyCPU, x86, x64 et Itanium.
AnyCPU est l'option par défaut : s'il n'y a pas d'option PlatformTarget, alors c'est AnyCPU par défaut, option qui signifie que l'application doit utiliser aussi bien la plateforme 32 ou 64 bits, selon la nature du système d'exploitation utilisé, ce qui ne convient pas dans notre cas, à cause du contrôle ActiveX seulement 32 bits OWC.
Explication de l'option de Visual Studio :
http://visualstudiohacks.com/articles/visual-studio-net-platform-target-explained/
"If the project is set to x86, this means the project is intended to run only as a 32-bit process. A 64-bit process will be unable to call into an assembly set as X86. Reasons to set your project as x86 include dependencies upon native DLLs that are only available in 32-bit or making native calls assuming 32-bit. Applications and assemblies marked for x86 can still run on 64-bit Windows. However they run under WOW64. Visual Studio itself runs under this emulation mode since it is a 32-bit application."
Doc WoW :
http://en.wikipedia.org/wiki/WoW64
http://en.wikipedia.org/wiki/Windows_on_Windows
Erreur OWC en 64 bits avec AnyCPU :
Classe non enregistrée (Exception de HRESULT : 0x80040154 (REGDB_E_CLASSNOTREG))
- Bug de formatage parfois si le séparateur décimal n'est pas "." : j'ai testé avec une version plus récente de OWC 9, soit OWC 11, et le problème est toujours là ! Solution palliative : changer le séparateur décimal à la volée (ce qui n'est pas très conseillé en mode multitâche avec d'autres logiciels : rétablir le plus tôt possible le séparateur décimal d'origine une fois les enregistrements chargés dans le tableur). Exemple avec VBXL : ce bug ce produit avec la colonne Vote, le format de précision à 2 décimales indiqué dans le modèle ne fonctionne pas : pour corriger cela, il faut commencer par utiliser un champ numérique réel et non texte dans la base de donnée, ce qui est logique (oubli de la 1ère démo VBXL). Ensuite, il faut mettre le booléen bGestionSepDecimal à Vrai dans le code pour changer le séparateur décimal à la volée : avec ces deux modifications, quel que soit le séparateur décimal en vigueur, le format précisé dans le modèle sera bien respecté maintenant ;
- Bug de formatage, notamment avec la catégorie "- Nul" (4ème colonne de mon exemple) : j'ai du mettre un quote devant : '- Nul ! En effet, le quote, ou guillemet simple, permet de forcer le mode texte dans une cellule Excel. Voici comment préfixer un champ par ' dans une requête (ce qui permet l'écriture directe des résultats de la requête dans le tableur, sinon il faut préfixer cellule par cellule) :
SELECT
""'"" & MaTable.MonChamp as MonChampPrefixé, ...
Autre solution possible : requête directe via les fonctions .ActiveSheet.ConnectionString et .ActiveSheet.CommandText : cela fonctionne bien, c'est rapide aussi et il n'y a pas de bug de formatage cette fois, voir ici : www.vbfrance.com/code.aspx?ID=47972
La principale limitation d'OWC 9 se rencontre parfois, sur certaine configuration : en réinstallant Windows XP sur un nouvel ordi, je dois maintenant attendre 30 secondes pour voir l'affichage des résultats ! Cela concerne l'écriture d'une cinquantaine de cellules une par une, et non d'un coup via ADO comme dans la démo VBXL. Lorsque je debug sur Visual Studio .Net pour voir quelle fonction est lente, le bug ne se produit plus !!! du coup, je suis obligé de chronométrer chaque fonction à l'exécution normale pour pouvoir finalement comprendre que le bug se situe au niveau de l'écriture d'une valeur dans une cellule du tableur OWC 9 : 99% du temps d'exécution total ! A priori, ce bug se produit plus fréquemment sur les postes avec beaucoup de RAM, à partir de 1Go (je n'ai pas réussi à faire diminuer suffisamment la RAM via un RamDrive ou RamDisk). Le bug est identique en DotNet2, avec VB6, ainsi qu'avec les versions 2002 et 2003 d'OWC 9.
Pour contourner le problème, voici une solution palliative, qui à l'inconvénient de nécessiter un peu de réécriture du code : Il suffit d'écrire en une seule opération, via la fonction ParseText, une série de valeurs contiguës dans le tableur. Cependant, si on essaye d'écrire une par une les cellules via cette méthode (tentative de solution pour éviter de réécrire du code), on retombe sur le problème de lenteur (ce qui incite à penser qu'il s'agit d'un problème général de passage de paramètre via l'interface ActiveX d'OWC 9). Voici un exemple d'écriture résolue selon ce principe ; sur un poste normal, le test prend moins d'une seconde, tandis que lorsque le bug est présent, le premier test prend une dizaine de secondes, et le second test reste inférieur à une seconde :
Effacer()
oXL.EnableUndo = False
oXL.EnableEvents = False
oXL.ScreenUpdating = False
oXL.ActiveSheet.Protection.Enabled
= False
Dim i%, j%
For i = 1 To 10
For j = 1 To 5
oXL.Cells(i, j) = (i + j)
Next j: Next i
oXL.EnableUndo = True
oXL.EnableEvents = True
oXL.ScreenUpdating = True
oXL.ActiveSheet.Protection.Enabled
= True
MsgBox ("Test 1 terminé")
Effacer()
oXL.EnableUndo = False
oXL.EnableEvents = False
oXL.ScreenUpdating = False
oXL.ActiveSheet.Protection.Enabled
= False
Const sDelimiteurCol$ = vbTab
Dim s$
For i = 1 To 10
For j = 1
To 5
s = s & (i + j) & sDelimiteurCol
Next j
s = s &
vbLf
Next i
oXL.ActiveSheet.Range("A1").ParseText s, sDelimiteurCol
oXL.EnableUndo = True
oXL.EnableEvents = True
oXL.ScreenUpdating = True
oXL.ActiveSheet.Protection.Enabled
= True
MsgBox ("Test 2 terminé")
Note : Parfois, le bug est due aussi au fait que le tableur est rempli alors qu'il n'est pas encore visible : il suffit alors d'attendre un peu au premier affichage avant de le remplir pour résoudre ce problème de lenteur... mais cela ne suffit pas pour ce test de vitesse par exemple. S'il y a trop de code à modifier pour utiliser cette solution palliative, il ne reste qu'à utiliser une version supérieure d'OWC !
- OWC requiert une licence Office pour l'interaction seulement, sinon la visualisation simple est libre de droit, il suffit de télécharger OWC (toutes les langues sont disponibles sur le site de Microsoft) : OWC11.EXE, ou OWC10.EXE pour 2003 ou 2002. On ne peut pas trouver la version 9=2000 en téléchargement sur le net, on ne peut la trouver que sur le CD d'installation d'Office 2000 (ou XP après installation). OWC 9 est livré avec Office 2000, OWC 9 et 10 sont livrés avec Office XP (mais attention aux versions patchées d'OWC 9), et OWC 10 et 11 sont livrés avec Office 11 (ces composants web sont bien installés par défaut, il n'est pas besoin de personnaliser l'installation d'Office) ; Office 2007 bêta 2 est livré avec OWC 10 et pas 11 !
- Il est interdit de distribuer la dll MSOWC.dll avec votre application, ce qui est dommage car cela simplifierait considérablement le déploiement de votre application, surtout si votre client n'a que Office 2003 : en effet, vous ne trouverez pas la dll en version 9 sur le poste de votre client ni sur son CD d'Office, et votre application ne fonctionnera peut être pas avec une autre version de la dll (voir la liste des bugs de la version OWC 10 et voir aussi le problème de la compatibilité des versions : rubrique suivante "L'Enfer des Dll"), il faudra donc demander à votre client de trouver un CD d'Office 2000 et n'installer votre application que sur le poste correspondant à cette licence valide, et copier cette dll depuis ce CD, par exemple dans un sous-dossier \Installation de l'application, comme pour VBXL ;
- En fait, avec OWC 9 ou 10, il suffit d'enregistrer la dll MSOWC via RegSvr32, manuellement ou via le code : cela fonctionne même dans un Windows "vide" sans Office (il n'est pas nécessaire d'installer réellement Office), y compris en mode édition : OWC est complètement fonctionnel ! en théorie, il faut une licence spécifique, sous la forme d'un fichier lpk (cf. LPK tool pour la création de fichier licence pour un contrôle ActiveX). Cela sert par exemple à faire une installation de votre application depuis un lecteur réseau sur des postes clients pour lesquels Office n'a pas forcément encore été installé. Cette faille a été corrigée en version 11 : si on installe OWC 11 via le package d'installation OWC11.exe et qu'on n'a pas Office 2003, le tableur est bien en lecture seule (en tout cas dans les premières versions d'OWC11, maintenant ce problème n'existe plus à ma connaissance ; par ailleurs le contournement via RegSvr32 en procédure manuelle ou par le code ne marche plus). Sous Windows Vista, seul OWC 11 fonctionne, sans doute à cause de ce qui vient d'être indiqué ;
- Si vous n'avez pas de licence Office, la version Access Runtime (gratuite) ne suffit pas pour pouvoir interagir avec un tableur OWC dans un formulaire Access. En revanche, si vous n'avez qu'une licence Office standard sans Access, alors la version Access Runtime suffit pour utiliser pleinement OWC dans un formulaire Access, car dans ce cas, les composants OWC sont bien installés avec Excel. Cela fonctionne même s'il s'agit d'Office XP avec le Runtime d'Access 2000.
Vous trouvez ces problèmes de licences et de déploiement compliqué ? hé bien c'est encore plus compliqué en ASP.Net selon si OWC est instancié coté serveur ou coté client, s'il y a une ferme de serveurs ou bien un serveur multicoeur, si le compartimentage des thread est MTA ou STA, si le contrôle est instancié dans le PageLoad ou plus tard... voir le livre "The Microsoft Office Web Components Black Book with .NET".
Normalement, il est recommandé d'installer toutes les mises à jour critiques proposées par Windows Update pour les composants Windows, notamment DAO et IE6 SP1 (comprenant ADO/MDAC), ainsi que les mises à jour d'Office (pour Access) via Office Update ; il y a cependant un cas particulier avec Office XP SP3 : le composant OWC 9 est mis à jour dans le SP3 (MSOWC.DLL version 9.0.0.8028 du 24/11/2003), il est compatible de façon ascendante avec la version d'origine d'OWC 9 (MSOWC.DLL version 9.0.0.3821 du 22/02/2000), mais pas de façon descendante, ce qui implique que vôtre logiciel distribué doit obligatoirement être compilé avec la version d'origine d'OWC 9 pour que tous les clients puissent faire fonctionner votre logiciel quelque soit leur configuration ! Le TypeLib (librairie de types) OWC 9 doit être en version 1.0 et non 1.1, supprimez la clé 1.1 le cas échéant dans la base de registre avant de déployer votre application (cela permet de débloquer VB6, lorsque la clé 1.1 est présente), et vérifiez les clés suivantes :
[HKEY_CLASSES_ROOT\TypeLib\{0002E540-0000-0000-C000-000000000046}]
- Et éventuellement pour VB6 :
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Visual Basic\6.0\{0002E540-0000-0000-C000-000000000046}#1.0]
@="C:\\PROGRA~1\\MICROS~3\\Office10\\MSOWC.oca"
- Note : à priori, il n'est pas possible de désinstaller le SP3 d'OfficeXP, on peut seulement réenregistrer la dll d'OWC 9 d'origine en version 1.0, et supprimer la clé 1.1 du TypeLib pour retrouver un poste de développement compatible toutes versions d'Office (en VB6 et VB .Net, on peut éditer le fichier projet dans le bloc-notes pour changer le TypeLib ; sous Access, il est carrément impossible de changer la version du TypeLib d'un composant dans un formulaire, à moins de supprimer puis réinsérer le composant ! faites des sauvegardes et réimportez un formulaire antérieur le cas échéant... sinon voir ici pour visualiser le code caché des formulaires Access, on peut éventuellement le changer...) ;
- Les fichiers TypeLib compilés (oca) sont situés ici :
C:\PROGRA~1\MICROS~3\Office10\MSOWC.oca : version 1.0
C:\Program Files\Microsoft Visual Studio\VB98\MSOWC.oca : version 1.1 incompatible avec la version 1.0
C:\PROGRA~1\FICHIE~1\MICROS~1\WEBCOM~1\10\OWC10.oca : version 1.1 incompatible avec la version 1.0
- Les classes des deux principaux objets sont "OWC.Spreadsheet.9" et "OWC.Chart.9", voir aussi les Identifiants des classes (ClsID) et des programmes (ProdID).
Normalement, il faut faire un logiciel d'installation pour pouvoir proprement installer puis désinstaller des composants. Cependant, attention à ne pas enregistrer MSOWC.dll systématiquement, auquel cas on ne pourrait plus désinstaller l'application sans désinstaller OWC ! il faut voir si on peut installer OWC si et seulement si il n'est pas déjà installé sur le poste (voir si l'assistant d'installation le permet, et voir s'il faut obligatoirement produire un fichier avec une licence pour redistribuer OWC en mode consultation seule, comme c'est le cas par exemple pour afficher des rapports dans une page web, ce qui est en fait l'utilisation principale prévue à l'origine pour OWC, par exemple avec Excel en faisant "Enregistrer sous" : "Page Web" : cocher "Ajouter l'interactivité" : en pratique le résultat est à peu près incompréhensible, et à mon avis peu de monde a utilisé ce truc).
Sinon une alternative consiste à démarrer l'application sur la procédure Main() avant d'afficher la feuille VB6, ce qui permet de faire toutes les vérifications sans plantage (notamment vérifier le numéro de version des dll), et le cas échéant d'enregistrer la dll OWC par le code : cela fonctionne très bien, à condition que l'utilisateur dispose des droits administrateur sur le poste (comme pour l'installation de certains logiciels), sinon Regsvr32.exe renvoi le code d'erreur 0x8002801c.
- OWC 10 : Ok, tout marche, sauf quelques problèmes avec les graphiques ;
- OWC 11 : Si on n'a pas Office 11, il est impossible de compiler l'exe, pourtant VBXL fonctionne en mode interprété ! les événements peuvent être récupérés, mais la feuille est verrouillée (par la licence) : pas de filtre ni édition. Par contre on peut la remplir par le code avec ADO.
Ce serait bien si on pouvait faire la même chose avec les graphiques, mais l'objet OWC Chart ne permet pas de charger un modèle html, ce qui dommage, car la mise en forme du graphique doit se faire totalement par le code (heureusement cette programmation est assez simple, car le formatage est automatique). L'intérêt du modèle html est bien sûr la conception via l'interface graphique d'Excel sans aucune ligne de code ! Idée pour trouver comment faire des graphiques par le code : examiner le résultat produit par l'enregistreur de macro d'Excel.
Je n'ai pas réussi à compiler en mode Strict en DotNet, probablement à cause de petits défauts de normalisation des interfaces des composants OWC (par exemple il y a certaines incohérences avec l'intellisense, voir le livre "The Microsoft Office Web Components Black Book with .NET").
- Large fonte : sur un écran LCD de 17 pouces configuré en haute résolution, on est souvent obligé de travailler avec une grande police de caractère pour pouvoir facilement lire les menus Windows (ou sinon on doit utiliser une plus basse résolution, ce qui n'est pas toujours très net sur un écran LCD). Or le redimensionnement des contrôles ActiveX ne fonctionne pas bien en Large Fonte, car les barres de défilement ne sont plus visibles !
- OWC 10 : impossible de récupérer les événements ! Il s'agit en fait d'un bug des adaptateurs (wrappers) d'origine pour OWC 10 :
Un article est publié sur le site de Microsoft pour corriger ce bug :
HOW TO:
Handle Events for the Office Web Components in Visual Studio .NET
http://support.microsoft.com/?kbid=328275
En pratique, cette procédure est complexe : je n'ai pas réussi à compiler la classe corrigé avec les outils en ligne de commande, cependant, en créant un nouveau projet CSharp, il est plus facile d'ajouter les références manquantes, et cette fois la compilation se passe sans trop de difficultés, voir le projet AxOWC10.sln dans le fichier WrapperOWC10.zip. Vous pouvez simplement utiliser les dll du dossier DllOWC10. Si vous souhaitez recompiler les wrappers pour les modifier (à priori ce n'est pas nécessaire), voici quelques notes pratiques :
Notes :
- Vous devez installer Visual C# 2003 pour compiler le projet AxOWC10.sln (pas testé avec Visual C# 2008 Express) ;
- Les outils en ligne de commande ("Visual Studio .NET 2003 Command Prompt") sont accessibles via un raccourci ajouté par VS .NET dans le menu "Démarrer" : "Programmes": "Microsoft Visual Studio .NET 2003" : "Outils Visual Studio .NET" ;
- Ne confondez pas la dll interop OWC10.DLL (424 Ko en version 2621, ou 456 Ko en version 6765) avec la dll du même nom contenant les composants OWC 10 (XP) : 7262 Ko (2621) ou 7083 Ko (6765) ;
- Ne renommez pas les dll à produire, même si vous voulez tester les différentes versions de la dll ;
- Enregistrez la bonne dll OWC avant d'extraire son code via l'utilitaire aximp (pour les Windows en français, remplacez "common files" par "Fichiers communs" ; cette opération est déjà faite dans le projet AxOWC10.sln, ainsi que les modifications indiquées dans l'article ci-dessus ; la dll OWC peut être située n'importe où, du moment qu'elle est bien enregistrée dans la base de registre) :
aximp
"c:\program files\Fichiers communs\microsoft shared\web
components\10\owc10.dll" /source
- La compilation provoque un warning qui peut être ignoré selon l'article Microsoft : "Le mot clé new est requis sur 'AxOWC10.AxSpreadsheet.DesignMode', car il masque le membre hérité 'System.ComponentModel.Component.DesignMode'" ;
- Les originaux des sources et dll se trouvent dans le dossier Originaux de chaque version dans le projet WrapperOWC10.zip ;
- Les Wrappers OWC sont compilés en DotNet 1, ce qui ne semble pas perturber le fonctionnement en DotNet 2 (cf. l'attribut des dll : Version du runtime : Version du runtime .NET avec lequel cet assembly a été compilé) ;
- L'utilitaire aximp n'est plus fourni avec la version Express de VB 2008 (par contre il se trouvait encore dans la version VB 2005 Express, mais elle a disparu du web). On trouve bien l'utilitaire dans le SDK de Vista Studio, qui est en libre téléchargement, mais on ne peut pas l'installer avec la version Express.
- On peut ajouter des commandes personnalisées dans la barre d'outils ;
- On peut changer la langue utilisée via oXL.LanguageSettings (mais cela ne corrige pas les bugs de format : la langue française est déjà paramétrée) ;
- On peut écrire dans une cellule via .Text et .Value2 (pour éviter les problèmes de format, par exemple pour les dates forcées en anglais dans OWC 9, 10 et 11, et aussi parfois pour les numériques) ;
- On peut désactiver le mode calcul : xlCalculationManual ;
- En option, on peut ne recalculer que les cellules concernées :
OWC10.Range.Formula et OWC10.Range.Calculate
Avant toute chose, vérifier que votre projet compile bien sans erreur, et que le mode Design de tous les formulaires s'affiche également sans erreur (recompiler tout avant au besoin ; si vous rencontrez l'erreur "Impossible de lier un gestionnaire d'événements à l'événement 'xxx', car il est en lecture seule" voir la solution ici). Cette procédure est facultative, la voici juste pour info., car une méthode plus simple est présenté après :
1°) Remplacer dans le code AxOWC.AxSpreadsheet par AxOWC10.AxSpreadsheet
Les deux lignes concernées sont (#Region " Code généré par le Concepteur Windows Form ") :
Private WithEvents oXL As
AxOWC.AxSpreadsheet
Me.oXL = New
AxOWC.AxSpreadsheet
2°) Remplacer les références AxOWC et OWC par AxOWC10 et OWC10
Note : si vous copiez une fois pour toute ces 2 dll dans le dossier (ou un sous-dossier) de votre application, vous pouvez mettre l'attribut Copie locale = False pour ces 2 références.
3°) Remplacer les gestionnaires d'événements AxOWC.IWebCalcEventSink_DblClickEvent par des simples System.EventArgs et simplifier le cas échéant ces procédures par .ActiveCell.Row, .Column et .Value pour obtenir les infos sur la cellule en question.
4°) Editer à nouveau le formulaire contenant OWC (ucTableur.vb en mode Design dans VBXL)
Note : une référence à MSDATASRC.dll est maintenant requise pour pouvoir éditer le formulaire (contrairement à OWC 9, c'est à cause de la ligne supplémentaire Me.oXL.DataSource = Nothing dans la fonction InitializeComponent avec OWC 10). Il faut juste sauver une fois le formulaire modifié pour mettre à jour le fichier frmXXX.resX (et éventuellement remettre à la bonne taille le contrôle dans le formulaire, cela peut corriger un bug sur le dimensionnement automatique du formulaire au démarrage, si la taille est sauvée dans un fichier xml de configuration).
Pour passer facilement d'une version d'OWC à une autre, le plus simple est d'utiliser une classe (cf. ucTableur.vb) qui encapsule les appels aux fonctions du tableur et utilise les bons gestionnaires d'événement selon chaque version, simplement en switchant une constante de compilation conditionnelle (les étapes 1, 2 et 3 ne sont donc plus nécessaire, mais attention car les dll à distribuer avec votre application ne sont pas les mêmes, voir la procédure d'installation automatique dans VBXL qui adapte l'affichage des messages en fonction de la configuration) :
#Const iOWC9 = 9
#Const iOWC10 = 10
#Const iOWC11 = 11 ' 11 et 12 sous Vista
#Const iOWC = iOWC10
#If iOWC = iOWC9 Then
Imports OWC
Imports AxOWC
#ElseIf iOWC = iOWC10 Then
Imports OWC10
Imports AxOWC10
#ElseIf iOWC = iOWC11 Then
Imports OWC11
Imports AxOWC11
#End If
Ensuite, tout semble fonctionner très bien et plus rapidement même (le premier bug signalé sur la lenteur rencontré sur certaines machines est effectivement corrigé)... jusqu'à ce que l'on tombe sur un bug système :
Un bug système survient de façon inopinée et plus ou moins aléatoirement suite à un affichage complexe :
System.NullReferenceException:
La référence d'objet n'est pas définie à une instance d'un objet.
at
System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr
hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at
System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
at System.Windows.Forms.Control.DefWndProc(Message& m)
at System.Windows.Forms.AxHost.WndProc(Message& m)
at
System.Windows.Forms.ControlNativeWindow.OnMessage(Message& m)
at
System.Windows.Forms.ControlNativeWindow.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd,
Int32 msg, IntPtr wparam, IntPtr lparam)
Ce bug se produit également en DotNet2 ; un test avec OWC 10 version 1.0 (2621 : nécessite de reconstruire l'adaptateur pour gérer les événements) au lieu de OWC 10 SP3 (6765) produit le même bug system.
Plusieurs autres bugs ou modifications ont été rencontrés :
- Il semble que sur certaines configurations, le simple clic ne fonctionne plus ! (cas où les cellules sont fusionnées dans le modèle Excel ?) ;
- L'export vers Word est 10 fois plus lent en OWC 10 ! L'export Excel n'est pas ralenti mais présente quelques petits défauts sur les cellules vides : la couleur de fond est perdue ! Pareil en OWC 11. Le bug ne se produit pas si on exporte directement via le bouton de la barre d'outil. Solution possible : ajouter un espace comme valeur dans la requête source ;
- La lecture de la position du scroll (barre de défilement) ne fonctionne plus en OWC 10 (ActiveSheet.Range(sPlage).Left et .Top ne dépendent plus du scroll) ;
- La définition de la présentation (bAfficherXXX) doit être faite plus tard, une fois que le tableur est complètement visible à l'écran, sinon ces options sont ignorées ;
- Me.oXL.DisplayOfficeLogo = False plante ! (cela est un peu gênant pour les graphes, car le logo OWC 10 est un peu trop ostensible. Le changement de la propriété en mode Design plante aussi ("Défaillance irrémédiable"). Solution : Afficher un graphique vide dès l'affichage du contrôle ;
- ActiveSheet.Cells.Clear() ne remet plus la largeur des colonnes à celle par défaut ;
- UsedRange.AutoFitRows() doit être remplacé par UsedRange.Rows.AutoFit(), de même que pour Columns ;
- Contrairement à OWC 9, OWC 10 requiert que le contrôle MSComCtl.ocx soit enregistré pour que la barre d'outils soit visible (sinon la barre n'est pas visible, mais cela ne plante pas).
Un test avec OWC 11 montre que le bug system n'a toujours pas été corrigé.
La procédure est tout à fait analogue à celle du tableur :
1°) Remplacer dans le code AxOWC.AxChartSpace par AxOWC10.AxChartSpace
Les deux lignes concernées sont (#Region " Code généré par le Concepteur Windows Form ") :
Private WithEvents oGr As
AxOWC.AxChartSpace
Me.oGr = New AxOWC.AxChartSpace
2°) Remplacer dans le code les constantes OWC.ChartXXXEnum par OWC10.ChartXXXEnum
3°) Remplacer les références AxOWC et OWC par AxOWC10 et OWC10
Là aussi l'utilisation d'une classe (cf. ucGraphe.vb) simplifie la migration. Je ferai prochainement une démo sur l'utilisation des graphiques. Pour le moment, voici les différences que j'ai rencontrées en migrant vers OWC 10 :
- Si on mélange des graphiques de type ChartChartTypeEnum.chChartTypeArea (29) avec des chChartTypeColumnClustered (type par défaut : 0), les chChartTypeArea doivent être tracés en dernier en OWC 10, alors que cela n'a pas d'importance en OWC 9 (on peut donc toujours les tracer en dernier pour avoir un code migrable) ;
- Les graphiques sont maintenant sensibles au séparateur décimal (il faut alors forcer le point décimal), et pour certains graphiques contenant différents types de courbe, il faut parfois ajouter des valeurs nulles (simplement faire maSerie &= "?" & vbTab) ;
- Pour les graphiques de type ChartChartTypeEnum.chChartTypeColumnStacked (1) en OWC 10 et 11, il faut appliquer le type au graphique et non plus à chaque série (comme cela fonctionnait en OWC9), et cela fonctionne aussi en OWC9.
Voici la procédure pour revenir à la version 9 d'OWC (juste pour info., pour vérifier que les classes ucTableur.vb et ucGraphe.vb fonctionne toujours) :
1°) Copier les dll de \DllOWC9 vers le chemin courant ;
2°) Ajouter les références via le menu parcourir, avec les propriétés suivantes : Version spécifique : True (car les dll en version 9 ne peuvent pas être mises à jour : les patchs ne sont pas compatibles avec toutes les versions d'OWC 9 que les clients de vôtre logiciel peuvent avoir, par exemple s'ils n'appliquent pas les mises à jour), Copie locale: False (car les dll sont déjà en local) ;
3°) Switcher la constante iOWC en iOWC9 ;
4°) Supprimer la ligne : Me.oXL.DataSource = Nothing (DataSource n'existait pas encore en OWC 9) ;
5°) Vérifier en mode Design la taille du contrôle OWC : il ne doit pas dépasser la taille du formulaire, sinon les booléens pour afficher les barres de défilement horizontale et verticale ne fonctionnent plus.
Attention car le designer corrige en précisant la ligne suivante (il faudra enlever AxOWC. si on change à nouveau de version d'OWC) :
Me.oXL = New AxSpreadsheet --> Me.oXL = New
AxOWC.AxSpreadsheet
Avant de convertir le projet VBXL.sln en VB 2005, pensez à inscrire d'abord la dll OWC dans la base de registre, si ce n'est pas déjà fait (il suffit de lancer la démo VBXL pour le vérifier), ainsi vous n'aurez que 4 warnings sans gravité, sinon, vous risquez de ne pas pouvoir compiler si la référence à la dll n'est pas trouvée avant la conversion du projet.
Pour l'édition des écrans en mode Design, si vous rencontrer un bug, voir même un plantage complet de VB 2005 Express, cela est peut être due à une erreur un peu sibylline déjà affichée en DotNet1 : "Impossible de lier un gestionnaire d'événements à l'événement 'xxx', car il est en lecture seule" : La solution consiste alors à ajouter le mot clé Protected dans la déclaration du contrôle utilisateur ucTableur :
Friend WithEvents ucT As ucTableur -> Protected Friend WithEvents ucT
As ucTableur
Note : Le code source du projet VBXL est strictement identique en DotNet2, aucune ligne de code n'a été convertie (on y arrive en modifiant légèrement quelques lignes avant la conversion, en faisant des essais de conversion), seuls les fichiers vbxl.sln vbxl.vbproj et vbxl.vbproj.user sont mis à jour : tant qu'on n'utilise pas de code spécifique DotNet2, cela permet de garder le même code source. Pensez à tout recompiler le code de façon à faire apparaître le contrôle ucTableur en mode design.
Si vous migrez la version 1.02 (VB 2005) de VBXL en VB 2008, il faut d'abord corriger les références OWC sur le répertoire principal (et non \obj\Debug), et vous obtenez ensuite au lancement le message :
"Erreur lors de l'exécution du projet : Impossible de démarrer le programme '...'.
Cette application n'a pas démarré, car la configuration de l'application est incorrecte. Consultez le fichier manifeste à la recherche des erreurs possibles. Réinstaller l'application pourrait résoudre ce problème. Pour plus d'informations, consultez le journal des événements de l'application."
Solution : supprimez simplement le fichier app.config dans l'IDE : la gestion du fichier de configuration a changé est n'est plus compatible : voir le code modifié dans la nouvelle version avec My.Settings.MonParametre = xxx.
A propos du journal des événements de l'application, je ne l'ai jamais trouvé, et je pense qu'il faut que l'application soit prévue en ce sens pour que cela fonctionne, par exemple il faut activer les événements log et ensuite utiliser My.Application.Log.WriteException partout dans le code pour écrire des informations dans ce journal :
Comment : écrire dans le journal des événements de l'application
http://msdn.microsoft.com/fr-fr/library/07347hdt.aspx
On propose aussi d'utiliser le débogage JIT pour corriger cette erreur, mais là non plus je n'ai jamais compris comment il était possible de l'activer !
- En DotNet on peut toujours compiler l'exe ! (contrairement à VB6 avec OWC 11 sans avoir Office 11) ;
- Si le composant OWC n'apparaît pas dans la boite à outil de VB Express, voici la méthode à suivre (de même que pour n'importe quel contrôle ActiveX) : il ne faut pas passer par le menu Projet : Ajouter une référence, mais par le menu contextuel de la boîte à outil : Ajouter/Supprimer des éléments ;
- Lancement d'un exécutable sur un lecteur réseau : ne marche pas ! C'est une question de sécurité DotNet, ce n'est pas un bug. Cette politique de sécurité a changé dans DotNet 3.5 SP1 (11/08/2008) : les applications peuvent maintenant s'exécuter depuis le réseau, ce qui devrait peut être simplifier le déploiement ;
- Lors d'un Export Excel, on a parfois le message "perso.xls est verrouillé pour modification" si Excel était déjà ouvert. La marche à suivre est d'aller dans le répertoire du fichier perso.xls, de sélectionner propriétés dans le menu contextuel, puis de cocher Lecture Seule :
"\Documents and
Settings\[CompteUtilisateurWindows]\Application
Data\Microsoft\Excel\XLSTART\PERSO.XLS"
- Mode lecture seule global au niveau de la classe ucTableur : on peut enlever la protection de la feuille pour autoriser les tris et les filtres, sans pour autant autoriser la modification du contenu des cellules, qui est interceptée avec un message d'explication. Cependant, pour pouvoir saisir des données (par exemple en cas d'utilisation de formules), il faudra remettre le verrouillage de la feuille (avec la gestion des seules cellules autorisées en édition : mode "protégé" pour ne pas effacer les formules) et désactiver le mode lecture seule global de la feuille au niveau de la classe ucTableur ;
- Démo comportant un lien hypertexte : cellule K1 (l'adresse doit être complète, car les adresses relatives ne sont pas gérées en OWC 9, ni les tips - ou infos bulles - ; on peut ajouter des liens par le code via le champ SubAddress : je n'ai pas testé pour quelle version d'OWC cela fonctionnait).
Pour masquer les dll OWC, il est tout à fait possible de les déplacer dans un sous-dossier de l'application : cela simplifiera le mode d'emploi de votre logiciel, car votre exécutable ne sera pas encombré de dll qui perturberont peut-être vos clients. Pour cela il suffit d'inclure un fichier VBXL.exe.config dans le répertoire de l'application, contenant une ligne probing avec le champ privatePath contenant le sous-dossier (DllOWC ici) :
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<runtime>
<rt:assemblyBinding xmlns:rt="urn:schemas-microsoft-com:asm.v1">
<rt:probing privatePath="DllOWC" />
</rt:assemblyBinding>
</runtime>
</configuration>
Le seul petit problème, c'est que cela ne fonctionne apparemment pas si le fichier app.config est géré par Visual Basic 2008 Express : normalement, ce fichier devrait être recopié en VBXL.exe.config depuis app.config, mais cela n'est pas le cas : je pense que la gestion de l'infrastructure de l'application par VB Express (même si l'option n'est pas activée) ne permet pas ensuite d'ajouter des champs dans le fichier de config. En conclusion, si vous voulez utiliser cette fonctionnalité, il faudra gérer entièrement la sauvegarde des paramètres (ne plus utiliser My.Settings.MonParametre = xxx, et ne pas ajouter de fichier app.config dans l'IDE) ce qui est un peu dommage.
Pour que l'application fonctionne quelle que soit la version d'ADO (ActiveX Data Object) installée sur un poste, il suffit d'indiquer l'option "Version spécifique" = faux dans les propriété de la référence (ADODB).
AdoDb et OleDb sont tous les deux des adaptateurs pour DotNet des composants Com/ActiveX correspondants, ce ne sont pas des fonctionnalités natives de DotNet (contrairement à SqlClient pour SQL Server). Cependant, OleDb est bien mieux intégré à DotNet, car toute une hiérarchie de classes DotNet y fait référence. Mais la fonctionnalité AdoDb.GetString qui nous intéresse ici pour charger rapidement le contenu d'un RecordSet dans le tableur, n'existe pas en OleDb (il existe une fonction OleDb.GetString qui ne fait pas la même chose : elle est limitée à un seul champ d'un seul enregistrement).
En utilisant la fonction copier/coller du tableur OWC (copier depuis le tableur OWC et coller vers une feuille de calcul Excel), on obtient parfois (avec OWC 11 notamment) l'erreur suivante 0xE004003B ( 3758358587) :
System.Runtime.InteropServices.COMException: {"Exception de HRESULT
: 0xE004003B"}
Data:
{System.Collections.ListDictionaryInternal}
HelpLink: Nothing
InnerException: Nothing
Message: "Exception de HRESULT :
0xE004003B"
Source: "Interop.OWC11"
StackTrace: " à OWC11.RangeClass.Select() à IL.ucTableur.SelectionnerPlage(String
sPlage) dans ucTableur.vb:ligne 1236"
TargetSite: {System.Reflection.RuntimeMethodInfo}
L'erreur provient du fait que la fonction :
sPlageUtilisee
= Me.oXL.ActiveSheet.UsedRange.Address.ToString()
indique une colonne en trop : la solution consiste donc, dans le cas d'une liste d'enregistrement dont le nombre de colonnes est connu à l'avance, d'extraire le nombre de ligne via la fonction suivante :
Dim
iLigneFinPlage% = Me.ucTableur.iLigneFinPlage(sPlageUtilisee)
puis de déduire la plage réellement utilisée (sPlageVisible n'indiquant pas le nombre de lignes) :
sPlageUtilisee
= sPlageVisible & iLigneFinPlage
Parfois l'instruction .ActiveSheet.Cells.ClearContents() peut prendre 1 seconde au lieu de quelques millisecondes, mais on peut la remplacer par .ActiveSheet.Cells.Value = "" ; en fait cela se produit aussi sur des fonctions comme ParseText, et seulement s'il n'y a qu'une seule ligne, à partir de 2 lignes cela ne se produit plus :
.ActiveSheet.Range(sPlage).ParseText(sbValeurs.ToString, vbTab)
OWC étant un contrôle ActiveX, son utilisation au sein d'un programme DotNet occasionne une perte de performance (due à l'interfaçage des données entre le monde ActiveX-Win32 et la plateforme DotNet), dégradation qui est particulièrement sensible dans le cas d'un grand nombre de cellules à mettre à jour. On peut certes optimiser le code de façon à écrire d'un coup une plage de cellules, mais cela requiert la réécriture du code source (qu'il faudra du coup bien re-tester). Et s'il s'agit de colorier un grand nombre de cellules disjointes, il faudra bien le faire une par une.
Un autre des problèmes que pose OWC est par exemple le nécessaire changement à la volée du séparateur décimal (de virgule en point) pendant le transfert en bloc d'un grand nombre de données (car le 'parser' ne traite que le format Anglais des décimaux) : cela fonctionne, mais cette solution n'est pas satisfaisante en soi, car elle pourrait très bien cesser de fonctionner avec la restriction de la gestion des paramètres régionaux de Windows par les applications, avec l'augmentation des mesures de sécurité. Un autre problème encore est qu'OWC est une technologie sans avenir : elle est abandonnée au profit des technologies orientées web. OWC .Net n'existera pas (OWC "12" de MS-Office 2007 est simplement une version repackagée d'OWC 10), car la vision de Microsoft dans ce domaine est concentrée sur Sharepoint (voir ci-dessous) et Excel Services.
Deux solutions peuvent être envisagées pour remplacer OWC : une solution Open Source, et l'achat d'un composant DotNet. L'avantage de l'Open Source est que la solution peut être améliorée (et elle est gratuite), mais pour le moment la solution trouvée est incomplète, il faut donc ajouter les fonctionnalités qui manquent. L'avantage d'un composant tout fait est que beaucoup de fonctionnalités sont déjà implémentées, mais l'inconvénient est qu'il faut attendre pour celles qui manquent (et le composant est payant).
Mais dans les deux cas, une solution pure DotNet garantie la pérennité et l'évolutivité de l'application et même sa portabilité : il existe un projet de portabilité des applications DotNet sur des environnements autres que Windows. On peut alors envisager le fonctionnement du logiciel exécutable sur toutes les plateformes non Windows supportant DotNet, à savoir Linux et MacOS avec le projet Mono (une fois que le code a été rendu compatible, le lancement de l'application ne nécessite pas même une recompilation).
Pour aller plus loin, le fait d'éviter les contrôles ActiveX ne peut que simplifier le portage des applications DotNet dans une page web. L'avantage des applications web est l'absence d'installation spécifique (hormis les plug-in éventuels), et le logiciel est toujours à jour. Deux philosophies s'affrontent, selon la taille des logiciels : d'une part le mode client-serveur avec ASP .Net / PHP / Java, et d'autre part le mode client riche avec Flash, Java encore et Silverlight (qui peut même s'exécuter en mode déconnecté). Ce qu'on appelle le web 2.0 étant un mix entre les deux approches, c'est-à-dire la possibilité d'interagir plus près du navigateur client sans avoir à recharger entièrement une page web à chaque demande de l'utilisateur. La flexibilité du web 2.0 autorise en particulier l'utilisateur à configurer sa page personnelle sur le site web en ajoutant ou enlevant des outils ou gadgets (voir par exemple les Web Parts dans Sharepoint).
Le mode client-serveur est accessible par principe depuis tous les environnements, tandis que le mode client riche dépend de l'interopérabilité : Flash est disponible partout, ainsi que Java, et Silverlight sera disponible aussi pour Linux grâce à l'implémentation Moonlight. Lorsque l'on choisit une technologie de développement web, on est confiné à l'intérieur d'un système plus ou moins fermé, à moins d'utiliser massivement les services web, selon la philosophie SOA. Il existe une possibilité d'interopérabilité entre le monde DotNet et le monde Java (voir ici), mais en général il s'agit plus d'une contrainte héritée des systèmes existants que d'un choix de conception.
Cependant, le portage d'une application sous Mono requiert une sérieuse réécriture du code, de façon à s'affranchir des technologies trop spécifiques au monde Microsoft. Par exemple, l'accès aux données via OleDb n'est pas encore supporté par Mono (c'est logique puisque OleDb s'appuie sur la couche COM/ActiveX, propre à Windows), ce qui signifie que l'on ne peut pas se connecter (à ma connaissance) à une base Access en passant par Mono.
La première étape effectuée pour le remplacement d'OWC est d'avoir encapsulé toute l'interface du tableur et du graphe OWC dans deux classes, ucTableur et ucGraphe (uc pour user control, ce sont des classes DotNet adaptateurs ou "wrappers"). Ces deux classes évitent de disséminer du code spécifique partout dans l'application (lequel code doit souvent être compilé dans un mode plus lâche, moins typé : mode Strict désactivé par exemple pour les contrôles ActiveX). En outre on peut y placer le code spécifique lié aux bugs comme par exemple la gestion du séparateur décimal, ou encore pour gérer le remplissage rapide d'une liste via un RecordSet AdoDb. Ainsi on prépare le code pour une future évolution.
Voici les tests que j'ai réalisés en l'occurrence avec le composant Open Source XmlSS et avec le composant SSGear :
Ce composant permet de lire des fichiers Excel au format xml (au lieu de html pour OWC), c'est un composant gratuit avec le code source VB.Net.
Il gère les méthodes WorksheetView.BeginUpdate et .EndUpdate ce qui permet de mettre à jour un grand nombre de cellules avant de rafraichir l'affichage, ce que ne permet pas vraiment les contrôles ActiveX comme OWC : du coup, l'affichage est spectaculairement plus rapide qu'OWC lors d'un grand nombre de cellules à mettre à jour.
Toutefois il reste des limitations :
- Le format d'affichage des cellules Excel (par ex. le format de précision) dans le fichier xml n'est pas pris en compte par le composant (il est cependant conservé dans le fichier xml, lorsqu'on ouvre à nouveau le fichier sous Excel : on pourrait donc lire ce format depuis le code source) ; la solution provisoire est d'afficher 2 décimales pour les réels ou sinon effacer ",00" à la fin pour les entiers ;
- Les formules ne sont pas gérées : il faut refaire les calculs dans le code ;
- Modèle de liste : il faut créer des lignes vides si elles ne sont pas dans le modèle : les modèles doivent réserver de la place car l'ajout de ligne ne fonctionne pas : c'est gênant pour les listes dans lesquelles le nombre d'éléments n'est pas connu à l'avance ;
- Les couleurs ne sont pas les mêmes que celles d'OWC : une correspondance devra être effectuée ;
- Pas de gestion des graphiques OWC : il faudra donc utiliser un autre composant DotNet pour refaire les graphiques qui fonctionnaient en OWC (ou sinon conserver OWC pour l'affichage des graphiques).
Ces défauts pourraient éventuellement être corrigés, car le code source est disponible ici en téléchargement (le projet est en "stand-by" depuis 2004 : l'auteur ne l'a pas fait évolué, et a maintenant d'autres priorités) :
www.codeproject.com/vb/net/xmlsscp.asp
Le composant tableur SpreadsheetGear est un composant DotNet payant compatible avec les classeurs Excel.
Il est également très rapide (car on peut appliquer les optimisations d'affichage DotNet, ce qui est très limité avec les contrôles ActiveX) : Cette fois le format Excel est directement supporté, pas besoin de convertir un classeur en html ou en xml, et Excel 2007 est même supporté aussi en partie.
Les graphiques liés sont également supportés (en 2D, mais pas en 3D), ce qui est remarquable, car OWC ne le fait pas : avec OWC on est obligé de construire des graphiques par le code, l'intégration DotNet de SSGear va donc beaucoup plus loin que Microsoft sur ses propres produits ! (ils ont réussi ce que Microsoft n'a pas voulu faire : une version pure DotNet d'OWC). Les fonctionnalités qui ne sont pas supportées ne sont pas affichées (par ex. les graphiques en 3D) : cela signifie que le composant interprète le contenu du classeur, la démo présente même une petite application qui ressemble à ce que pourrait être une version légère d'Excel, qui ne pèse que 8 Ko (mais la dll principale fait près de 3 Mo) : SpreadsheetGearForWindows.exe
Il n'y a pas d'installation à faire, c'est une simple dll à distribuer avec l'exécutable, comme n'importe quelle dll DotNet (elle est un peu volumineuse mais on peut l'installer à un endroit unique une fois pour toute sur chaque poste si on veut, un peu comme un contrôle ActiveX, via l'utilitaire gacutil.exe).
Les formules sont supportées aussi, ainsi que les commentaires qui apparaissent comme des info-bulles, comme sous Excel (mais dans ce cas il faut éviter de couper l'affichage avec un volet figé). On peut ajouter des boutons cliquables, des dessins Excel (mais cette fois pas directement depuis le classeur Excel, par le code seulement).
Il fonctionne aussi en ASP.Net, c'est à dire sur un serveur web qui produit des classeurs Excel à la volée : les exemples de démonstration ne sont que des fichiers téléchargés, il n'existe pas à ma connaissance un mode interaction dans un navigateur (il y a toutefois une démo de génération de graphique à la volée, en mode client-serveur ASP.Net).
Il y a un inconvénient, il est entièrement vectoriel : c'est donc un peu flou (comme IE7, Vista et le prochain Visual Studio 2010), mais le zoom est possible (par ex. avec la molette + touche ctrl, ou par le code), et plus la résolution de l'écran est grande, moins le flou devrait se faire sentir (cela concerne surtout la résolution de base 1024 x 768).
Note : On peut régler le flou des polices vectorielles vista ici, mais il est difficile d'arriver à un résultat aussi net et homogène que l'affichage historique de Windows (dans la résolution de base 1024 x 768 sur un écran LCD en tout cas) :
www.microsoft.com/typography/cleartype/tuner/tune.aspx
(cela n'a pas d'impact sur le contenu du tableur SSGear, ni sur le contenu du tableur Excel 2007, qui gèrent indépendamment leur propre affichage, cela agit seulement sur les menus et les autres contrôles de toutes les applications sous Vista)
La gestion des graphiques devrait permettre de refaire l'équivalent des graphiques d'OWC, mais les couleurs ne sont pas les mêmes : une correspondance devra être effectuée. Les graphiques liés montrent que les possibilités sont riches, mais la programmation est sensiblement différente de celle d'OWC (je n'ai pas encore réussi à fixer une taille de graphique qui peut se redimensionner dans son cadre). Sinon, le cas échéant, on peut éventuellement conserver OWC pour la partie graphique de l'application.
Ce composant est payant (une seul fois 1000 $, ensuite on peut distribuer la dll comme on veut avec l'application, il est livré sans son code source, et est bien protégé contre le désassemblage et la rétro-conception, pour ceux qui penseraient à utiliser Reflector). Le composant peut être testé gratuitement pendant 1 mois ici :
Silverlight est une machine virtuelle ou plugin pour navigateur internet, qui permet de développer des applications web riches dans un moteur de rendu vectoriel. Les applications Silverlight utilisent le format xaml : il s’agit d’un fichier xml pour décrire l’interface, qui est dissociée de l’application : l’avantage est de pouvoir faire développer l’interface des applications par des professionnels du graphisme tandis que l’application elle-même sera développée par des informaticiens : le fichier xaml contient des balises imbriquées représentant la complexité d’une scène, et des événements sont associés par nommage à des éléments de l’interface, tels que des boutons. De la sorte, il est possible de changer complètement l’habillage d’une application sans pour autant toucher au code de l’application qui gère les événements. L’interface étant essentiellement vectorielle (on ne parle plus de pixel), on peut zoomer en fonction de la résolution de l’écran sur lequel on consulte la page web. Les applications Silverlight s’exécutent du coté client du navigateur (comme les applications flash d’adobe), et non plus en mode client-serveur comme les applications ASP .Net (pour lesquelles il faut un serveur pour les héberger, qui peut utiliser une base de données). Si une application Flash ou Silverlight diffuse par exemple de la vidéo, il faut toutefois faire héberger un service de diffusion de vidéo, mais le mode client-serveur est facultatif et non obligatoire comme en ASP .Net.
Les applications Silverlight sont développées en DotNet, mais elles ne supportent qu'un sous-ensemble réduit de la plate-forme DotNet, de sorte que la migration en Silverlight d'une application client riche Windows n'est pas garantie : la réécriture de l'application restreinte à un sous-ensemble peut être difficile voir impossible en l'état actuel des fonctionnalités de Silverlight.
Lorsque l'habillage d'une application est principalement décrite sous forme de feuilles Excel, il peut être intéressant d'examiner si Silverlight peut afficher directement une feuille Excel et gérer les événements associés à un tableur, comme le clic sur une cellule. Voyons les différentes possibilités envisageables :
Dans l'article suivant est décrit un procédé permettant de convertir un graphique Excel simple en une application Silverlight interactive :
www.wpf-graphics.com/HowTo_Sl_Excel.aspx
Le résultat est assez convainquant sur le principe, qui apparait assez simple : il s'agit de récupérer le code xaml correspondant au graphe via le convertisseur Paste2Xaml :
www.wpf-graphics.com/SilverlightPage.aspx?xap=SilverlightExcel.xap
L'interaction est obtenue par un procédé qui commence à compliquer un tout petit peu les choses : il faut renommer chaque élément du graphe pour pouvoir ensuite ajouter la gestion de l'interactivité de ces éléments...
L'imprimante virtuelle XPS est la généralisation du procédé précédant à toute application qui imprime quelque chose, via le pilote d'imprimante virtuelle "Microsoft XPS Document Writer" (XPS signifie "XML Paper Specification"). Celui-ci est un complément gratuit de Microsoft Office 2007 : Enregistrement en PDF ou XPS dans Microsoft.
Dans l'article suivant est décrit comment convertir n'importe quoi en xaml, via ce principe :
http://iaci.ro/2008/06/29/how-to-convert-anything-to-xaml
Il y est indiqué comment produire un fichier xaml (XPS est basé sur xaml) : hélas il est souvent difficile d'exploiter directement les fichiers produits car de nombreuses balises ne sont pas compatibles avec le xaml compris par Silverlight (par exemple les balises pour décrire les polices de caractères utilisées dans un classeur Excel). Dans l'exemple du graphique Excel, on utilise un convertisseur avec l'objectif de se concentrer sur l'essentiel du contenu xaml, le résultat est simple mais limité. Si on veut généraliser le principe, on dépasse rapidement la compatibilité de Silverlight. D'une manière générale, la représentation xaml d'une scène ordinaire est relativement complexe, et seul un outil dédié (et payant) permet de concevoir des interfaces d'application dont les balises peuvent être associées facilement à des événements Silverlight. En l'occurrence, l'outil préconisé par Microsoft est Expression Blend. Pour le moment, l'idée de récupérer du code xaml apparait intéressante mais difficilement exploitable pour des modèles Excel quelconques.
Une autre solution serait de voir s'il est possible de compiler le composant XmlSS en Silverlight :
Il y a une forte dépendance du code source à la hiérarchie WinForm de la plateforme DotNet : cette partie de la plateforme n'est pas disponible pour les sous-ensembles web tel que Silverlight : on ne peut donc pas compiler le code source dans une application Silverlight s'exécutant au sein d'une page web coté client.
On peut essayer de reprogrammer cette partie, mais c'est une tache probablement ardue, par exemple ArrayList de System.Collections est dans mscorlib.dll est introuvable en Silverlight. Cependant, on peut facilement le remplacer par System.Collections.Generic.List<T> (l'utilisation des génériques simplifie énormément la programmation, c'est une bonne chose d'avoir abandonné toutes les librairies historiques de Microsoft de façon à ce que le plug-in Silverlight soit le plus léger possible).
En revanche, la hiérarchie System.Drawing n'est pas disponible non plus (selon la logique du tout vectoriel qui prévaut dans Silverlight), et là c'est carrément un changement radical de programmation : la réécriture du composant représente un sérieux challenge.
Une version Silverlight est à l'étude en priorité, mais aucune date n'est fixée pour le moment (le succès n'est pas garanti, car le sous-ensemble DotNet web/client est assez restreint par rapport à la plateforme DotNet complète). Cependant les chances de succès sont plus élevées qu'avec le composant XmlSS, car SSGear est déjà entièrement vectoriel, et une équipe de développeurs est déjà sur le sujet.
Pour des applications Windows, OWC peut dors et déjà être remplacé dans des scénarios où le gain de performance est intéressant. Au besoin, le reste des fonctionnalités manquantes peut être complétées, par exemple la gestion des couleurs ou des bordures. En ce qui concerne les graphiques, mieux vaut conserver OWC. Si on veut conserver toutes les fonctionnalités tout en allant vite dans certain cas, il est possible de modifier la classe adaptateur pour gérer deux types de tableur à la fois, que l'on pourrait choisir à la compilation, ou bien au démarrage de l'application via un paramètre utilisateur, ou mieux encore à la volée avec un bouton bascule.
Pour des applications Web, Silverlight est actuellement le système le plus proche, en terme de programmation, de la conception d'application Windows, surtout en DotNet : les connaissances peuvent donc être réutilisées en grande partie (tandis que la programmation ASP .Net requiert une nouvelle expérience de programmation). Dans le fonctionnement de base de Silverlight, il est tout à fait possible d'encapsuler les données avec l'application, pour y accéder simplement via un lien Internet. Les données peuvent par exemple provenir d'un fichier xml compressé (lequel pourra être décompressé via la librairie SharpZipLib pour Silvelight) : dans ce cas de figure, rien n'est besoin d'être hébergé dynamiquement, comme une base de données, tous les fichiers de l'application sont simplement hébergés en mode statique (par un simple transfert FTP, ce qui peut être automatisé).
Il existe aussi des composants Javascript, tel que TreeGrid, qui sont conçus pour fonctionner en Html dans le navigateur, en mode client serveur comme ASP .Net ou PHP, ou bien directement depuis un CD-Rom, les données devant être au format xml. D'une manière générale, les possibilités sont quasi infinies en mode client serveur, mais le style de programmation est tout aussi varié, et pas toujours aussi optimal en terme de facilité de développement et maintenance du code source, que peut l'être le développement DotNet pour Windows.
Delivering
Spreadsheet Capabilities Across Platforms By Bill Albing
www.codeproject.com/KB/showcase/farpoint.aspx
- Test du composant tableur SpreadsheetGear ;
- Composant XmlSS : Gestion du double-clic, gestion de l'écriture de plusieurs cellules à la fois (équivalent de la méthode OWC ParseText), optimisation de l'affichage avec WorksheetView.BeginUpdate et .EndUpdate, exception Argument_AddingDuplicate__ désactivée dans XmlSS.Utilities.IntKeyHashtable.insert, gestion du séparateur décimal (avant seul le point décimal était géré, voir les fonctions iConv et rConvStrEnReel dans XmlSSWorkbookFactory), migration et nettoyage du code en VB 2008 sans warning (chercher 'Patrice' pour trouver toutes les modifs dans le code) ;
- Bug lenteur OWC11 : Parfois l'instruction .ActiveSheet.Cells.ClearContents() peut prendre 1 seconde au lieu de quelques millisecondes, mais on peut la remplacer par .ActiveSheet.Cells.Value = "" ; en fait cela se produit aussi sur des fonctions comme ParseText, et seulement s'il n'y a qu'une seule ligne, à partir de 2 lignes cela ne se produit plus :
.ActiveSheet.Range(sPlage).ParseText(sbValeurs.ToString, vbTab)
- Graphiques histogrammes cumulés en OWC 10 et 11 : le type OWC11.ChartChartTypeEnum.chChartTypeColumnStacked (1) doit maintenant s'appliquer au graphique entier et non plus à chaque courbe du graphique (comme cela suffisait en OWC 9) ;
- Classes et modules utilitaires mis à jour ;
- Gestion Windows Vista : passage en OWC 11 (simplification de switch de version OWC) ;
- Amélioration du modèle html : on peut maintenant trier chaque champ correctement, y compris le champ Date ;
- Gestion simplifiée des paramètres de la configuration via : My.Settings.MonParametre = xxx (la sauvegarde du mode plein écran fonctionne bien maintenant) ;
- Amélioration du code : Try Catch au lieu de On Error... ;
- Passage en VB9/2008.
- Classe ucTableur pour gérer OWC 9 et 10 au choix ;
- Mode lecture seule global au niveau de la classe ucTableur ;
- Gestion des événements en DotNet pour OWC 10 ;
- Démo ODBC pour charger le contenu d'une source ODBC externe (un fichier Excel par exemple) ;
- Si OWC n'est plus inscrit dans la base de registre, revérification des composants au prochain redémarrage ;
- Gestion du séparateur décimal : activé ;
- Modèle avec volet figé pour que les entêtes des colonnes restent toujours visibles ;
- Correction des bugs de formatage OWC 9 (date et catégorie avec -) ;
- Export Excel et Word, avec ou sans modèle prédéfini ;
- Définition de la plage visible restreinte à la plage des données effective ;
- Démo comportant un lien hypertexte.
- Optimisation du chargement des données : requête en lecture seule et en avant seulement :
oConn.Mode = adModeRead
oRq.CursorType = adOpenForwardOnly
- Déverrouillage du tableur pour pouvoir trier, filtrer... :
oXL.ActiveSheet.Protection.Enabled = False
- AfficherMsgErreur : simplification ;
- ADO en Liaison tardive pour ne plus dépendre de la version d'ADO installée, voir cependant en DotNet ;
- Vérification de la présence d'OWC et d'ADO avant d'afficher la feuille VB6, possibilité d'installation le cas échéant : voir les limitations ;
- Test OWC 10 et 11 : voir les limitations ;
- Version en VB .Net : voir les limitations.
- C:\Program Files\Fichiers communs\Microsoft Shared\Web Components\11\1033 (11 pour la version Office System = 2003, ou bien 10 pour XP, Fichiers communs ou bien Common Files)
OWCRCH11.chm - Charts : Graphiques
OWCRDP11.chm - Data Access : Accès aux données
OWCRPL11.chm
- Pivot Table : Table pivot
OWCRSS11.chm - Spreadsheet : Tableur
OWCVBA11.chm - Modèle objet
- Le forum officiel d'OWC : microsoft.public.office.developer.web.components
- Microsoft
Office 2000 Web Components White Paper :
http://office.microsoft.com/Downloads/2000/Owcwp.aspx
- HOW
TO: Find Office Web Components (OWC) Programming Documentation and Samples
http://support.microsoft.com/default.aspx?scid=kb;EN-US;319793
- Office
XP Web Component Toolpack
- Office
XP PIA
http://support.microsoft.com/kb/328912/fr
- Access
2002 Enterprise Developer's Handbook
Chapter
12: Using the Office Web Components
http://msdn2.microsoft.com/en-us/library/aa188213(office.10).aspx
- OWC
Roadmap
http://blogs.msdn.com/excel/archive/2006/07/17/668544.aspx
- MONO:
an alternative for the .NET framework
www.codeproject.com/cpnet/mono-merta.asp
www.mono-project.com/Main_Page
- Visual
MainWin
http://dev.mainsoft.com/Default.aspx?tabid=29
- Grasshopper
2.0 Technology Preview: Code .NET 2.0, Build Java, Run Linux
www.codeproject.com/showcase/JMSCSharpNew.asp
- www.codeproject.com/useritems/another_graphic_engine.asp
- www.codeproject.com/cs/miscctrl/GraphComponents.asp
- www.codeproject.com/csharp/julijanpiechart.asp
- www.codeproject.com/cs/miscctrl/PieChart.asp
- www.codeproject.com/csharp/zedgraph.asp
- www.codeproject.com/cs/miscctrl/CS3DCharting.asp
- www.carlosag.net/Tools/WebChart/Default.aspx
- www.3dman.org/chart/ : DaveChart
- Composant tableur : www.codeproject.com/vb/net/xmlsscp.asp
- Generating
Excel(XML Spreadsheet) in C#
www.codeproject.com/office/excelxmlspreadsheet.asp
- www.codeproject.com/aspnet/ExcelShtAndChrt-In-aspx.asp
- www.codeproject.com/csharp/ChartOWC.asp
- Excel
Reader : Read Excel files in pure C# without interop
www.codeproject.com/office/ExcelReader.asp
- How
to Integrate Excel in a Windows Form Application using the WebBrowser
Another
approach to integrate Office documents in your Windows C# .NET applications
www.codeproject.com/useritems/Embedding_Excel.asp
- www.codeproject.com/aspnet/DataGridExportToExcel.asp
équivalent : www.vbfrance.com/code.aspx?ID=32896
- Attacher Word directement dans l'appli :
www.codeproject.com/office/WordInDotnet.asp
- www.codeproject.com/useritems/OfficeVersion.asp
- Late
Bound ActiveX loading
www.codeproject.com/useritems/Late_Bound_ActiveX.asp
www.codeproject.com/csharp/LingeringCOMObjects.asp : ActiveX en DotNet
- SafeCOMWrapper
- Managed Disposable Strongly Typed safe wrapper to late bound COM
www.codeproject.com/csharp/safecomwrapper.asp
- Dynamically
adding ActiveX controls in managed code
www.codeproject.com/dotnet/AxForms.asp
- How
To Get Properties and Methods in Late Binding COM-Apps Like Excel
www.codeproject.com/useritems/How2LateBinding.asp
- www.codeproject.com/dotnet/DeployingFrameworkMdac.asp
- Bootstrapper : permet de tout installer depuis le msi :
- ADODB
serialization : How to serialize and deserialize an ADODB Recordset
www.codeproject.com/useritems/RecordsetSerializer.asp
- ODBCDotNet : Extraire des requêtes ODBC dans un tableau de tableaux de String
http://patrice.dargenton.free.fr/CodesSources/ODBCDotNet.html
- Voir aussi : http://patrice.dargenton.free.fr/dvdclass/index.html
Matrice des identifiants globaux (GUID) d'OWC 10 à utiliser
suivant les versions d'Internet Explorer :
|
Versions IE / OWC 10 |
Dernier OWC 10 SP3 |
Ancien OWC 10 pré-SP3 |
|
IE6x |
Utiliser l'ancien ou le nouveau GUID |
Utiliser uniquement l'ancien GUID |
|
IE5x |
Utiliser uniquement le nouveau GUID |
Utiliser uniquement l'ancien GUID |
Anciens GUID pour OWC 10 : version 2621 (2001)
Spreadsheet 0002E551-0000-0000-C000-000000000046
PivotTable 0002E552-0000-0000-C000-000000000046
DataSourceControl 0002E553-0000-0000-C000-000000000046
Chart 0002E556-0000-0000-C000-000000000046
Nouveaux GUID pour OWC 10 : 6619 (2004), 6765 (2005)
Spreadsheet 0002E541-0000-0000-C000-000000000046
Chart 0002E546-0000-0000-C000-000000000046
PivotTable 0002E542-0000-0000-C000-000000000046
DSC 0002E543-0000-0000-C000-000000000046
CLSID:
{0002E530-0000-0000-C000-000000000046}
ProgID:
OWC.DataSourceControl.9
CLSID:
{0002E510-0000-0000-C000-000000000046}
ProgID:
OWC.Spreadsheet.9
CLSID:
{0002E500-0000-0000-C000-000000000046}
ProgID:
OWC.Chart.9
CLSID:
{0002E520-0000-0000-C000-000000000046}
ProgID:
OWC.PivotTable.9
CLSID: {0002E553-0000-0000-C000-000000000046}
ProgID:
OWC10.DataSourceControl.10
CLSID:
{0002E551-0000-0000-C000-000000000046}
ProgID:
OWC10.Spreadsheet.10
CLSID: {0002E556-0000-0000-C000-000000000046}
ProgID:
OWC10.ChartSpace.10
CLSID:
{0002E552-0000-0000-C000-000000000046}
ProgID:
OWC10.PivotTable.10
CLSID:
{0002E55b-0000-0000-C000-000000000046}
ProgID:
OWC11.DataSourceControl.11
CLSID:
{0002E559-0000-0000-C000-000000000046}
ProgID:
OWC11.Spreadsheet.11
CLSID:
{0002E55d-0000-0000-C000-000000000046}
ProgID:
OWC11.ChartSpace.11
CLSID:
{0002E55A-0000-0000-C000-000000000046}
ProgID:
OWC11.PivotTable.11
- How
To Call CLSID And ProgID Related COM APIs in Visual Basic
ProgIDFromCLSID: To retrieve a ProgID with a given CLSID
http://support.microsoft.com/kb/183544/en-us
Voici la liste des liens issus du livre "The Microsoft Office Web Components Black Book with .NET" (avec l'aimable autorisation d'Alvin Bruney, son auteur ; note : quelques liens cassés ont été corrigés) :
- http://support.microsoft.com/default.aspx?scid=kb;en-us;555094
- http://support.microsoft.com/kb/q243006/
- http://support.microsoft.com/kb/555094/en-us
- http://support.microsoft.com/default.aspx?scid=kb;en-us;828950
- http://support.microsoft.com/kb/q231094/
- http://support.microsoft.com/default.aspx?scid=kb;EN-US;244049
- http://support.microsoft.com/?id=288907
- http://support.microsoft.com/default.aspx?scid=kb;en-us;Q286317
- Office
XP Tool: Web Components : OWC10.exe
- www.microsoft.com/technet/security/bulletin/MS02-044.mspx
- http://support.microsoft.com/kb/264096/en-us
- http://support.microsoft.com/default.aspx?scid=kb;EN-US;244049
- http://aspnet.4guysfromrolla.com/articles/080603-1.aspx
- http://msdn.microsoft.com/data/downloads/default.aspx
- www.webtropy.com/articles/art14-2.asp?Interop=OWC
- http://support.microsoft.com/default.aspx?scid=kb;EN-US;286278
- http://support.microsoft.com/default.aspx?scid=kb;EN-US;317316
- http://support.microsoft.com/?id=328275
- http://support.microsoft.com/default.aspx?scid=kb;en-us;555162
- http://support.microsoft.com/kb/319342/EN-US/ VB
- http://support.microsoft.com/kb/319341/EN-US/ C#
- http://support.microsoft.com/kb/319559/EN-US/ Office XP Chart C#
- http://msdn2.microsoft.com/en-us/library/aa155776(office.10).aspx
- www.internetnews.com/bus-news/article.php/3851_1016171
- www.theregister.co.uk/2002/04/09/a_trio_of_msoffice_security/
- Introducing
the Office Web Components
http://msdn2.microsoft.com/en-us/library/aa155782(office.10).aspx
- http://msdn2.microsoft.com/en-us/office/aa905392.aspx
- http://msdn2.microsoft.com/en-us/library/aa166518(office.10).aspx
- www.wimdows.net/articles/article.aspx?aid=15
- http://support.microsoft.com/kb/q256624/
- http://msdn2.microsoft.com/en-us/office/aa905392.aspx
- http://msdn2.microsoft.com/en-us/library/aa166512(office.10).aspx
- www.pcquest.com/content/search/showarticle.asp?artid=43566
- http://support.microsoft.com/kb/316337
- www.eggheadcafe.com/articles/20021220.asp
- http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us
- http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k2/html/odc_acprogpvt.asp
- http://msdn.microsoft.com/library/default.asp?url=/workshop/components/activex/licensing.asp
- http://msdn2.microsoft.com/en-us/library/aa140061(office.10).aspx
- http://msdn2.microsoft.com/en-us/library/aa198515(office.10).aspx
- http://support.microsoft.com/kb/q301582/
- http://support.microsoft.com/kb/q286210/
- http://support.microsoft.com/kb/q302101/
- http://support.microsoft.com/default.aspx?scid=kb;en-us;288739
http://office.microsoft.com/en-us/assistance/HA010345791033.aspx
http://support.microsoft.com/?kbid=298764
- http://support.microsoft.com/default.aspx?scid=kb;EN-US;294798
- http://support.microsoft.com/?id=317630
- http://msdn2.microsoft.com/en-us/library/aa140057(office.10).aspx
- http://support.microsoft.com/kb/235542
- http://msdn2.microsoft.com/en-us/library/aa140057(office.10).aspx
- http://msdn.microsoft.com/msdnmag/issues/03/10/OLAP/
- http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/whypriinterop.asp
- http://support.microsoft.com/?id=315695
- http://office.microsoft.com/en-us/assistance/HP052386071033.aspx
- http://msdn2.microsoft.com/en-us/library/aa163987(office.10).aspx
- http://support.microsoft.com/default.aspx?kbid=286211
- http://msdn2.microsoft.com/en-us/library/aa155723(office.10).aspx
- http://support.microsoft.com/default.aspx?scid=kb;en-us;555094
- www.microsoft.com/office/previous/xp/developer/platform/owcfaq.asp
- http://support.microsoft.com/default.aspx?scid=kb;en-us;243006
- How
To Use the PivotTable Office Web Component with VB
http://support.microsoft.com/default.aspx?scid=kb;en-us;235542
- http://support.microsoft.com/default.aspx?scid=kb;en-us;229577
Si vous avez des informations utiles sur OWC, n'hésitez pas à m'envoyer un mail.