VBXL : Programmation efficace d'Excel en VBA, VB6 et VB .Net

www.vbfrance.com/code.aspx?ID=17783

Documentation : vbxl.html

Code source : VBXL.vbproj.html

Par Patrice Dargenton

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

Composants requis. 3

Limitations. 4

OWC et Windows Vista. 4

OWC et Windows 64 bits. 4

Bugs de formatage. 5

Bug OWC 9 : lenteur sur certaine configuration. 5

Solution palliative au bug de lenteur OWC 9. 5

Licence. 6

L'Enfer des Dll (OWC 9) 7

Distribuer une application VB6 avec OWC.. 8

Tests complémentaires en VB6. 8

Test d'OWC 10 et 11. 8

Test d'OWC Chart 8

Programmation en VB .Net 8

Bugs. 8

Gestion des événements en DotNet pour OWC 10. 8

Fonctionnalités ajoutées dans OWC 10. 9

Procédure pour remplacer le tableur OWC 9 par OWC 10. 9

Liste des bugs OWC 10. 10

Procédure pour remplacer le grapheur OWC 9 par OWC 10. 11

Procédure pour repasser OWC en version 9. 11

Erreur lors de la migration de VS 2003 à VB 2005. 12

Erreur lors de la migration de VB 2005 à VB 2008. 12

Divers. 12

Déplacer les dll dans un sous-dossier de l'application. 13

Composants d'accès aux données : ADO.. 13

Différences entre AdoDb et OleDb. 13

Bug lors d'un copier/coller 14

Bug de lenteur avec OWC 11. 14

Remplacer OWC ?. 14

Les problèmes que posent OWC.. 14

Les solutions envisageables. 14

L'interopérabilité. 15

Le composant Open Source XmlSS.NET Spreadsheet 15

Le composant tableur SpreadsheetGear 16

Silverlight 17

Convertir des fichiers Excel au format xaml 17

L'imprimante virtuelle XPS. 17

Version Silverlight de XmlSS.NET Spreadsheet 18

Version Silverlight de SSGear 18

Conclusion. 18

Autre composant DotNet à tester : Farpoint 19

Historiques des versions. 19

Version 1.04 du 17/08/2009. 19

Version 1.03 du 23/08/2008. 19

Version 1.02 du 28/01/2007 en VB .Net 19

Version 1.01 du 03/04/2004. 20

Version 1.00 du 08/11/2003. 20

Documentation et liens. 20

OWC.. 20

Mono et compagnie. 21

Composants graphiques. 21

Office. 21

ActiveX.. 21

Installation et déploiement 22

Divers. 22

Identifiants des classes (ClsID) et des programmes (ProdID) 22

OWC 9. 22

OWC 10 ancien. 22

OWC 11. 23

Liens tirés de "The Microsoft Office Web Components Black Book with .NET" 23

Chapter 1. 23

Interactive usage. 23

Licensing. 23

Deployment 23

O.W.C. Outside of Internet Explorer 23

Chapter 2. 23

Dynamic Chart Generation. 23

Binding charts to datasources. 24

Null data points. 24

Web Component download. 24

Security vulnerability white paper 24

Chapter 3. 24

Streaming charts to browser 24

Server-side chart generation. 24

Charting with the O.W.C. 24

MDAC 2.5 download. 24

Chapter 4. 24

OWC reference. 24

Interactive charts. 24

OWC limitations. 24

Binding charts to xml datasource. 24

OWC preview.. 24

Chapter 5. 24

Handling events for the O.W.C. 25

Custom drawing. 25

Handling events in windows forms. 25

Office Automation. 25

Chapter 6. 25

OWC vulnerabilities. 25

OWC 9. 25

OWC language reference. 25

Chapter 7. 25

Exporting data. 25

Com Add-Ins with Excel 25

OWC Resources for XP and 2000. 25

OWC object models. 25

Chapter 8. 25

Word integration basics. 25

Convert ADO.NET dataset to ADO recordset 25

Streaming Excel to the browser 26

OWC help and support 26

Chapter 9. 26

Spreadsheet cell linking. 26

Licensing. 26

Excel spreadsheet programming. 26

OWC programming. 26

Chapter 10. 26

Pivot Table Cloned Member issue resolution. 26

Extracting aggregates values. 26

Retrieving filtered members. 26

OWC installation issues. 26

Chapter 11. 26

Pivot Table List View Programming. 26

Pivot Table List in Access form.. 26

Pivot Table rendering. 26

Pivot Table hyperlink support 26

Chapter 12. 26

Creating cubes from relational datasources. 27

Pivot Table code and VB.. 27

OLAP. 27

Registration free COM components. 27

Connecting to XML Web Services. 27

Chapter 13. 27

Add-ins. 27

OWC PIA's. 27

Combination Charts. 27

OWC Book excerpt 27

OWC XML Schemas. 27

Chapter 14. 27

Licensing. 27

OWC and VB.. 27

OWC incorrect help topics. 27

 

 

Composants requis

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.

 

 

Limitations

 

OWC et Windows Vista

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.

 

