Gare à la casse et sus à la migraine ! Dans cette rapide présentation, on va voir quelques (je dis bien quelques) éléments permettant d’aller plus loin avec VB. En fait, on va voir comment VB peut (mais ce n’est pas obligé) utiliser des éléments de Windows pour améliorer ses (vos) performances. Mais là, inutile de préciser qu’entrant de plain-pied dans le domaine ésotérique de l’architecture de Windows, on n’est pas au bout de nos peines.

Vous savez sans doute (ne serait-ce que pour avoir supprimé un jour par mégarde) que ces fameuses DLL jouent un rôle capital dans Windows. Mais que se cache-t-il derrière cet acronyme byzantin ? Eh bien, ce sont des "bibliothèques de liens dynamiques", autrement dit des Dynamic Link Libraries. Ces DLL contiennent du code compilé (donc illisible) exécutant telles ou telles fonctions dans Windows.

Par exemple, vous avez déjà remarqué que dans Windows, certaines boîtes de dialogue ont une tête standard, toujours la même quelle que soit l'application : Fichier – Ouvrir, Fichier - Enregistrer, Fichier – Imprimer, Format - Police, et quelques autres encore. Ce n'est pas un hasard : ces boîtes sont en quelques sorte préprogrammées, et n’importe quel programmeur (dont vous-mêmes, public adoré), au lieu de se fader de les reproduire avec plus ou moins de bonheur, peut se contenter d’y faire appel.

En fait, quel que soit le logiciel de départ, lorsqu'on déclenche par exemple la commande Fichier - Imprimer, c'est toujours le même morceau de code externe à ce logiciel qui s'exécute .

Pour continuer avec notre exemple, Comdlg32.dll est le doux nom de la DLL qui contient ce code nécessaire à l’exécution de boîtes de dialogue communes (d’où son titre, abréviation de "Common Dialog") aux applications Windows qui veulent s’en servir.

Donc, lorsque Word ou Excel vous proposent ces boîtes de dialogue, il faut comprendre que les lignes de code correspondantes ne font pas à proprement partie de Word ou Excel. Ces lignes de code sont stockées (une seule fois, donc) dans cette DLL. Word et Excel, eux, se contentent d’appeler la DLL, autrement dit le code qu’elle contient.

Il en va de même pour toutes les DLL, qui sont donc des morceaux de programme utilisables par d’autres programmes. Cela signifie que lorsque vous écrivez du VB, vous n’êtes pas obligé de réinventer à chaque fois l’eau tiède, la poudre à maquiller et le fil à couper le roquefort. Si une DLL contient déjà le code qui fait ce que vous souhaitez, vous pouvez (c’est même recommandé) appeler cette DLL plutôt que réécrire – généralement, moins bien – le code en question en VB.

Avec VB, vous pouvez donc :

Vous l'aurez compris, on se contentera du premier point (quoique le second ne soit pas si inabordable que cela).

Alors, au fait, pourquoi « lien dynamique » ? C’est une question d’architecture. Un langage qui fonctionne avec des liens statiques incorpore à l’exécutable absolument tous les éléments de code dont il a besoin (cf. ce qu’on a dit, par exemple,  pour le chargement des fichiers dans un contrôle image). Avantage, l’exécutable est autonome, et portable tel quel sur n’importe quel machine. Inconvénient, l’exécutable en question a tendance a être gros. L’avantage des langages et des systèmes fonctionnant avec des liens dynamiques, c’est que le code souvent utilisé est en quelque sorte partagé entre tous les exécutables qui en ont besoin à un moment où à un autre.

Avantage : s’il y a plein d’exécutables, on finit par y gagner en place occupée sur l’ordinateur. Inconvénient, l’exécutable généré par un tel langage ne fonctionnera que s’il trouve présentes sur la machine toutes les DLL dont il a besoin. C’est précisément un des aspects cruciaux dont s’occupe l’assistant d’installation de Visual Basic.

En fait, avec cette histoire de DLL, on retrouve peu ou prou à un autre niveau la division entre « logiciel d’application » et « système d’exploitation »  qui existe depuis si longtemps en informatique. Mais là, la zone d’influence du « système d’exploitation », disons plutôt de Windows, dépasse largement la gestion du disque dur et de l’écran. Les DLL contiennent du code gérant (liste non exhaustive) : l’interface graphique, les capacités multimédia…

VB offre en fait deux possibilités pour appeler le code contenu dans les DLL de Windows. Si l'une d'elle vous est encore inconnue, l'autre est en réalité une vieille connaissance… car tels M. Jourdain, vous n'avez jusqu’à maintenant fait qu'appeler des DLL sans le savoir.

Commençons par le plus barbare, le plus brutal et le plus sanguinaire. Aïe, Aïe, Aïe, que se cache-t-il derrière API, ce joli nom de pomme rouge ? Comme vous vous en doutez, comme à chaque fois que Microsoft est dans le secteur, ze worm is in ze frout.

API signifie : Application Programming Interface. C’est en fait un habillage de toutes les fonctions disponibles au sein des DLL. Mais on verra qu'en fait d'habillage, cela ressemble davantage à des haillons qu'à autre chose…

L'idée générale de l'API, c'est que toute DLL peut être utilisée par un langage comme VB sous forme de fonction, qui utilise donc les paramètres (arguments) qu'on lui fournit et qui renvoie donc un résultat vers le langage. Donc, en théorie, pour utiliser une DLL, il suffit de savoir laquelle effectue le traitement que l'on souhaite, quels arguments il faut lui envoyer, et quel type de valeur elle retourne. Ensuite, il ne reste plus qu'à créer cette fonction dans le programme. Mais... il y a un mais. Et pas qu'un seul !

