Nous allons dans cet article nous concentrer sur l'installation de composants ActiveX. Pour mieux comprendre les choses, nous nous intéresserons aussi à quelques aspects liés au codage de contrôles ActiveX. Ces installations pourront être faites soit manuellement, soit par l'intermédiaire d'un programme d'installation, soit directement par Internet. Enfin, nous parlerons de quelques problèmes classiques pouvant intervenir lors de ces installations. Mais avant de rentrer sérieusement dans les détails, quelques rappels et précisions seront certainement utiles.
Attention, à la suite de ce document, vous allez être en mesure de pouvoir manipuler les paramètres de sécurité de votre navigateur Internet Explorer. Ces changement pourrons être lourd de conséquence sur vous utilisez ce dernier sur un site cherchant à pirater votre machine. En conséquence, l'auteur de ce document se décharge de toutes responsabilités liées à la lecture de ce document. Il est à la charge de chacun de garantir sa propre sécurité. L'auteur ne pourra en aucun cas être tenu responsable des changements de stratégie de sécurité de votre navigateur.
Une des caractéristiques notable de la plate-forme Windows est quelle propose l'architecture COM (Component Object Model). Cette architecture permet de pouvoir concevoir des composants logiciels (à partir de n'importe quel environnement de développement supportant le modèle COM) pouvant être réutilisés quasiment à l'infini (pour peu qu'ils soient utilisés dans un développement compatible avec le modèle COM).
En fait, COM est une spécification permettant l'appel de méthodes et l'accès à des propriétés d'un objet, à partir de n'importe quel langage de programmation. Là ou la difficulté réside, c'est qu'en fonction d'un langage ou d'un autre (par exemple Visual C++ et Visual Basic), les types de données ne sont pas équivalents (donc une donnée n'occupe pas la même taille) et les paramètres ne sont pas systématiquement passés de manière similaire à la méthode (la fonction si vous préférez). Il fallait donc unifier les choses pour pouvoir piloter du logiciel à partir d'un autre bout de code, non forcément écrit à partir d'un même langage. C'est l'objectif du modèle COM.
Mais attention ! Les composants COM sont compilés : le code source est traduit en langage machine spécifique à une plate-forme donnée (souvent Windows sur processeur Pentium). Ce modèle diffère sensiblement de l'architecture Java ou de la nouvelle architecture .NET (Microsoft). Le code d'un composant COM se trouve sur le disque dans un fichier d'extension .dll (Dynamic Linking Library).
Un contrôle ActiveX est en fait un composant COM. Mais le contrôle ActiveX présente une caractéristique supplémentaire : il se doit d'être visuellement manipulable par un outil d'assemblage de composants. Attention, cela ne veut pas dire qu'un contrôle ActiveX est forcément visuel à l'exécution. Mais il se doit d'être configurable durant les phases de conception est de manière visuelle. A titre d'exemple, on peut citer le contrôle Timer que l'on retrouve par exemple dans l'environnement Visual Basic 6.0. Les captures d'écrans suivantes vous montrent des contrôles, et notamment un Timer, durant les phases de conception et d'exécution (Design Time et Run Time).
| Phase de conception | Phase d'exécution |
|---|---|
|
|
Un contrôle ActiveX est, bien entendu, lui aussi compilé. Son code se trouve sur le disque dans un fichier d'extension .ocx. A quelques détails près, il s'agit d'une DLL.
Qu'il s'agisse de composants COM ou de contrôles ActiveX, ils se doivent tous d'être "enregistrés dans la base de registre Windows" pour pouvoir être utilisés. Cette base de registre permet notamment, pour les composants COM, de mettre en correspondance des identificateurs (pour le composant) avec la localisation physique, sur le disque, du fichier de code correspondant.
Si un composant n'est pas enregistré dans la base, il ne sera pas utilisable au sein de vos programmes. Pour ce faire un outil existe : regsvr32.exe. Nous reviendrons ultérieurement sur la structure de la base de registre, du moins pour la partie utile à l'architecture COM, et sur l'utilisation de l'outil précédemment cité. Notez bien que la base de registre Windows sert aussi pour de nombreuses choses, mais dont nous ne parlerons pas dans ce document.
Un problème pour l'utilisation des composants COM (et donc des contrôles ActiveX) existe lorsque qu'ils sont embarqués au sein d'une page HTML et manipulé via un langage de script quelconque (JScript ou VB Script). En effet, dans le contexte des pages Web, un client demande une page sur un site sans être garant que cette dernière ne va pas endommager sont ordinateur. En effet n'oublions pas qu'un composant COM est en fait une DLL de code natif pouvant faire plus ou moins n'importe quoi.
Le problème soulevé est réel et de nombreux virus actuels sont basés sur des failles de sécurité du modèle COM dans le cadre du WEB. Bien souvent c'est par le biais de mail que vous vous faites infecter : mais n'oubliez pas qu'Internet Explorer (le navigateur de la société Microsoft supportant le modèle COM) est en fait lui même un contrôle ActiveX et qu'il est embarqué dans les outils Outlook et Outlook Express. Désormais, les mails sont des pages Web (en tout cas dans la majorité des cas). D'où, bien entendu la nécessité d'installer des anti-virus sur nos machines.
Dans le but de sécuriser les choses, vous pouvez faire signer votre composant par une entité tierce qui vous délivrera un certificat numérique. Cela ne garantie pas réellement ce que fait le composant, mais qu'il est bien fournit pas la société mentionnée. Dans tous les cas, il est de votre ressort d'avoir confiance en la société vous fournissant le composant. La capture d'écran suivante vous montre ce que vous affiche Internet Explorer lorsque vous tentez de télécharger un composant signé.
 |
La capture d'écran précédente montre un des organismes apte à garantir la provenance d'un contrôle : "VerySign Commercial Software Publishers CA". Vous pouvez au niveau d'Internet Explorer autoriser ou interdire le téléchargement de contrôles non signés ainsi que pour ceux qui sont signés.
De plus, les composants COM peuvent être marqués comme étant sûrs (ou non) pour le scripting dans le cadre du Web. Mais attention cela n'a de sens que pour les composants installés de base sur votre ordinateur. En effet, on peut par Internet downloader d'autres composants, et le développeur du composant peut marquer son composant comme étant sûr, à sa convenance, dans son atelier de développement (comme le montre la capture d'écran suivante). Il est donc nécessaire, au niveau du navigateur, d'aussi sécuriser le téléchargement de composants. Nous reviendrons sur cela ultérieurement.
 |
A titre d'exemple, vous pouvez sous Windows obtenir le composant Calendar (double-cliquez sur l'horloge dans la barre des tâches) : il s'agit d'un contrôle ActiveX installé de base sur l'OS (Operating System) et marqué comme étant sûr pour le scripting vous pouvez donc l'embarquer dans une page Web. Si vous utilisez Internet Explorer vous devriez voir apparaître un calendrier au dessous de ce paragraphe (pas sur Netscape). Par contre, il existe aussi un composant permettant d'accéder au système de fichier de l'ordinateur. Ce composant est bien entendu marqué comme étant non sûr pour le scripting. Malgré cela, si vous changez la sécurité de votre navigateur, vous pouvez permettre son utilisation : mais cela reste à vos risques et périls.
Vous pouvez aussi jouer, au niveau d'Internet Explorer, sur l'exécution (ou la non exécution) des contrôles marqués comme étant sûrs et ceux ne l'étant pas. Nous reviendrons sur ces possibilités ultérieurement.
Afin de mieux comprendre tous les concepts, nous allons coder un contrôle ActiveX minimal. Nous nous servirons de ce dernier pour comprendre et imager tous les concepts présentés dans ce document. Pour coder ce contrôle ActiveX, il nous faut choisir un environnement de développement. Je me propose d'utiliser Visual Basic 6.0. Ce n'est pas lui qui permettra les choses les plus poussées, mais il présente l'avantage d'être très simple à appréhender.
Le but de ce composant est d'afficher une petite horloge numérique que vous allez pouvoir utiliser par la suite dans vos applications, voir dans une page Web. Cette horloge n'exposera aucune propriété, mais disposera malgré tout de deux méthodes permettant l'arrêt et le redémarrage de l'horloge.
Visual Basic permet de créer ce qu'on appelle un groupe de projet. Cela est pour nous très utile : en effet, il nous faut avoir un projet de contrôle ActiveX (pour notre horloge) et un autre projet classique pour tester notre contrôle. La capture d'écran suivante montre le contenu de chacun de nos deux projets.
Notez que les noms du projet ActiveX et du composant seront utiles par la suite. Le projet définit en fait un package de composants. Le package Infini contient qu'un seul et unique composant : le composant Clock. Il est vrai que nous avons ici à faire à un "petit projet" de test. En fait, après compilation, le package va générer un fichier de code machine qui aura donc comme extension .ocx (comme nous l'avons expliqué précédemment).
Le nom du second projet à moins d'importance. Ce projet contient une feuille (une fenêtre) de test dans laquelle a été incorporé un exemplaire de notre contrôle ActiveX.
La topographie du groupe de projet étant faite, intéressons nous maintenant au code de notre contrôle ActiveX. En fait en VB on génère du code de deux manières : graphiquement, via l'éditeur visuel et manuellement via l'éditeur de code. Ce dernier ne montre pas ce qui a été généré visuellement (mais soyez curieux et ouvrez le fichier "Clock.ctl" dans Notepad par exemple - vous comprendrez mieux les choses). Voici donc les deux vues (Visual Basic) possibles du fichier "Clock.ctl".
 |
