Aller au contenu

Messages recommandés

Posté(e)

Salut à tous,

pour rappel, même si c'est finalement hors sujet,

on peut faire communiquer VBA et LISP sous autocad,

avec les VLAX Class de Franck Ockendo

la dernière fois que j'ai testé, c'était sous la 2007,

ensuite j'ai abandonné le VBA pour le VB.net, mais je n'ai jamais eu le temps de formaliser les liaison lisp/vb.net

(d'en faire un tuto très propre avec des exemples concrets)

à toute fin utile, je joint un zip contenant l'essentiel

a+

gégé

----------------------------------------------------------------------

Site: https://www.g-eaux.fr

Blog: http://g-eaux.over-blog.com

  • Réponses 51
  • Créé
  • Dernière réponse

Meilleurs contributeurs dans ce sujet

Posté(e)

Coucou

 

C'est certain que les possibilités sont infinies, seule l'intelligence de celui qui code entre en ligne de compte.

Dans notre cas, la question de Thelduin on pourrait même imaginer comme je le sous-entendais :

Un lisp qui enregistre en CSV et ensuite dans Excel une macro qui traite ce CSV pour calculer ce qu'il souhaite

Pour son TFE je pense que l'impression serait bonne de faire du "multi logiciel", non ?

Je ne suis pas dans son cas de figure, mon TFE en ce moment il se gère avec la caisse de retraite (hihi)

 

Merci pour cet échange d'information quand même, le VBA à force d'annoncer sa mort va finir par faire comme certains artistes qui font leurs adieux pathétiques tous les ans (depuis dix ans).

 

Amicalement

Posté(e)

Salut

 

Pour moi, la seule limite est l'imagination. Tu n'imagines pas ce que l'on peut faire avec les activex.

Pour le fun, un exemple qui fait parler Autocad ;)

(setq sapi (vlax-create-object "Sapi.SpVoice"))
(vlax-invoke sapi "Speak" "Autocad qui parle" 0)
(vlax-release-object sapi)

 

D'après ton lisp, il est certain que l'on peut optimiser des choses, mais le plus important est qu'il fonctionne.

Ensuite, on te propose plusieurs solutions et tu as tout ce qu'il faut pour avancer dans ton projet. A toi de choisir.

 

@+

Les Lisps de Patrick

Le but n'est pas toujours placé pour être atteint, mais pour servir de point de mire.

Joseph Joubert, 1754-1824

Posté(e)

Salut,

 

On peut faire dialoguer différentes interfaces de programmation (LISP VBA ou LISP .NET) mais souvent on se retrouve vite confronté à des problèmes qui font que ce qui semblait plus simple au départ finit par devenir un vrai casse-tête.

Je recommanderais donc d'essayer de choisir l'interface qui semble la mieux adaptée et de tout faire avec celle-ci.

Gilles Chanteau - gileCAD - GitHub
Développements sur mesure pour AutoCAD

Posté(e)

Salut,

 

On peut faire dialoguer différentes interfaces de programmation (LISP <=> VBA ou LISP <=> .NET) mais souvent on se retrouve vite confronté à des problèmes qui font que ce qui semblait plus simple au départ finit par devenir un vrai casse-tête.

Je recommanderais donc d'essayer de choisir l'interface qui semble la mieux adaptée et de tout faire avec celle-ci.

Oui, mais on peut très vite être limité dans son interface. Pour ceux qui aiment les casse-têtes chinois, rien ne vaux les API. C'est aussi ce qui font leurs charmes et leurs puissances.

 

Coucou

 

OK pour l'imagination, pour être complet je parlerais d'une triplette de qualités

Imagination, intelligence et compétence pour terminer.

 

Amicalement

C'est en forgeant que l'on devient forgeron.

Toi et moi, on a commencé tout seul dans notre coin, sans Internet, avec seulement les exemples fournit par Autodesk.

Ce n'est plus le cas maintenant et l'on peut s'appuyer sur les forums, des sites comme le tien pour avancer dans son projet, même si on ne comprend pas tout (dans une certaine limite).

 

@+

Les Lisps de Patrick

Le but n'est pas toujours placé pour être atteint, mais pour servir de point de mire.

Joseph Joubert, 1754-1824

Posté(e)

Oui, mais on peut très vite être limité dans son interface. Pour ceux qui aiment les casse-têtes chinois, rien ne vaux les API. C'est aussi ce qui font leurs charmes et leurs puissances.

 

