Domanda:
devo inserire delle coordinata in una tabella excel, poi gli stessi valori li devo riportare anche in autocad. Secondo voi esiste un atomatismo che mi consente di non fare due volte lo stesso lavoro? Esiste una tecnica che mi consente di inserire i dati in tabella ed in automatico vengono anche riportati sul disegno?
Non è indispensabile che usi obbligatoriamente Excel, potrei volendo utilizzare anche un altro progamma.
Ago : [post n° 72298]
PROBLEMA INSOLUBILE
potrebbe funzionare se inserisci nel disegno un'oggetto OLE impostato in modo che si aggiorni ogni volta che apri il file dwg? vedi:
[wikiArchipedia: oggetti-ole]
[wikiArchipedia: oggetti-ole]
ci sono anche altri metodi, più macchinosi, ma più alla portata di chi non sa programmare; per esempio, se salvi il file xls delle coordinate in formato testo, con un po' di editing puoi trasformarlo in uno script (file *.scr), che puoi dare in pasto ad autocad.
supponiamo per esempio di dover creare delle linee, e di avere i dati in excel in formato x1,y1,x2,y2; basta creare una colonna con la formula ="_line "&x1&","&y1&" "&x2&","&y2&" ", salvare questa colonna (copia/incolla speciale/valori) come file di testo, rinominarlo in .scr e quindi eseguirlo in autocad con il comando script
supponiamo per esempio di dover creare delle linee, e di avere i dati in excel in formato x1,y1,x2,y2; basta creare una colonna con la formula ="_line "&x1&","&y1&" "&x2&","&y2&" ", salvare questa colonna (copia/incolla speciale/valori) come file di testo, rinominarlo in .scr e quindi eseguirlo in autocad con il comando script
secondo te, come mai si trovano facilmente in giro routine in AutoLISP, ma procedure in VBA niente? Capisco l'ARX, ma il Visual Basic è più intuitivo dell'AutoLISP... Misteri.
che sia perchè autolisp è presente su autocad da 15 anni, più o meno, mentre le prime implementazioni utilizzabili di VBA per autocad risalgono alla versione 14.
Tieni conto che VBA è sì più intuitivo, ma di solito viene usato per fare cose molto più evolute (tipo nel caso in questione collegare due sofware diversi: in autolisp sarebbe impensabile), e quindi alla fine la difficoltà esiste sempre.
Il motivo quindi penso sia riconducibile alla distinzione che bruce perens (padre dell'open source) fa tra i software "differentiating" e quelli "non differentiating" (vedi http://perens.com/Articles/Economic.html già citato anche se per altre ragioni): autolisp viene spesso utilizzato per svolgere compiti comuni (intendi, che accomunano molti utenti, e che possono far risparmiare tempo, ma non sono mission-critical); tipicamente le applicazioni VBA sono più mirate, e per questo motivo costituiscono un maggiore vantaggio competitivo, e hanno quindi un valore maggiore anche per chi le sviluppa (che comprensibilmente si tiene stretto il suo know-how).
Mi spiego con un esempio: possedere un lisp che spegne/accende i livelli o disegna una trave IPE può far risparmiare tempo, ma nessuno al giorno d'oggi pagherebbe per averlo.
Tipicamente, infatti, il cliente non è disposto a pagare per risparmiare tempo (ANCHE se a conti fatti gli converrebbe); è invece molto più disposto a farlo per risolvere un problema altrimenti non risolvibile: un VBA come quello in esempio non è calzante, perchè esistono escamotage manuali.
Ma se supponiamo di non conoscere questi escamotage, o se per esempio il VBA inserisse blocchi (magari migliaia) sulla base dei valori di un elenco su cui devono anche essere svolti dei calcoli complessi, esso non farebbe semplicemente risparmiare tempo, bensì risolverebbe un problema insolubile (perchè a mano sarebbe impossibile farlo, anche disponendo di una cantina con 10 schiavi cinesi che stanno al cad tutto il giorno); come tale è vendibile, e il cliente che viceversa NON E' in grado di ottenere il risultato, è disposto a pagarlo.
Per questo motivo lo sviluppatore, anche se talvolta può concedere gratuitamente , per pubblicizzarsi, l'uso dell'applicazione, si guarda bene dal condividerne il codice.
Non è cioè una questione di complessità, ma di valore intrinseco dell'oggetto.
Tieni conto che VBA è sì più intuitivo, ma di solito viene usato per fare cose molto più evolute (tipo nel caso in questione collegare due sofware diversi: in autolisp sarebbe impensabile), e quindi alla fine la difficoltà esiste sempre.
Il motivo quindi penso sia riconducibile alla distinzione che bruce perens (padre dell'open source) fa tra i software "differentiating" e quelli "non differentiating" (vedi http://perens.com/Articles/Economic.html già citato anche se per altre ragioni): autolisp viene spesso utilizzato per svolgere compiti comuni (intendi, che accomunano molti utenti, e che possono far risparmiare tempo, ma non sono mission-critical); tipicamente le applicazioni VBA sono più mirate, e per questo motivo costituiscono un maggiore vantaggio competitivo, e hanno quindi un valore maggiore anche per chi le sviluppa (che comprensibilmente si tiene stretto il suo know-how).
Mi spiego con un esempio: possedere un lisp che spegne/accende i livelli o disegna una trave IPE può far risparmiare tempo, ma nessuno al giorno d'oggi pagherebbe per averlo.
Tipicamente, infatti, il cliente non è disposto a pagare per risparmiare tempo (ANCHE se a conti fatti gli converrebbe); è invece molto più disposto a farlo per risolvere un problema altrimenti non risolvibile: un VBA come quello in esempio non è calzante, perchè esistono escamotage manuali.
Ma se supponiamo di non conoscere questi escamotage, o se per esempio il VBA inserisse blocchi (magari migliaia) sulla base dei valori di un elenco su cui devono anche essere svolti dei calcoli complessi, esso non farebbe semplicemente risparmiare tempo, bensì risolverebbe un problema insolubile (perchè a mano sarebbe impossibile farlo, anche disponendo di una cantina con 10 schiavi cinesi che stanno al cad tutto il giorno); come tale è vendibile, e il cliente che viceversa NON E' in grado di ottenere il risultato, è disposto a pagarlo.
Per questo motivo lo sviluppatore, anche se talvolta può concedere gratuitamente , per pubblicizzarsi, l'uso dell'applicazione, si guarda bene dal condividerne il codice.
Non è cioè una questione di complessità, ma di valore intrinseco dell'oggetto.
Rimango dell'idea che con un linguggio semplice e completo come VBA puoi fare cose complesse ma anche semplici.
Chi vuole sviluppare sul serio (il programmatore "per soldi") usa ARX, il C, che ti permette una totale coincidenza con l'ambiente di sviluppo, che non viene interpretato, ma semplicemente eseguito, oltre alla compilazione del codice.
VBA è e rimarrà sempre un linguaggio per script esterni appiccicati. La stessa Microsoft non se ne fa più un vanto.
Quindi non credo che il motivo dell'assenza di routine in giro sia il maggior valore intrinseco, credo più alla prima ragione che hai dato, i 18 anni di AutoLISP, più veloce a partire, più integrato nel programma, e in fin dei conti più facile da scrivere e da usare, addirittura sulla stessa linea di comando...
Chi vuole sviluppare sul serio (il programmatore "per soldi") usa ARX, il C, che ti permette una totale coincidenza con l'ambiente di sviluppo, che non viene interpretato, ma semplicemente eseguito, oltre alla compilazione del codice.
VBA è e rimarrà sempre un linguaggio per script esterni appiccicati. La stessa Microsoft non se ne fa più un vanto.
Quindi non credo che il motivo dell'assenza di routine in giro sia il maggior valore intrinseco, credo più alla prima ragione che hai dato, i 18 anni di AutoLISP, più veloce a partire, più integrato nel programma, e in fin dei conti più facile da scrivere e da usare, addirittura sulla stessa linea di comando...
Bravi! ...sono le ragioni validissime per le quali ho deciso di restare solidamente ancorato ad AutoLISP / Visual LISP.
Buon lavoro a tutti!
ARKLisp
http://webspace.omniway.sm/fbattistini/
Buon lavoro a tutti!
ARKLisp
http://webspace.omniway.sm/fbattistini/