Option Explicit
Private Sub tmrSeconds_Timer()
lblClock.Caption = Time
End Sub
Private Sub UserControl_Resize()
fraPourFaireBeau.Width = UserControl.Width
fraPourFaireBeau.Height = UserControl.Height
lblClock.Width = UserControl.Width
lblClock.Top = (UserControl.Height - lblClock.Height) / 2 + 100
End Sub
Private Sub UserControl_Show()
tmrSeconds_Timer
End Sub
Public Sub StartTimer()
tmrSeconds.Enabled = True
End Sub
Public Sub StopTimer()
tmrSeconds.Enabled = False
End Sub
|
Une fois le projet codé, il nous faut compiler le projet pour générer le fichier ocx et pour enregistrer le composant dans la base de registre Windows. En effet Visual basic prend à sa charge l'enregistrement du composant, tout du moins sur le poste de développement ! Pour ce faire, allez dans le menu "Fichier", et cliquez sur "Créer Infini.ocx". Le système se charge de faire tout ce qui est nécessaire. A partir de là, vous pouvez utiliser ce composant dans vos développements, et sur ce poste. Vous pouvez télécharger le code de ce composant en activant ce lien. Pour pouvoir exploiter le code il vous faudra avoir l'environnement Visual Basic 6.0 d'installé sur votre machine
Au terme de cette partie, beaucoup de choses ont été faites, et notamment au niveau de la base de registre. Nous allons donc maintenant nous intéresser de plus près à ce qui a été mis en oeuvre au niveau de la base de registre.
Comme nous l'avons dit précédemment, les noms du package et du composant sont utiles : en effet ils sont réutilisés pour générer un identificateur textuel appelé "PROgramatic IDentifier" (ProgId pour les intimes). Cet identificateur est un nom humainement mémorisable, qui a été stocké dans la base de registre. Il suivra toujours le pattern (motif) suivant : NomProjet.NomComposant. Dans notre cas précis, le ProgId de notre composant est "Infini.Clock".
Pour voir le contenu de la base de registre, vous pouvez utiliser un outil nommé "regedit.exe" (REGistry EDITor). Il est fourni de base sur plate-forme Windows. Pour lancez cet outil, affichez en premier la fenêtre Run (appuyez simultanément sur les touches Windows (en bas à droite du clavier - à côté de la touche Ctrl) et R). Y saisir "regedit" puis cliquez sur Ok. L'éditeur de base de registre doit se lancer.
La base de registre Windows est structurée de manière hiérarchique, un peu à l'instar du système de fichiers. Au niveau principal, cinq entrées sont proposées. Seule la première nous intéresse : elle est nommée HKEY_CLASSES_ROOT.
|
Directement sous cette entrée, vous retrouvez de nombreuses sous-entrées. Elles sont de natures plus ou moins diverses. Mais certaines sont constituées de deux noms séparés par un point : se sont tous les ProgIds des composants supportés par votre machines. Recherchons-y le ProgId "Infini.Clock".
|
Ce qu'on remarque c'est qu'en fait le ProgId redirige vers un autre identificateur : un CLSID. En fait le ProgId pose un problème au niveau de l'architecture COM. Il n'y a aucune garantie que cette chaîne de caractères soit unique. Or, au niveau de COM et d'Internet, il faut pouvoir garantir l'unicité du composant. Un autre identificateur est donc requis.
L'identificateur de classe (CLSID - CLaSse IDentifier) est en fait le véritable identificateur de votre composant. Mais je pense qu'on s'accordera à dire qu'il n'est pas franchement mémo-technique (il est affiché dans la capture d'écran précédente). Cette série de caractères a été générée sur le poste de développement que j'ai utilisé lors de la construction de projet. Ce numéro ne changera pas sur votre poste : il est stocké dans le fichier .ocx.
Cet identificateur est théoriquement unique. Il a été généré à partir du numéro MAC de ma carte réseau (qui lui aussi est unique). La conséquence est surprenante : pour développer des composants COM, il vous faut une carte réseau pour garantir l'unicité du CLSID.
Donc une fois que nous avons obtenu le CLSID à partir du ProgId, nous allons rentrer à nouveau dans la base de registre, mais à un noeud différent. En effet, toujours dans HKEY_CLASSES_ROOT, il existe une sous entrée CLSID. Déroulez cette entrée pour voir apparaître la liste de tous les CLSID installés sur votre poste. Recherchez-y votre CLSID (regedit propose une fonctionnalité "Rechercher"). La capture d'écran suivante vous montre quelques informations et notamment la sous entrée InprocServer32 : c'est elle qui contient la localisation du fichier .ocx sur le disque.
|
Nous venons de réaliser le cheminement classique que réalise un programme qui cherche à instancier un composant COM. Via ce cheminement, il sera capable de connaître l'emplacement du fichier de code à charger en mémoire.
Maintenant que nous avons bien cerné ce qui a été fait sur le poste de développement, intéressons-nous aux différents moyens existant pour déployer un contrôle ActiveX. Dans un premier temps nous allons surtout voir comment manuellement installer un contrôle ActiveX.
La première partie semble triviale : il nous faut copier tout le code dont dépend votre contrôle ActiveX. A priori cela a l'air simple : il faut copier l'ocx. Mais tout n'est pas aussi simple. Selon les environnements utilisés, nous pouvons avoir besoin de fichiers supplémentaires, et notamment avec Visual Basic. En effet, pour qu'un programme Visual Basic puisse marcher, il lui faut ce que l'on appelle le Runtime VB (une dll supplémentaire).
Connaître ces dépendances n'est pas toujours chose facile. Pour faciliter les choses, l'environnement de développement Visual Studio propose un outil supplémentaire nommé "Dependency Walker" (pour le localiser, allez dans le menu "Démarrer". Puis trouvez l'entrée "Visual Studio 6.0" ou "Visual Basic 6.0". Il devrait alors y avoir une sous entrée "Outils Microsoft Visual Studio 6.0". Lancez-y le programme "Depends". La capture d'écran qui suit montre les dépendances du fichier "infini.ocx".
|
Si vous analysez l'arborescence, vous devriez remarquer que le fichier "Infini.ocx" dépend du fichier "MSVBVM6.0.dll". Il s'agit du Runtime VB. Ce dernier n'est pas systématiquement installé sur tout poste Windows. Il est donc vital de le copier aussi. Par contre, les fichiers dont dépend le fichier de Runtime ne sont pas à réinstaller. En gros, il s'agit des fichiers principaux de l'architecture Windows (s'ils n'existent pas sur un poste, c'est que ce n'est pas un poste Windows).
Kernel32.dll : contient tout le code du noyau Windows (gestion de la mémoire, ordonnanceur de tâches, ...).
User32.dll : contient tout le code nécessaire pour le gestionnaire de fenêtres Windows.
GDI32.dll (Graphics Device Interface) : contient tout le code
Une fois les différents fichiers copiés sur le poste, il ne vous reste plus qu'à enregistrer le package dans la base de registre. Si le package contient plusieurs composants, ils seront tous enregistrés dans la base. Si vous deviez faire la chose à la main, via "regedit", cela serait ingérable. En effet, il existe plusieurs entrées dans la base qui pointe mutuellement les unes sur les autres (ProgId, ClsId, TypeId, ...).
Heureusement, un petit outil existe dont nous avons déjà un peu parlé : regsvr32.exe. Cet outil se lance à partir d'une console et prend en paramètre la localisation sur le disque d'un fichier ".dll" ou ".ocx". Vous pouvez aussi faire un raccourcit vers ce fichier sur votre bureau : ainsi, vous pourrez faire du drag'n drop pour enregistrer vos composants.
Pour enregistrer notre composant, ouvrez une console et placez-vous dans le répertoire contenant le fichier "infini.ocx". Tapez ensuite la commande suivante : regsvr32 infini.ocx.
Pour désinstaller un composant, la technique est presque la même que pour l'installation, à un détail près : il vous faut aussi ajouter l'option /u pour demander le désenregistrement.
Vous devriez maintenant mieux comprendre pourquoi sous Windows, supprimer le répertoire d'installation d'une application, ne suffit pas pour complément la désinstaller. Il faut aussi nettoyer la base de registre. Les assistants de désinstallation s'en chargent, normalement très bien.
Toutes les étapes que nous venons de voir peuvent être automatisées. Il existe des outils chargés de réaliser toutes ces étapes, et même de fournir les informations utiles à une désinstallation propre. Le pack Visual Studio 6.0 fournit aussi un tel outil : l'assistant d'empaquetage et de déploiement. Au terme de la création du programme d'installation, il vous fournit un fichier "setup.exe", un fichier ".cab" (une archive compressée contenant tout le code utile à votre programme) et un autre fichier de configuration. Le lancement du fichier "setup.exe" aboutit à l'installation de l'application sur le poste et à l'enregistrement de tous les composants COM.
Un composant COM peut aussi se voir installer par le Web. Mais dans ce cas, il s'agira plus précisément d'un contrôle ActiveX. Celui-ci s'insérera dans une page HTML et sera téléchargé directement à partir du réseau, s'il n'est pas déjà présent sur le poste du client. Pour que cela puisse marcher, il faut que la page HTML soit codée pour pouvoir permettre le download et que la stratégie de sécurité du navigateur client soit permissive. Pour ce dernier aspect, vous ne pouvez présager de rien !
|
Donc, comme je vous l'ai dit plus haut, il faut autoriser le téléchargement du contrôle ActiveX. Pour ce faire, il faut modifier le contenu du tag <OBJECT>. Vous pouvez le générer via un outil d'édition de page HTML (Front Page par exemple). Par défaut, celui-ci accepte un paramètre classid : il permet de définir l'identificateur de classe du composant. Il n'est pas conseiller sur Internet d'utiliser le ProgId car on doit garantir l'identification quelque soit la localisation de la machine. |
En rajoutant le paramètre "codebase", vous indiquez à partir de quelle adresse Internet le navigateur peut télécharger le composant, si la machine hôte ne possède pas déjà un composant de ClsId identique à celui exprimé dans la page HTML. Sans ce paramètre, le téléchargement est irréalisable. L'exemple de code suivant montre un exemple de code HTML permettant le download de contrôle ActiveX
<OBJECT classid="CLSID:B3A5F463-EBD7-487E-B737-D2B772908D0F"
codebase="./infini.ocx">
</OBJECT>
|
Une autre possibilité, dérivée de la précédente permet une installation plus judicieuse du contrôle ActiveX. En effet, votre contrôle peut dépendre d'autres fichiers de code. Si ces fichiers ne sont pas aussi copiés, le contrôle ne fonctionnera probablement pas. "L'assistant d'empaquetage et de déploiement", fournit avec notamment Visual Basic, permet de générer un fichier d'extension ".cab" et contenant tous les fichiers nécessaires. En fait, ce fichier est une archive compressée. Dans ce cas le tag OBJECT ne référencera plus le fichier ".ocx" mais l'archive ".cab". Celle-ci est autonome et installe seule tous les fichiers nécessaires.
<OBJECT classid="CLSID:B3A5F463-EBD7-487E-B737-D2B772908D0F"
codebase="./Infini.cab#version=1,0,0,0">
</OBJECT>
|
Mais attention : indiquer au niveau de la page que le contrôle est téléchargeable ne suffit pas forcément ! Il faut aussi garantir que la sécurité du navigateur autorise ce téléchargement et l'exécution sur le poste client.
La sécurité au niveau du navigateur Internet Explorer peut s'avérer subtile a configurer. Déjà vous pouvez configurer les choses pour la zone Internet différemment de la zone Intranet. De plus, pour chaque zone, vous pouvez autoriser ou non différentes choses (download, enregistrement, exécution) en fonction que les contrôles soit sûrs ou non et signés ou non. Soit pas mal de possibilités.
Pour obtenir le panneau de configuration des sécurités sous Internet Explorer, il faut sélectionner l'entrée "Option" dans le menu "Outils". Ensuite, sélectionnez l'onglet "Sécurité". La capture d'écran qui suit montre la boîte de dialogue en question.
Pour changer le niveau de sécurité d'une zone, sélectionner la zone et cliquez sur "Personnaliser". Il faudra, pour permettre l'utilisation du contrôle :
Autoriser le download
Autoriser l'initialisation (enregistrement dans la base de registre)
Autoriser l'exécution
Dans notre cas, le contrôle n'est ni signé, ni marqué comme étant sûr pour le scripting. Plutôt que de carrément autoriser ces différents aspects, vous pouvez demander à ce que vous soyez sollicité pour prendre la décision d'autoriser ou non la chose. La capture d'écran suivante montre ces choix.
Malgré votre vigilance et ce que nous venons de voir, il se peut que parfois les choses ne se passent pas comme prévu. Deux problèmes reviennent fréquemment lors de ce genre de manipulation. Soit le runtime Visual Basic (si vous l'utilisez) n'est pas présent sur le poste client. Soit il peut aussi y avoir une mauvaise configuration au niveau des droits NTFS sur les répertoires, du serveur web, contenant notamment le fichier .ocx.
Dans ce cas, il vous manque au moins une DLL sur le poste client. Il se peut même qu'il vous manque d'autres fichiers (.dll ou .ocx) indépendamment du runtime VB. Utilisez dans ce cas un outil vous montrant les dépendances de votre fichier. L'assistant d'empaquetage et de déploiement et même très certainement la meilleure solution dans ce cas.
Dans ce cas, il se peut que le fichier ".ocx" soit non accessible via le serveur Web. Effectivement, pour exécuter du code sous Windows, il faut obligatoirement y être connecté avec un login et un password. IIS (Internet Information Services) associe fréquemment au compte anonyme le login IUSR_HOSTNAME (ou hostname est le nom du serveur).
Vérifiez alors bien que ce compte utilisateur a accès au fichier requis. Si ce n'est pas le cas, de toute façon, IE vous affiche une page erreur liée à la sécurité. La sécurité NTFS se met en oeuvre via l'explorateur de fichier Windows.
Un dernier problème pouvant survenir lors de l'installation de composant COM, par le biais du navigateur Internet Explorer, tient dans le fait que la variable d'environnement PATH n'est peut être pas correctement positionnée. En effet, le programme "regsvr32.exe" est souvent localisé soit dans le répertoire "System32" (sous le répertoire d'installation de Windows) pour Windows NT, 2000 et XP, soit dans le répertoire "System" pour Windows 95, 98 et Me.
Pour rapidement savoir si vous avez à faire à ce problème, prenez une console DOS. Tapez-y "regsvr32". Si une fenêtre d'aide apparait, tout va bien. Sinon, vous devriez lire une erreur sur la console indiquant que la commande est introuvable. Il vous faudra dans ce dernier cas mettre à jour votre environnement Windows.
Sous Windows 95, 98 ou Me, cette variable d'environnement est définie dans le fichier de démarrage "autoexec.bat". Editez-le et localisez la ligne commençant par "SET PATH=...". Ajoutez-y le chemin d'accès approprié. Notez que le séparateur de répertoire est le caractère point-virgule.
Sous architecture Windows NT, 2000, XP, ce n'est plus le fichier "autoexec.bat" qui définit les variables d'environnement utilisées par le système. Pour pouvoir mettre à jour la variable PATH, la méthode la plus simple consiste à cliquer du bouton droit de la souris sur l'icône "Poste de Travail" placée sur le bureau et de choisir dans le menu les propriétés. Une boîte de dialogue apparait. Choisissez-y l'onglet "Avancé" situé le plus à droite. Vous pouvez à partir de là modifier les choses. Le séparateur de chemin est encore une fois le point-virgule.
L'architecture Windows permet donc de pouvoir coder des composants réutilisables via de nombreux environnements (VB, VC++, VJ++, ... et le Web). Visual Basic, permet de rapidement coder des contrôles ActiveX, même s'il offre moins de possibilités que Visual C++. Une fois le composant près, l'environnement Visual Basic permet de générer le fichier d'extension ".ocx" qui sera utilisé par la suite.
Comme nous l'avons vu, l'architecture COM/ActiveX s'appuie grandement sur la base de registre Windows. Si vous déployez manuellement vos contrôles, l'outil "regsvr32.exe" vous assistera dans cette tâche (ainsi que pour la désinstallation).
Pour pouvoir utiliser ces composants au sein d'un page Web, deux étapes sont nécessaires. Il faut tout d'abord autoriser le téléchargement au niveau du code HTML de la page et vérifier les aspects liés à la sécurité NTFS. Vous êtes, normalement, en mesure de garantir ces points. Par contre, vous ne pouvez pas garantir que les différents navigateurs des postes de vos clients seront bien configurés.
Retour accueil Visual Basic 6.0
Améliorations / Corrections
Vous avez des améliorations (ou des corrections) à proposer pour ce document : je vous remerçie par avance de m'en faire part, cela m'aide à améliorer le site.
Emplacement :
Description des améliorations :