[AUTOCAD] Lisp TUY didn't work

[nG!Hebus]

Hi,

I'm using BonusCAD's LISP since few year, but i'm changing for another company and i lose my old LISP, i find them in new version but they didn't work like i used it before.

If someone can help me, Autocad return this message : paramètre de la variable AutoCAD rejeté: "delobj" nil

Thanks for your help !

"French version:

J'utilise des lisp produits par BonusCAD depuis une paire d'années maintenant, ceux ci fonctionnais très bien jusqu'à ce que je change d'entreprise... J'ai perdu une partie de ceux ci et je pensais les avoir retrouvés MAIS ! En fait non, ils ont été modifiés par rapport à ceux que j'ai connu.

Je suis sur une version AUTOCAD 2025 FULL, le lisp et ces fichiers sont en dessous, quand je lance TUY pas de soucis, dès que je lance TUYB, Autocad me retourne : paramètre de la variable AutoCAD rejeté: "delobj" nil

merci pour votre aide  ;)"

[pendean]

---

@nG!Hebus wrote:

...I'm using BonusCAD's LISP since few year...

"French version:

J'utilise des lisp produits par BonusCAD depuis..."

---

Why not ask them about that?

[ВeekeeCZ]

Do you get the TUYB dialog? If so, post a screenshot of meaningful parameters.

Just make sure that all the files are saved at the searchable paths.. add the path to "Support File Search Path".

Also, either set SECURELOAD sysvar to 0 or add the path between Trusted locations.

[nG!Hebus]

Hi,

He retired in 2014...

[nG!Hebus]

Hi the problem not coming from autocad but from lisp.

I used "Appload" to load them at every start, i think someone change a little piece of AUTOLisp and now it doesn't work...

"TUY" command is working, but not "TUYB" -> this command was used for make bloc after create solid, autocad tell me :

paramètre de la variable AutoCAD rejeté: "delobj" nil

I have another LISP who didn't work, same like this for flange, "BRIDE" work, "BBRIDE" didn't work... Autocad return : 

Impossible d'appeler (command) à partir de *error* sans appeler préalablement (*push-error-using-command*).
Il est recommandé de convertir les appels (command) en (command-s).

[ВeekeeCZ]

You are repeating yourself. Answer my question and confirm that you have set paths correctly.

[ВeekeeCZ · Accepted solution]

Here is one thing that you SHOULD do...  - BUT IT DOES NOT FIX THE ISSUE!

Search all the files for error functions... something like the red part 

And replace all command with command-s

(defun erreurbride (msg)
  (setvar "delobj" delobjet)
  (if sv_dm (setvar "DYNMODE" sv_dm))
  (setvar "CMDECHO" 1)
  (if (not (zerop (getvar "cmdactive")))(command))
  (command-s "_undo" "_e")
  (command-s "_u")
  (setq *error* m:err m:err nil)
  (princ "\nPas de valeur dans base données pour ce type de bride")
  (prin1)
)

[nG!Hebus]

You would see this?

 

[nG!Hebus]

Ok i will try this 😉

EDIT : Working on "BBRIDE" !

[ВeekeeCZ]

Do you see the TUYB dialog when you run the command?

[ВeekeeCZ · Accepted solution]

Just to recap... I tried BBRIDGE lisp in ACAD 2025 and was able to run and use it. That means the LISP work, you just have to find a way to load them properly. Maybe someone who speaks French could take over. Good luck.

[_Serge · Accepted solution]

Bonjour,

Je n'ai pas essayé la routine (et je ne le ferai pas). BeekeeCZ a probablement mis le doigt sur le problème mais sans mentionner pourquoi il avait supposé la cause. En fait, le message est trompeur car il fait référence à l'instruction (setvar "delobj" delobjet) située dans une trappe d'erreur (la fonction erreurcdb et peut-être ailleurs).  La variable est globale et n'a probablement pas initialisée au moment où la fonction d'erreur erreurcdb prend le relais, d'où le fait qu'AutoLISP considère (setvar "delobj" nil). Je tient à souligner que "delobj" est une variable qui existe encore et qui est reliée à _SWEEP. Là n'est pas le problème.