J'ai dû mal m'exprimer, je répondais à GEGEMATIC à propos de "dialogues" entre LISP et VBA ou LISP et .NET.

Ces dernières années, j'ai beaucoup vu, des demandes pour appeler des routines LISP (et récupérer le retour) depuis des programmes .NET pensant que c'était plus simple que ré-écrire le LISP en C# ou VB alors que la vraie difficulter est de faire dialoguer deux environnement de programmations si différents (typage faible ou fort, dynamique ou statique, contexte document ou contexte application, etc.).

Même dans l'autre sens, où il est prévu de pouvoir définir des fonctions LISP avec .NET, les choses ne sont pas simples (typage des arguments et valeurs de retour, gestion des erreurs).

Gilles Chanteau - gileCAD - GitHub
Développements sur mesure pour AutoCAD

Posté(e)

Salut Patrick,

Pour le fun, un exemple qui fait parler Autocad ;)

(setq sapi (vlax-create-object "Sapi.SpVoice"))
(vlax-invoke sapi "Speak" "Autocad qui parle" 0)
(vlax-release-object sapi)

 

Super ton exemple ! j'en étai resté à :

(vl-vbarun "Vba_Beep")

qui ne marche plus, car je n'installe plus VBA

 

tu sera peut être intéressée par cet article

comment connaitre le prog id ?

 

ou alors, tu va me dire:

mais il suffit de faire alt+shift sur … tu ne savais pas ?

a+

gégé

----------------------------------------------------------------------

Site: https://www.g-eaux.fr

Blog: http://g-eaux.over-blog.com

Posté(e)

Salut !

 

Ensuite, on te propose plusieurs solutions et tu as tout ce qu'il faut pour avancer dans ton projet. A toi de choisir.

 

Si je récapitule, vous m'avez proposé soit de tout faire dans le lisp, ce que je trouve assez séduisant comme idée, soit de passer par un CSV, c'est bien ça ?

 

Je vais explorer ces deux pistes dès que je peux (ce week end je pense), et je reviens vers vous si j'ai des soucis de compréhension ! :D

Posté(e)

Salut !

 

J'ai eu une idée pour mon projet, et j'aimerais vous la soumettre.

En fait, je fais le calcul dans le lisp, et juste après le calcul, je fais apparaître une boite de dialogue dans laquelle je fais afficher le résultat du calcul. Et plus de ça, je fais une liste déroulante avec les ferraillages communs (2Ha10, 2Ha12 etc...) avec la section correspondante affiché à côté

Ça permettrait d'avoir un point de contrôle sur ce qui sort du lisp, et ça donne le choix à l'utilisateur du ferraillage qu'il veut.

Vous pensez que c'est faisable ?

Posté(e)

Salut,

 

Je te conseillerais d'y aller progressivement, sans chercher à tout faire d'un coup.

Les boites de dialogue en LISP (DCL) ne sont pas très faciles à faire (ni le design ni la gestion), donc, dans un premier temps, concentre toi sur les calculs (ce qui est important), tu peux toujours afficher les résultats dans la fenêtre de texte avec de simples (prompt ...).

Gilles Chanteau - gileCAD - GitHub
Développements sur mesure pour AutoCAD

Posté(e)

Bonjour (ou bonsoir :D) !

 