OWC et Windows 64 bits

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))

 

Bugs de formatage

- 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

 

Bug OWC 9 : lenteur sur certaine configuration

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.

 

Solution palliative au bug de lenteur 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 !

 

Licence

- 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".

 

L'Enfer des Dll (OWC 9)

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).

 

Distribuer une application VB6 avec OWC

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.

 

 

Tests complémentaires en VB6

 

Test d'OWC 10 et 11

- 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.

 

Test d'OWC Chart

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.

 

 

Programmation en VB .Net

 

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").

 

Bugs

- 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 :

 

Gestion des événements en DotNet 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.

 

Fonctionnalités ajoutées dans OWC 10

- 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

 

Procédure pour remplacer le tableur OWC 9 par OWC 10

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 :

 

Liste des bugs OWC 10

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é.

 

Procédure pour remplacer le grapheur OWC 9 par OWC 10

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.

 

Procédure pour repasser OWC en version 9

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

 

Erreur lors de la migration de VS 2003 à VB 2005

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.

 

Erreur lors de la migration de VB 2005 à VB 2008

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 !

 

Divers

- 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).

 

Déplacer les dll dans un sous-dossier de l'application

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.

 

Composants d'accès aux données : ADO

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).

 

Différences entre AdoDb et OleDb

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).

 

Bug lors d'un copier/coller

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

 

Bug de lenteur avec OWC 11

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)

 

 

Remplacer OWC ?

 

Les problèmes que posent OWC

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.

 

Les solutions envisageables

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).

 

L'interopérabilité

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 :

 

Le composant Open Source XmlSS.NET Spreadsheet

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

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 :

www.spreadsheetgear.com

 

Silverlight

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 :

 

Convertir des fichiers Excel au format xaml

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

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 :

 

Version Silverlight de XmlSS.NET Spreadsheet

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.

 

Version Silverlight de SSGear

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.

 

Conclusion

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.

 

Autre composant DotNet à tester : Farpoint

Delivering Spreadsheet Capabilities Across Platforms By Bill Albing

www.codeproject.com/KB/showcase/farpoint.aspx

 

 

Historiques des versions

 

Version 1.04 du 17/08/2009

- 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) ;

 

Version 1.03 du 23/08/2008

- 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.

 

Version 1.02 du 28/01/2007 en VB .Net

- 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.

 

Version 1.01 du 03/04/2004

- 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.

 

Version 1.00 du 08/11/2003

 

 

Documentation et liens

 

OWC

- 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

  www.microsoft.com/downloads/details.aspx?FamilyID=BEB5D477-2100-4586-A13C-50E56F101720&displaylang=en

 

- 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 et compagnie

- 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

 

Composants graphiques

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

 

Office

- 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

 

ActiveX

- 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

 

Installation et déploiement

www.codeproject.com/dotnet/DeployingFrameworkMdac.asp

 

- Bootstrapper : permet de tout installer depuis le msi :

  www.microsoft.com/downloads/details.aspx?displaylang=fr&FamilyID=627921a0-d9e7-43d6-a293-72f9c370bd19

 

Divers

- 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

 

Identifiants des classes (ClsID) et des programmes (ProdID)

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

 

OWC 9

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

 

 

OWC 10 ancien

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

 

OWC 11

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

 

 

Liens tirés de "The Microsoft Office Web Components Black Book with .NET"

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) :

 

 

Chapter 1

 

Interactive usage

http://support.microsoft.com/default.aspx?scid=kb;en-us;555094

 

Licensing

http://support.microsoft.com/kb/q243006/

http://support.microsoft.com/kb/555094/en-us

 

Deployment

http://support.microsoft.com/default.aspx?scid=kb;en-us;828950

 

O.W.C. Outside of Internet Explorer

http://support.microsoft.com/kb/q231094/

 

 

Chapter 2

 

Dynamic Chart Generation

http://support.microsoft.com/default.aspx?scid=kb;EN-US;244049

 

Binding charts to datasources

http://support.microsoft.com/?id=288907

 

Null data points

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q286317

 

Web Component download

- Office XP Tool: Web Components : OWC10.exe

www.microsoft.com/downloads/details.aspx?FamilyID=982B0359-0A86-4FB2-A7EE-5F3A499515DD&displaylang=EN

 

Security vulnerability white paper

www.microsoft.com/technet/security/bulletin/MS02-044.mspx

 

 

Chapter 3

 

Streaming charts to browser

http://support.microsoft.com/kb/264096/en-us

 

Server-side chart generation

http://support.microsoft.com/default.aspx?scid=kb;EN-US;244049

 

Charting with the O.W.C.

http://aspnet.4guysfromrolla.com/articles/080603-1.aspx

 

MDAC 2.5 download

http://msdn.microsoft.com/data/downloads/default.aspx

 

 

Chapter 4

 

OWC reference

www.webtropy.com/articles/art14-2.asp?Interop=OWC

 

Interactive charts

http://support.microsoft.com/default.aspx?scid=kb;EN-US;286278

 

OWC limitations