Il s'agit probablement d'un problème d'environnement. Soit que les chemins de recherche ne trouvent pas le dcl ou tuyp.lsp ou encore que le chemin d'accès (voir SECURELOAD) n'est pas autorisé. Dans la commande _OPTIONS, il faut voir l'un et l'autre sous l'onglet Fichier, respectivement dans "Chemin de recherche de fichiers de support en cours d'utilisation" et "Emplacements approuvés". Particularités supplémentaires : les emplacements approuvés dépendent de 2 variables, soit TRUSTEDPATHS et SECURELOAD et permettent d'être simplifiés en déclarant un chemin racine suivi de 3 points pour inclure les sous-répertoires (ex: "C:\MesFichiersLisp\..." signale à AutoCAD que "C:\MesFichiersLisp" et tous ses sous-répertoires sont approuvés.

Enfin, voici un segment du fichier tuyp.lsp:

(setq dcl_id (load_dialog "tuyp.dcl"))
(if (not (new_dialog "tuyp" dcl_id))
(exit)
)

Ce que ça dit, c'est qu'en cas d'erreur de chargement du DCL, la fonction (exit) sera exécutée, d'ou le relais potentiel à la fonction erreurcdb précitée.

En espérant l'information pertinente.

[nG!Hebus]

Salut,

C'est effectivement uniquement une erreur de variable... Pourquoi ma version aurais était installé avec des variables différentes, je ne comprend pas... j'ai bien un fichier .arg que je promène depuis des années avec toutes mes variables réglées de bases...

Est ce que cela peut aussi venir du serveur one-Drive ? Je n'ai pas les droits sur l'ordinateur pour mettre des éléments directement au plus court comme je fait souvent chez mes clients.

En tout cas cela refonctionne donc MERCI 😉

[_Serge]

Bonjour,

Puisque la solution a été acceptée, je ne devrais plus continuer cette discussion mais pour moi le mystère demeure. Qu'avez-vous modifiée ? Avez-vous forcé une valeur ? J'ai peur que vous n'ayez que reporté le problème.

Pourriez-vous faire un petit test ? Copiez ceci sur la ligne de commande (la liste peut être modifiée pour inclure d'autres fichiers, ne pas inclure le chemin) :

(mapcar (function (lambda (fichier) (findfile fichier))) (list "acad.exe" "tuyau3d.lsp" "tuyp.lsp" "tuyp.dcl"))

Une liste de chemin complet va apparaître si son chemin de recherche a été trouvé, sinon, nil. J'ai inclus "acad.exe" pour garantir au moins un succès.

(exemple de valeurs: ("C:\\Program Files\\Autodesk\\AutoCAD 20XX\\acad.exe" Z:\\toto\\tuyau3d.lsp" nil nil))

Voici mes observations:

• La variable DELOBJ n'a pas été modifiée depuis très longtemps donc les commandes associées se comportent comme avant.
• La recommandation d'utiliser command-s au lieu de command dans les trappes d'erreurs est pertinente depuis AutoCAD 2015 ou R20.0) (les raisons pour lesquelles utiliser l'une ou l'autre dépasse le cadre de cette discussion mais disons rapidement que command s'emploie lorsque l'énoncé est complet (ex: (command "_point" '(0,0 0.0))) et que command-s s'emploie dans les trappes d'erreur ou lorsque l'énoncé est incomplet (ex: (command "_pline")). En théorie, si la routine avait été exempte d'interruption forcée, la trappe d'erreur n'aurait jamais été appelée, donc la différence entre command et command-s aurait été sans objet.
• Pour ce qui est des emplacements réseau ou même du chargement à partir de lecteurs amovibles, AutoLISP ne pose généralement pas de problème (c'est une autre histoire pour des dll, là encore les subtilités dépassent cette discussion). Par contre, le système d'exploitation peut démontrer un manque de bonne volonté à donner l'accès au fichier lorsque le chemin est long ou virtuel. D'où l'idée d'effectuer le test avec (mapcar (function (lambda (fichier) (findfile fichier))) (list "acad.exe" "tuyau3d.lsp" "tuyp.lsp" "tuyp.dcl" "fichier_x.lsp" "fichier_y.lsp" "etc" "etc")).