J'ai réussi à calculer mon ferraillage. J'ai finalement fait tous mes calculs dans le LISP, voilà l'état de mon code à l'heure actuelle (j'ai passé 3h30 à faire la partie ferraillage :D) :

J'ai pas déclaré de variable comme vous me l'avez dit, parce que j'utilise les mêmes variables avec les mêmes valeurs dans plusieurs fonctions

(defun c:trace_releve()
(initia)
(command "_-dimstyle" "_r" "COT25")
(setq kw "Oui")
(while ( = kw "Oui")
(setq dclid (load_dialog "releve.dcl"))
(new_dialog "trace" dclid)
(action_tile "accept" "(recup)")
(action_tile "cancel" "(done_dialog)")
(start_dialog)

 ;=====calcul des paramètres utiles=====;
 
 ;niv_inf_dalle = arase inférieure de la dalle
 ;brut = niveau brut de la dalle
 ;epdalle = épaisseur de la dalle
 ;fini = niveau fini
 ;eprel = épaisseur du relevé
 ;arase_sup = arase supérieure du relevé
 ;diff_niv = différence de niveau entre le brut et le fini

;COFFRAGE;
 
(setq niv_inf_dalle(- brut epdalle))
(setq x_insert(car(getpoint "\nSpécifiez le point d'insertion du point inférieur droit (seul le x est retenu) : "))) ;à revoir
(setq p1(list (+ x_insert eprel 50) brut 0))
(setq p2(list (+ x_insert eprel 50) niv_inf_dalle 0))
(setq p3(polar p1 (+ 0 pi) 50))
(setq p4(polar p2 (+ 0 pi) (+ 50 eprel)))
(setq p5(list (car p4) arase_sup 0))
(setq p6(list (+ (car p5) eprel) (- (cadr p5) 1) 0))
(setq diff_niv(- fini brut))
(setq p7(polar p3 (/ pi 2) diff_niv))
(setq p8(polar p1 (/ pi 2) diff_niv))



 (if (tblsearch "LAYER" "01_BA_Coupe") ;test la présence du calque de coupe
(setvar "clayer" "01_BA_Coupe") 
   	(command "_layer" "_M" "01_BA_Coupe" "_CO" 6 "" "ep" 0 "" "tl" "Continuous" "" "")
 )
(command "_pline" p1 p3 p6 p5 p4 p2 "")


 (if (tblsearch "LAYER" "01_BA_Fini") ;test de présence
   	(setvar "clayer" "01_BA_Fini")
 	(command "_layer" "_M" "01_BA_Fini" "_co" 3 "" "ep" 0 "" "tl" "AXES" "" "")
 )
(command "_line" p7 p8 "")


 (if (tblsearch "LAYER" "01_BA_Cotation") ;test de présence
   	(setvar "clayer" "01_BA_Cotation")
 	(command "_layer" "_M" "01_BA_Cotation" "_co" 2 "" "ep" 0 "" "tl" "Continuous" "" "")
 )
(command "cotord" p7 "TE" "<>f" (polar p7 0 30))
(command "cotord" p3 "TE" "<>b" (polar p3 0 30))
(command "cotlin" p2 p1 (polar p1 0 10) "cotcont" p8 p6 p5 "" "")
(command "cotord" p5 (polar p5 0 (+ eprel 30)))


;FERRAILLAGE;

 (initget 1 "Oui Non")
   (setq kw_fer (getkword "\nVoulez-vous tracer le ferraillage ? [Oui/Non]"))

(cond
   ((= kw_fer "Oui")(kw_oui))
   ((= kw_fer "Non")(prompt "dommage"))
)

 
(initget 1 "Oui Non")
 (setq kw(getkword "\nVoulez-vous tracer un autre relevé/garde-corps/acrotère ? [Oui/Non]"))
)
(setvar "clayer" "0")
(reinitia)
)

;=========Fonction de récupération DCL========;

(defun recup()
(setq epdalle(get_tile "epdalle"))
 		(setq epdalle(atof epdalle))
(setq brut(get_tile "brut"))
 		(setq brut(atof brut))
(setq fini(get_tile "fini"))
 		(setq fini(atof fini))
(setq eprel(get_tile "eprel"))
 		(setq eprel(atof eprel))
(setq arase_sup(get_tile "arase_sup"))
 		(setq arase_sup(atof arase_sup))
 	(setq longueur(get_tile "longueur"))
 		(setq longueur(atof longueur))
(done_dialog)
)

;==========Fonctions initialisation=========;
(defun initia()
 (setq acob (getvar "osmode"))
 (setq unitang (getvar "aunits"))

 (setvar "osmode" 0)
 (setvar "aunits" 3)
)
;===================================
(defun reinitia()
 (setvar "osmode" acob)
 (setvar "aunits" unitang)
)

;======FONCTIONS POUR CALCUL=======;
(defun kw_oui()
 
(setq pcent_sct_b 0.5)
(setq haut_bas (- arase_sup fini))
(setq sup_inf (> haut_bas 30))
 (cond
   ((= sup_inf T)(rel_haut))
   ((= sup_inf nil)(rel_bas))
 )
 (cond
   ((= typerel "haut")(calcul_h))
   ((= typerel "bas")(calcul_B))
 )
)
;=======================================
(defun rel_haut()
(setq typerel "haut")
(setq hauteur_h haut_bas)
(setq hauteur_b (- fini niv_inf_dalle))
)
;==============================================================================
(defun rel_bas()
(setq typerel "bas")
(setq hauteur (- arase_sup niv_inf_dalle))
)
;==============================================================================
(defun calcul_h()
(setq as_ha6 0.565)
(setq nb_ha6 (fix (/ hauteur_h 20)))
(setq as_tt_ha6 (* as_ha6 nb_ha6))

(setq sct_bet_h (* hauteur_h eprel))
(setq sct_bet_b (* hauteur_b eprel))

(setq pcent_sct_h (+ 0.17 (* 0.0625 (- longueur 4.0))))

(setq as_rel_h (/ (* sct_bet_h pcent_sct_h) 100))
 (setq as_deduit_h (- as_rel_h as_tt_ha6))
(setq as_rel_b (/ (* sct_bet_b pcent_sct_B) 100))


 (setq result_part_h (strcat "\nSection d'acier nécessaire calculé dans la partie haute : " (rtos as_rel_h 2 2) "cm2"))
 (setq result_h (strcat "\nSection d'acier nécessaire restant dans la partie haute : " (rtos as_deduit_h 2 2) "cm2"))
 (setq result_b (strcat "\nSection d'acier nécessaire dans la partie basse : " (rtos as_rel_b 2 2) "cm2"))
 
   (prompt result_h)
   (prompt result_B)
 
)
;===============================================================================
(defun calcul_b()
(setq sct_bet_b (* hauteur eprel))
(setq as_rel_b (/ (* sct_bet_b pcent_sct_B) 100))

 (setq result (strcat "\nSection d'acier nécessaire : " (rtos as_rel_b 2 2) "cm2"))

   (prompt result)
)

   ;hauteur_h = hauteur de la partie exposé dans le cas d'un relevé haut
   ;hauteur_b = hauteur de la partie non exposé dans le cas d'un relevé haut
   ;hauteur = hauteur du relevé dans le cas d'un relevé bas
   ;typerel = type de relevé
   ;haut_bas = différence arase_sup fini

   ;sct_bet_h = section de béton exposé dans le cas d'un relevé haut
   ;sct_bet_b = section de béton non exposé dans le cas d'un relevé haut ou section de béton d'un relevé bas
   ;pcent_sct_h = pourcentage d'acier mini pour la partie haute
   ;pcent_sct_b = pourcentage d'acier mini pour le relevé bas ou la partie basse
   ;as_ha6 = section d'un lit ha6 (soit 0.565cm2)
   ;nb_ha6 = nombre de lit de ha6 de peau
   ;as_tt_ha6 = sections total en ha6
   ;as_rel_h = section calculé dans la partie haute d'un relevé haut
   ;as_deduit_h = section restante après déduction des aciers de peau de as_rel_h
   ;as_rel_b = section calculé d'un relevé bas ou de la partie basse d'un relevé haut

 

Maintenant, ma dernière question (je pense) pour ce projet concerne les blocs dynamiques.

En effet, j'ai une bibliothèque de blocs dynamique de ferraillage (U, cadre, barres ...) avec des champs (voir image : 1523659676-exemple-bloc-dyn.png)

 

Seulement, toutes les données qu'on entre dans l'onglet "personnaliser" des propriétés, j'arrive pas à y avoir accès. Je pensais qu'avec un entget je pourrais les avoir, mais non. Du coup, je ne sais absolument pas comment accéder à ces données ...

 

EDIT : si vous pensez que c'est trop au dessus de mon niveau, j'ai une autre solution, mais j'aimerais voir comment manipuler des blocs dyn en lisp. De plus, on se sert des ces blocs au quotidien au bureau, donc j'ai l'habitude de m'en servir

Posté(e)

Coucou

 

Au moins tu as travaillé, c'est bien mais comme je n'ai pas vu le fichier DCL donc je n'ai pas pu tester ton travail.

 

En attendant le passage de (gile) qui va être bien plus précis que moi car c'est lui qui nous a appris à travailler les blocs dynamiques..

Je suis en train de traiter les fonction VL sur da-code et c'est justement de ces fonctions VL dont tu vas avoir besoin

Du style :

 

(and
 	(= (vla-get-ObjectName blk) "AcDbBlockReference")
 	(= (vla-get-IsDynamicBlock blk) :vlax-true)
)
;et encore : 
vla-GetDynamicBlockProperties

Je te laisse regarder l'aide en attendant pour te familiariser avec ces nouvelles fonctions

 

Amicalement

Posté(e)

J'ai pas déclaré de variable comme vous me l'avez dit, parce que j'utilise les mêmes variables avec les mêmes valeurs dans plusieurs fonctions

 

Si on t'a conseillé de déclarer localement les variables, ce n'est pas "par principe". En ne le faisant pas tu t'exposes à des bugs difficiles à localiser.

La probabilité que ces bugs surviennent augmente avec le nombre de variables globales. Il y en a déjà un nombre assez considérable. Si j'ai bien compris, tu penses étoffer ta routine et, vu la façon dont tu as commencé, ça veut dine encore plus de variables.

 

Je vais essayer, à l'aide d'un exemple très simple, d'expliquer ce qui pourrait être une meilleure pratique et ensuite, ce que je pense être une bonne pratique

 

La manière dont tu procèdes avec des variables globales :

(defun c:mauvaisePratique	()
 (setq a 10)
 (calculGlobal)
 (prompt (strcat "\n" (itoa B)))
 (princ)
)

(defun calculGlobal ()
 (setq b (+ a 5))
)

 

En localisant variables et fonctions, tu éviteras tout risque d'interaction avec l'extérieur de ta routine :

(defun c:meilleurePratique (/ calculLocal a B)

 (defun calculLocal ()
   (setq b (+ a 5))
 )

 (setq a 10)
 (calcul)
 (prompt (strcat "\n" (itoa B)))
 (princ)
)

 

Mais vu le nombre de variables que tu utilises, même si le problème des effets secondaires (effets de bord) est conscrit à ta routine, il existe tout de même à l'intérieur de celle-ci.

La bonne pratique est d'utiliser des fonctions auxquelles on passe un ou plusieurs arguments et qui renvoient une valeur.

(defun c:bonnePratique (/ a B)
 (setq a 10
       b (calculArg a)    ; appel de la fonction calculArg en lui passant a comme argument
 )
 (prompt (strcat "\n" (itoa B)))
 (princ)
)

(defun calculArg (x)       ; x est l'argument de la fonction calculArg
 (+ x 5)                  ; valeur retournée par la fonction
)

 

De plus, cette façon de faire permet souvent de réduire le nombre de variables locales, donc d'effets secondaires.

(defun c:bonnePratique ()
 (prompt (strcat "\n" (itoa (calculArg 10))))
 (princ)
)

 

 

En ce qui concerne les propriétés dynamiques des blocs, il faut utiliser les fonctions vla* pour y accéder.

Mais personnellement, je n'ai pas trop envie de t'en dire plus tant que que tu continues dans une voie qui fait fi des conseils qu'on a pu te donner.

Gilles Chanteau - gileCAD - GitHub
Développements sur mesure pour AutoCAD

Posté(e)

Salut !

 

je n'ai pas vu le fichier DCL donc je n'ai pas pu tester ton travail

 

Effectivement, je l'ai oublié. Le voilà :

 

trace : dialog{

label = "Données";

: edit_box {
 label = "Epaisseur de la dalle";
 key = "epdalle";
 }

: edit_box {
 label = "Niveau brut";
 key = "brut";
 }

: edit_box {
 label = "Niveau fini";
 key = "fini";
 }

: edit_box {
 label = "Epaisseur du relevé";
 key = "eprel";
 }

: edit_box {
 label = "Arase supérieure du relevé";
 key = "arase_sup";
 }
 
: edit_box {
 label = "Longueur de l'élément";
 key = "longueur";
 }

: row {
 : button {
   label = "OK";
   is_default = true;
   key = "accept";
   }

 : button {
   label = "Annuler";
   is_default = false;
   is_cancel = true;
   key = "cancel";
   }
}
}

 

 

Mais personnellement, je n'ai pas trop envie de t'en dire plus tant que que tu continues dans une voie qui fait fi des conseils qu'on a pu te donner.

 

Je n'en fais pas fi, c'est juste que j'avais mal compris cette histoire de variable globale et locale. En fait, savais pas où déclarer mes variables parce qu'elles passent d'une fonction à une autre, mais en restant la même chose.

 

Mais ce que j'ai compris de ton message, c'est que ma fonction defun c:trace_releve est ma fonction principale, et que, parmi les variables, il y aura les fonctions que je vais définir dans ma fonction principale avec un defun, c'est bien ça ?

 

Je vais donc avoir :

 

(defun c:trace_releve(/ toutes_mes_variables recup initia reinitia kw_oui rel_haut rel_bas calcul_h calcul_B)

Et derrière, je vais définir mes fonctions dans mon defun c:trace_releve

C'est bien ça ? :D

Posté(e)

Coucou

 

Merci pour le DCL, si je trouve un peu de temps je regarde

 

Il me semblait t'avoir dirigé vers ma page d'explications sur les variables, non ?

 

Edit : je viens de vérifier, dans le message #22 tu as bien un lien sur la fonction SETQ

et en fin de sa page je parle des variables,

va voir et dis-moi si quelque chose manque aux explications

Amicalement

Posté(e)

Je n'en fais pas fi, c'est juste que j'avais mal compris cette histoire de variable globale et locale. En fait, savais pas où déclarer mes variables parce qu'elles passent d'une fonction à une autre, mais en restant la même chose.

 

Mais ce que j'ai compris de ton message, c'est que ma fonction defun c:trace_releve est ma fonction principale, et que, parmi les variables, il y aura les fonctions que je vais définir dans ma fonction principale avec un defun, c'est bien ça ?

 

Je vais donc avoir :

 

(defun c:trace_releve(/ toutes_mes_variables recup initia reinitia kw_oui rel_haut rel_bas calcul_h calcul_B)

Et derrière, je vais définir mes fonctions dans mon defun c:trace_releve

C'est bien ça ? :D

 

Déclarer localement variables et fonctions serait un moindre mal.

Mais, à mon avis, prendre l'habitude de définir des fonctions qui prennent un ou plusieurs argument et d'utiliser la valeur renvoyée par ces fonctions (comme on le fait avec les fonctions prédéfinies) est essentiel.

 

Je te rappelle ce sujet dont je te recommande grandement la lecture.

Gilles Chanteau - gileCAD - GitHub
Développements sur mesure pour AutoCAD

  • 4 semaines après...
Posté(e)

Salut !

Bon, je fais face à un problème, je ne sais pas comment déclarer toutes mes variables, sachant qu'elles passent d'une fonction à une autre. Et je ne sais pas quelles variables je peux passer en argument dans mes fonctions

Ça va faire deux semaines que j'essaye de faire bien, comme me l'a fortement conseillé (gile) et là j'avoue que je sèche complètement ...

Je pense que j'ai trop avancé dans mon code, j'aurai du le faire dès le début (mais je ne le savais pas) et du coup, il est pas du tout pensé pour des fonctions à arguments

Posté(e)

Bonjour ! (ou bonsoir ^^)

J'ai eu une petite baisse de motivation, mais je viens de m'y remettre et j'ai une question !

J'ai cru comprendre, en testant, que l'ordre dans lequel sont définies les fonctions ont une importance, par exemple si j'écris ça :

(defun c:sub(/ calcul a B)

(setq a (getreal "\nValeur de a ?"))
(calcul)
(prompt (strcat "/n" itoa B))
(princ)

(defun calcul()
(setq b (+ a 10))
)

J'ai un message d'erreur me disant que la fonction calcul n'existe pas, alors que si j'écris mon code comme ceci :

(defun c:sub(/ calcul a B)

(defun calcul()
(setq b (+ a 10))
)

(setq a (getreal "\nValeur de a ?"))
(calcul)
(prompt (strcat "/n" itoa B))
(princ)

à ce moment-là, ça fonctionne. Est-ce normal ? Et du coup, est-ce que cet ordre d'écriture est à respecter avec des sous-routines avec argument ?

Posté(e)

Bonjour

 

Ta fonction calcul n'a pas besoin d’être dans ton programme principal.

 

Une simple parenthèse fermante après le (princ) de ton 1er exemple suffit a régler le problème.(pour clore ton defun c)

 

a oui, il y a aussi a à passer en argument dans calcul.

 

(defun c:sub(/ a )

(setq a (getreal "\nValeur de a ?"))

(prompt (strcat "\n" itoa (calcul a)))
(princ)
)
(defun calcul(a)
(+ a 10)
)

Posté(e)

je ne pense pas.

 

L'un des interet des fonctions, est qu'elles peuvent être utilisées par d'autre lisp, suffit qu'elles soient chargées une fois.

Un autre est de clarifier le programme principal afin de nous maintenir plus aisément dans notre algorithme.

Créer un compte ou se connecter pour commenter

Vous devez être membre afin de pouvoir déposer un commentaire

Créer un compte

Créez un compte sur notre communauté. C’est facile !

Créer un nouveau compte

Se connecter

Vous avez déjà un compte ? Connectez-vous ici.

Connectez-vous maintenant



×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer. Politique de confidentialité