http://support.microsoft.com/default.aspx?scid=kb;EN-US;317316

 

Binding charts to xml datasource

http://support.microsoft.com/default.aspx?scid=http:// support.microsoft.com:80/support/kb/articles/q286/2/12.asp&NoWebContent=1

 

OWC preview

http://msdn.microsoft.com/library/default.asp?url=/seminar/mmcfeed/mmcdisplayfeed.asp?lang=en&product=103335&audience=100402

 

 

Chapter 5

 

Handling events for the O.W.C.

http://support.microsoft.com/?id=328275

 

Custom drawing

http://support.microsoft.com/default.aspx?scid=kb;en-us;555162

 

Handling events in windows forms

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#

 

Office Automation

http://msdn2.microsoft.com/en-us/library/aa155776(office.10).aspx

 

 

Chapter 6

 

OWC vulnerabilities

www.internetnews.com/bus-news/article.php/3851_1016171

www.theregister.co.uk/2002/04/09/a_trio_of_msoffice_security/

 

OWC 9

- Introducing the Office Web Components

  http://msdn2.microsoft.com/en-us/library/aa155782(office.10).aspx

 

 

OWC language reference

http://msdn2.microsoft.com/en-us/office/aa905392.aspx

http://msdn2.microsoft.com/en-us/library/aa166518(office.10).aspx

 

 

Chapter 7

 

Exporting data

www.wimdows.net/articles/article.aspx?aid=15

 

Com Add-Ins with Excel

http://support.microsoft.com/kb/q256624/

 

OWC Resources for XP and 2000

http://msdn2.microsoft.com/en-us/office/aa905392.aspx

 

OWC object models

http://msdn2.microsoft.com/en-us/library/aa166512(office.10).aspx

 

 

Chapter 8

 

Word integration basics

www.pcquest.com/content/search/showarticle.asp?artid=43566

 

Convert ADO.NET dataset to ADO recordset

http://support.microsoft.com/kb/316337

 

Streaming Excel to the browser

www.eggheadcafe.com/articles/20021220.asp

 

OWC help and support

http://support.microsoft.com/default.aspx?scid=fh;en-us;kbhowto&sd=gn&ln=en-us

 

 

Chapter 9

 

Spreadsheet cell linking

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnacc2k2/html/odc_acprogpvt.asp

 

Licensing

http://msdn.microsoft.com/library/default.asp?url=/workshop/components/activex/licensing.asp

 

Excel spreadsheet programming

http://msdn2.microsoft.com/en-us/library/aa140061(office.10).aspx

 

OWC programming

http://msdn2.microsoft.com/en-us/library/aa198515(office.10).aspx

 

 

Chapter 10

 

Pivot Table Cloned Member issue resolution

http://support.microsoft.com/kb/q301582/

 

Extracting aggregates values

http://support.microsoft.com/kb/q286210/

 

Retrieving filtered members

http://support.microsoft.com/kb/q302101/

 

OWC installation issues

http://support.microsoft.com/default.aspx?scid=kb;en-us;288739

 

 

Chapter 11

 

Pivot Table List View Programming

http://office.microsoft.com/en-us/assistance/HA010345791033.aspx

 

Pivot Table List in Access form

http://support.microsoft.com/?kbid=298764

 

Pivot Table rendering

http://support.microsoft.com/default.aspx?scid=kb;EN-US;294798

 

Pivot Table hyperlink support

http://support.microsoft.com/?id=317630

 

 

Chapter 12

 

Creating cubes from relational datasources

http://msdn2.microsoft.com/en-us/library/aa140057(office.10).aspx

 

Pivot Table code and VB

http://support.microsoft.com/kb/235542

 

OLAP

http://msdn2.microsoft.com/en-us/library/aa140057(office.10).aspx

http://msdn.microsoft.com/msdnmag/issues/03/10/OLAP/

 

Registration free COM components

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/whypriinterop.asp

 

Connecting to XML Web Services

http://support.microsoft.com/?id=315695

 

 

Chapter 13

 

Add-ins

http://office.microsoft.com/en-us/assistance/HP052386071033.aspx

 

OWC PIA's

http://msdn2.microsoft.com/en-us/library/aa163987(office.10).aspx

 

Combination Charts

http://support.microsoft.com/default.aspx?kbid=286211

 

OWC Book excerpt

http://msdn2.microsoft.com/en-us/library/aa155723(office.10).aspx

 

OWC XML Schemas

www.microsoft.com/downloads/details.aspx?FamilyId=FE118952-3547-420A-A412-00A2662442D9&displaylang=en

 

 

Chapter 14

 

Licensing

http://support.microsoft.com/default.aspx?scid=kb;en-us;555094

http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/q288/7/29.asp&NoWebContent=1

www.microsoft.com/office/previous/xp/developer/platform/owcfaq.asp

http://support.microsoft.com/default.aspx?scid=kb;en-us;243006

 

OWC and VB

- How To Use the PivotTable Office Web Component with VB

  http://support.microsoft.com/default.aspx?scid=kb;en-us;235542

 

OWC incorrect help topics

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.