Une remarque pertinente ?
Une critique impertinente ?
Un lynchage en règle ?
Une invitation sous les tropiques ?

Ecrivez-moi !
Conçu et enseigné tel qu'en lui même, avec pertes, fracas et humour de qualité supérieure            
 par Christophe Darmangeat dans le M2 PISE du Master MECI (Université Paris 7)            

 
 
 
  
 
 
 
Partie 15
VB.NET et Windows
 
Là, c'est vraiment parti pour le grand frisson. Oubliés les montagnes russes, le train fantôme et les disques de Frédéric François : pour se faire des vraies sensations, rien de tel que... Visual Basic.

1. Les outils qui ne sont pas dans la boîte
Jusqu'à maintenant, à part quelques digressions au sujet des structures du langage (parfois copieuses, je vous le concède), ce cours a consisté à baguenauder nonchalamment parmi les différents contrôles proposés dans la boîte à outils pour découvrir de quoi ils avaient l'air.
Cependant, toute la vie d'un programmeur ne se résume pas aux contrôles de la boîte à outils. Il peut arriver que notre imagination débridée (ou celle de notre client) exige des traitements dont ces contrôles se révèlent bien incapables.
Alors, dans ces cas-là, qu'est-ce qu'on fait ? Eh bien, il y a grosso modo deux cas de figure :
  • le contrôle qui fait ce dont vous avez besoin existe... ailleurs que dans la boîte à outils.
  • ce contrôle n'existant nulle part dans l'univers connu, il n'y a plus qu'à pallier la carence en vous mettant vous-mêmes au boulot.
Bien entendu, fainéants comme nous sommes, nous avons tout intérêt à explorer soigneusement la première possibilité avant de nous lancer dans la seconde. Première possibilité donc, le contrôle existe, ne reste plus qu'à le dégoter. Alors, ces contrôles qui existent ailleurs que dans la boîte à outils, où sont-ils ?

1.1 Les autres contrôles de Visual Studio
D'une part, dissimulés dans VB lui-même. Un certain nombre de contrôles (d'intérêt divers, il faut bien le dire) sont en effet là, tapis dans l'ombre, en attendant que vous veniez fouiller pour vous en servir. Pour les ajouter à la boîte à outils, c'est extrêmement simple : il suffit de passer par la commande Outils - Ajouter/Supprimer des éléments de la boîte à outils. Attention, il existe deux onglets : autant l'onglet Framework.Net ne vous offrira pas un choix énorme, autant les composants COM représentent tout de suite une série de nouvelles possibilités autrement plus étoffée.
Bien entendu, les contrôles récupérés par ce biais ne disposent d'aucune documentation : ce serait trop facile. Ce sera donc à vous de tâtonner, de deviner, bref, de jouer les Sherlock Holmes, pour trouver la clé de ces nouveaux outils et les utiliser au mieux.
Remarque fumante :
Parmi les contrôles disponibles par ce biais, se trouvent dans le Framework .Net trois petits bijoux qui permettent, en deux coups de cuiller à pot, de disposer d'un explorateur d'unités logiques (sous forme de liste déroulante), d'un explorateur de répertoires (sous forme de Treeview) et d'un explorateur de Fichiers (sous forme de ListBox). Ces trois contrôles sont fort utiles pour construire des boîtes de dialogue de type Fichier - Ouvrir un peu personnalisées. Pour une description du code nécessaire, c'est tout en bas de cette page qu'il faut regarder.
1.2 Des contrôles dans le vaste monde de l'Internet
Bon, mais voilà, si comme il est toujours possible, le contrôle de notre coeur ne se trouve pas dans cette liste, où chercher ? C'est très simple : sur le net. Il existe, prêts à être téléchargés, des tonnes de contrôles qui ont été développés, payants, shareware ou... carrément en libre accès.
Un contrôle, c'est un fichier de type *.ocx : quand on effectue une recherche sur le net, c'est souvent une bonne idée que de taper cette extension plutôt que "contrôle" dans Google.
Si la recherche est fructueuse, vous récupèrerez parfois un fichier *.ocx tout seul. Parfois avec un exécutable qui l'installera sur votre machine. Et parfois aussi, accompagné d'un petit fichier d'explications sur son utilisation, voire d'un projet servant d'exemple. Pour les contrôles gratuits, c'est en quelque sorte à la fortune du pot.
Une fois le fichier installé à un endroit quelconque de votre machine, il faut le faire apparaître dans la liste des contrôles disponibles. Pour cela, même manip que précédemment, onglet Com, puis bouton Parcourir, afin d'aller localiser le fichier. Le contrôle apparaît ensuite coché, et il suffit de faire OK pour qu'il fasse une entrée fracassante dans la boîte à outils. Et voilà le travail.
Avec ça, on peut voir venir pour 99 % des situations non prises en charge par les contrôles de la boîte à outils. Citons par exemple, pêle-mêle :
  • la diffusion d'un fichier mp3
  • la diffusion d'un fichier vidéo
  • la gestion d'un conteneur d'image gérant la transparence (rappelons-nous que le PictureBox en est incapable).
  • etc.
