Fonctions C# et espace lisp séparé

[D.DUHEM]

Dans l'optique d'améliorer l'interface de nos logiciels, nous avons écrit la partie interface en C# et défini des fonctions LISP destinées appeler ces boites modales et modless.

 

En mode développement, tout se passe bien. le LISP appelle bien les boites d'interface et récupère les résultats.

 

Par contre en mode exécution, (pour ne pas être perturbé par des routines utilisateur), le VLX produit est dans un espace séparé et là, plus rien ne fonctionne : les fonctions lisp définies par la DLL ne sont plus reconnues.

 

Il ne semble pas exister de fonctions de type Vl-arx-import comme pour les ARX.

 

Première question : quelqu'un a-t-il résolu ce genre de problème ? Si oui comment ?

 

Seconde question : Pour résoudre le problème, nous avons écrit des fonctions ARX en interface entre le LISP et notre DLL ; celà semble fonctionner sauf l'appel des boites de dialogue WPF qui plantent systématiquement AutoCAD dès lors qu'un ARX compilé en mode CLi/Clr est chargé. Problème connu ? résolu ?

 

merci

[(gile)]

Salut,

 

Même dans ce sens : .NET appelé depuis AutoLISP la liaison n'est pas terrible (dans l'autre sens, c'est souvent désastreux).

Comme beaucoup de ceux qui ont commencé .NET en venant d'AutoLISP, j'ai essayé d'utiliser des passerelles entre les deux environnements mais je n'ai jamais été pleinement satisfait (par exemple il n'est pas possible depuis une méthode LispFunction, de générer proprement des erreurs AutoLISP en cas de nombre ou de type d'argument incorrect).

J'ai donc fini par renoncer à utiliser ce type d'interaction bien avant d'essayer des solution aussi complexes que celles que tu évoques.

À mon sens, le plus simple est finalement de ré-écrire la partie LISP en .NET.

[GEGEMATIC]

Salut,

je sais que c'est prétentieux de ne pas être d'accord avec Gille sur un problème de programmation,

mais sur ce point précis je ne suis pas vraiment d'accord.

Quand on a des milliers de ligne de code Lisp, qui servent comme autant d'outils ponctuels, pour traiter un problème particulier, les réécrire intégralement en net, c'est économiquement suicidaire.

se priver des possibilités de .net pour faire évoluer ces programmes lisp, c'est dommage, surtout quant des propriétés et méthodes ne sont pas exposées en .com, et qu'elles le sont en .net.

Pour l'utilisation d'une commande lisp définie en .net, je n'ai jamais eu de problème particulier, car ayant un usage interne, la gestion des erreurs n'est pas primordiale.

 

En gros, si c'est de la programmation a vendre, d'accord avec Gille, si c'est de la programmation à consommer sur place(TVA 5.5%), le .net est utilisable avec lisp.

 

Pour l'usage de boite de dialogue net avec lisp, j'ai fait beaucoup de tests concluants, mais je n'ai jamais eu le temps de les utiliser pour de bon. (déboguer du net avec autocad, c'est vraiment chronophage, surtout quand comme moi, on est de plus en plus étourdi ...)

 

Pour moi, la solution est peut être dans la question:

Par contre en mode exécution, (pour ne pas être perturbé par des routines utilisateur), le VLX produit est dans un espace séparé

Je ne suis pas une pointure dans ce domaine, mais l’ancêtre de l'espace de nom, c'est bien le bon vieux préfixe de commande ?

d'ailleurs je me demande ce qui se passe si deux programmes .dll différents utilisent le même nom de namespace ? est-ce que le nom de la dll est ajouté pour éviter les confusions? je n'en sais rien.

mais à partit de 3 caractères alphanumérique de préfixe, le risque de perturbation avec les routines vlx de l'utilisateur devient assez anecdotique non ?

 

-sous toute réserve-

gégé