Première bonne blague : à part d’épais et indigestes bouquins (en plus, ils sont chers), il n’existe nulle part une liste un peu complète des fonctions d’appel de l’API, vous disant  quelle fonction fait quoi, et la syntaxe de l’appel. Donc, en gros, ça existe, mais Microsoft ne vous dit pas ni où ni comment. Résultat, il faut chercher, chercher, et chercher encore, crier au secours sur Internet, pour savoir quel appel API utiliser pour une tâche donnée, et en connaître la syntaxe. Il n'y a pas si longtemps, j’ai vu un étudiant passer plusieurs heures à chercher comment, par un code VB, lancer Access avec une base de données précise chargée à l’ouverture… Ce n’est pourtant pas sorcier, me direz-vous ? Pourtant, il n’a obtenu une réponse valable que juste avant de mourir d’épuisement et de désespoir.

Mais jetons un voile pudique sur les affres de cette quête, et imaginons que vous ayez enfin trouvé la syntaxe de l’appel API de vos rêves les plus fous. Comment le mettre en œuvre dans votre application ?

En ce qui concerne la syntaxe, un appel API ne se distingue pas fondamentalement d’un appel à une fonction ordinaire, avec des paramètres.

Pour pouvoir utiliser de l’API (autrement dit une DLL), il faut tout d’abord déclarer la fonction en question, en indiquant les éléments suivants :

Tout cela, encore une fois, vous ne l’inventez pas. Il vous faut tous ces renseignements pour pouvoir travailler, renseignements recueillis dans un bouquin, sur le Net, ou auprès d’un ami si vous avez de mauvaises fréquentations.

Au total, la déclaration donnera un splendide zorglub du genre :

Hem. Je sens qu'un petit décodage ne sera pas inutile.

Une fois cette fonction d’appel API déclarée, vous pourrez vous en servir comme de n’importe quelle fonction, avec par exemple en cours de programme :

Et voilà. Finalement, c'est simple, non ?

Heureusement, ce qui sauve le programmeur VB (sans parfois qu'il le sache), c'est qu'à chaque fois qu'on appelle des DLL, on n'est pas systématiquement obligé de passer par l'API. Il existe une autre voie, bien plus facile. Cette voie, ce sont les... contrôles !

Mais oui ! Les contrôles ne sont que des programmes qui servent d'intermédiaire entre le développeur et les DLL de Windows, intermédiaire qui se charge de traduire la discussion en la rendant nettement plus accessible.

Quand on y réfléchit un peu, tout ça se tient parfaitement. Depuis le début de ce cours, qu'avons nous fait ? Nous avons employé des boutons, des cases à cocher, des listes, etc. autrement dit des éléments de Windows>. Cela signifie que les boutons, les cases à cocher, et tutti quanti existent dans Windows sous forme de DLL. Ce sont ces DLL que nos logiciels classiques (Word, Excel ou Photoshop) utilisent en permanence. Et ce sont ces mêmes DLL que nous avons pu utiliser nous aussi pour écrire nos propres applications.

Simplement, nous n'avons pas eu à programmer d'appels API lorsque nous avions besoin de tout cela (on s'en serait rendu compte !). Pourquoi ? Parce que d'autres programmeurs, en l'occurrence les auteurs du langage  Visual Basic, ont écrit avant nous de petits programmes nous présentant ces DLL sous forme d'objets réutilisables, avec leurs propriétés et leurs méthodes.

Dès lors, cela signifie que si l'on a besoin d'un élément de Windows, il faut toujours chercher à passer par un contrôle, et ne se résoudre à passer par l'API qu'en dernier recours, si on n'a trouvé aucun contrôle qui effectue la tâche voulue.

On peut classer les contrôles VB en quatre  catégories :

A signaler que si votre application emploie des contrôles non standard, vous devez veiller, tout comme pour des fichiers images, à ce que l'installateur repère ces contrôles et les écrive dans le bon répertoire des machines sur lesquelles votre application sera distribuée.

Je termine cette partie par un exemple qui en vaut un autre, celui du contrôle qui gère les DLL des boîtes de dialogue communes (Fichier-Ouvrir, Fichier-Imprimer, etc.) : le contrôle Comdlg32.ocx

Celui-ci permet d’utiliser la DLL correspondante, dont on a parlé plus haut (comdlg32.dll). Grâce à ce contrôle, on disposera donc des menus Fichier - Ouvrir, Fichier - Enregistrer, etc., sans - presque - avoir à rien faire.

Avant toute chose, il faut bien sûr commencer par charger le contrôle comdlg32.ocx dans VB, car ce contrôle, par défaut, ne vous est pas proposé. Rappel : pour ce faire, il faut passer par la commande Projet – Composants, et le choisir dans la liste.

Ensuite, l’astuce, c’est qu’avec ce seul contrôle, on peut ouvrir six boîtes de dialogues différentes. Pour ce faire, il suffit d’appliquer à ce contrôle la méthode appropriée :
 

Avant de lancer telle ou telle méthode pour ouvrir la boîte de dialogue correspondante, il conviendra d'ajuster les propriétés du contrôle, afin de préciser éventuellement des filtres (pour Fichier - Ouvrir), un titre pour votre boîte, etc. De même, la réponse de l’utilisateur sera stockée, comme d’habitude, dans une autre propriété du contrôle. On a ainsi, entre autres, pour la boîte de dialogue Fichier - Ouvrir :

Pour les propriétés des autres boîtes de dialogue communes, cf. les bouquins ou le Net !