Remarque :
Face à un traitement qui sort des sentiers battus, on a toujours intérêt à prendre quelques minutes pour se demander si ce traitement ne ferait pas partie des fonctionnalités de Windows, auquel cas les chances de trouver un contrôle qui permette de les appréhender sont multipliées.
Un exemple parmi tant d'autres : la programmation d'un jeu de cartes, type belote ou bridge.
Avant de se lancer dans la numérisation des cartes et autres opérations fastidieuses de ce genre, on peut pertinemment remarquer que Windows intègre en standard plusieurs jeux de cartes. Ce qui signifie que les cartes utilisées par ces différents jeux existent dans une dll unique, à laquelle il est possible de faire appel pour programmer n'importe quel autre jeu (hormis le tarot, bien sûr...)
Mais, évidemment allez -vous dire, bande de grincheux que vous êtes, 99% des situations, c'est bien beau, mais et le 1 % qui reste ? Ben le 1 % qui reste, c'est que personne n'a fait le boulot... et que vous allez devoir vous y coller vous-mêmes.
En attendant, une petite récréation :
Pour cet exercice, plusieurs remarques s'imposent.
Tout d'abord, celui-ci faisant appel à un composant ocx, un simple exécutable ne suffit pas pour le faire fonctionner : le composant en question doit évidemment être lui aussi installé sur la machine de destination pour que le programme s'exécute convenablement. Voilà pourquoi le lien de l'exécutable pointe ici sur un véritable installateur, conçu avec la technique vue au chapitre 13.
Ensuite, le programme lui-même se divise en deux parties. Tout d'abord, l'interface et les fonctionnalités, que vous devrez obligatoirement traiter. Puis ensuite, une conclusion plus purement algorithmique dédiée au calcul du résultat (paire, brelan, etc.). Vous pourrez laisser celle-ci de côté si vous avez peur de risquer une tendinite des neurones.

2. Quand il n'y a pas d'outils...
Lorsque vous êtes en pays étranger, que vous ne parlez pas un mot de la langue locale, et que vous voulez  demander à un autochtone d'accomplir une tâche quelconque, vous avez trois solutions :
  • vous trouvez un interprète
  • vous prenez votre dictionnaire français - syldavien, et vous vous débrouillez pour faire des phrases sans interprète.

Eh bien, avec VB .Net, c'est un peu la même chose... sauf qu'il n'y a pas de dictionnaire ! Ou tout au moins, pas de dictionnaire fiable et complet. Reprenons.

La langue étrangère inconnue parlée par les indigènes, c'est évidemment Windows, et ses centaines de programmes compilés : les dll. Ces programmes sont utilisés par Windows lui-même, mais ils peuvent également l'être par n'importe quel logiciel qui le souhaite. Encore faut-il savoir comment on s'adresse à une dll. L'interprète, qui permet de dialoguer avec les dll pour leur faire faire ce qu'on souhaite, c'est évidemment le contrôle. Dès lors :
  • soit ce contrôle existe déjà (ce sont les différents cas dont nous avons parlé jusque là)
  • soit le contrôle n'existe pas, alors nous pouvons éventuellement le fabriquer
La fabrication de contrôles est une tâche certes exaltante, mais pas toujours facile. En fait, il s'agit d'un cas particulier du problème plus général de la fabrication de nos propres classes, problème sur lequel nous allons nous pencher (très rapidement)... dans le chapitre suivant.
Pour le moment, je vais simplement dire quelques mots de la dernière possibilité, celle qui consiste à appeler directement les dll de Windows depuis un programme VB, sans passer par l'intermédiaire d'un contrôle. Une telle technique est toujours assez laborieuse à mettre en oeuvre : les dll de Windows sont loin d'être toujours bien documentées, et il faut parfois déployer des trésors de patience pour dégoter, dans un obscur forum ou dans une revue confidentielle, la syntaxe qui vous permettra de faire tourner la dll voulue. C'est d'ailleurs pour cette raison que les contrôles existent  : afin de présenter au programmeur une interface plus sympathique pour s'adresser aux dll de Windows.
Admettons donc que nous ayons besoin d'appeler la fonction Bidule, faisant partie de la dll Chmoldu, ne requérant aucun argument et renvoyant une valeur entière, et pour laquelle nos recherches désespérées n'ont pu nous donner aucun contrôle disponible. La première chose à faire est en quelque sorte d'intégrer cette fonction au sein de notre programme VB, afin de pouvoir y faire appel par la suite. Cela se traduit par l'instruction Declare, avec quelque chose qui ressemblera à :
Declare Auto Function  Bidule Lib "Chmoldu.dll" () As Integer
Cette bonne chose une fois faite, on pourra utiliser la fonction Bidule comme n'importe quelle autre fonction, en respectant le nombre et le type des arguments :
Toto = Bidule() + 5
Sur le principe, donc, rien de plus simple. Dans la pratique, cela s'avère bien souvent un long chemin de douleurs. D'une part, parce que je le répète, les fonctions disponibles au sein des dll sont rarement documentées correctement. On peut donc passer de longues heures à rechercher quelle fonction de quelle dll fait ce qu'on veut, et encore plus de temps à savoir quels sont les arguments requis pour son fonctionnement. Ensuite, parce que VB n'étant pas spécialement conçu pour pratiquer ce genre de sport extrême, le passage des arguments peut vite tourner au casse-tête (je glisse pudiquement sur les détails techniques).
Pour conclure, les appels directs aux fonctions des dll, doivent rester ce qu'ils sont : une solution de dernière extrémité, à ne manipuler qu'en cas d'absolue nécessité, c'est-à-dire en l'absence de contrôles.