Histoire de la programmation dans AutoCAD

[Invité Patrick]

Ci-dessous un message de Serge Camiré, à propos de la programmation dans AutoCAD. J'avais demandé à Serge de publier ce texte sur CADxp, après qu'il l'ai publié sur un autre forum CAO:

---

 

Il y eu Illuvatar et la grande lumière.

 

Il y eu ensuite les scripts et les menus. L'interaction était très limitée.

 

Il y eu ensuite AutoLISP avec la version 2.18 d'AutoCAD et qui était basé sur le Common LISP, un langage des années 50 et que je trouve hyper-intelligent car encore adapté à la gestion d'objets complexes, même après 50 ans. Arrivée tardive du Visual LISP décrite plus loin. Avec l'arrivée de R12 (projet Proteus), on peut créer des boites de dialogue via le langage DCL. Sa grande faiblesse demeure dans la lecture de fichiers binaires et la complexité du DCL.

 

Il y eu DIESEL (Acronyme de Direct Interpretively Evaluated String Expression Language) pour l'interprétation dynamique des chaines de caractères (c'était l'époque où le fondateur John Walker (pas celui des Talibans) s'amusait à développer toutes sortes de langages, dont ATLAS pour la compatibilité du DXF). DIESEL est pratique en AutoCAD LT, pour dynamiser des menus déroulants, pour personnaliser la barre d'état (modemacro), pour le texte externe (Rtext) et aussi pour formatter simplement des dates.

 

Vint ensuite R13 et le langage ObjectARX, destiné à une classe plus restrainte de programmeurs. Elle permet notament de créer des objets personnalisés.

 

Puis vint la 14.01 (pas 14.0) et VBA, ainsi que la possibilité d'utiliser VB pour se connecter à AutoCAD depuis une application externe. À l'origine assez resteint mais depuis très complet. On s'en sert pour faire des boites de dialogue plus complexes (et moins chiantes) qu'en AutoLISP. L'accès à des fichiers binaires n'est pas un problème. La gestion des erreurs est meilleure (en Lisp, une erreur conduit à l'arrêt du programme (à quelques nuances près). Sa faiblesse est au niveau de l'interaction sur la ligne de commande. Sa grande force qui est le pendant de sa faiblesse: très effficace si on se limite à la boite de dialogue. VBA contient encore des failles que l'on ne peut simplement résoudre par des appels à AutoLISP (via le SendCommand).

 

Finalement, presqu'au même moment où VBA faisait son entrée, Autodesk a acquit Vital Lisp de Basic Softwae pour l'intégrer sous le nom de Visual Lisp. Visual Lisp offre un environnement de développement puissant mais demeure faible par rapport aux boite de dialogue et l'accès au fichier. VisualLisp a permi de revaloriser AutoLISP par l'ajout de très nombreusses fonctions en ActiveX.

 

Entre VBA ou Lisp, le choix n'est pas toujours évident car les 2 s'équivalent. Si on doit exécuter des routines simples depuis un menu, AutoLISP est mon choix car moins d'overhead.