Hello World: ovvero cosa serve veramente per far funzionare un’addin managed ObjectARX

Negli Autodesk Labs è presente l'immancabile applicazione Hello World con cui configurare correttamente l'ambiente di sviluppo.

Nel Lab vengono indicate le DLL da linkare e gli eventuali attributi da aggiungere alle classi o ai metodi come in particolare il CommandMethod con cui definire un comando custom all'interno di AutoCAD.

Ciò che il lab non dice sono però alcuni accorgimenti fondamentali per far funzionare veramente tutto riducendo gli errori. Sono piccole configurazioni che però mi hanno fatto perdere giornate di lavoro.

  1. I metodi associati ad un CommandMethod devono essere pubblici e non devono restituire nessun valore (devono cioè essere delle sub in VB.Net o restituire void in C#)
  2. Oltre a aggiungere le reference alle due librerie acadmgd.dll e acadmgdb.dll è fondamentale impostare la proprietà Copy Local a False altrimenti quando invocate il comando custom AutoCAD vi dice che non esiste nessun comando con quel nome
  3. Un'ultima cosa che mi ha fatto perdere il sonno per giorni… Impostate nella variabile PATH il percorso [program folder]Autocad 2008 altrimenti potete scordarvi di utilizzare l'ereditarietà nelle form…
Share

Disabilitare l’invio del report di errore ad Autodesk in caso di crash di AutoCAD

Ogni volta che si manda in crash AutoCAD  viene visualizzata la form per inviare la segnalazione di errore ad Autodesk.

Nonostante le mille attenzioni che si possono avere per non mandare in crash AutoCAD ciò in realtà accade diverse volte al giorno soprattuto in fase di sviluppo e debug.

Basta dare un'occhiata al video intitolato "10 EASY ways to crash your AutoCAD addin" per farsene un'idea (il video è scaricabile da qui).

Per evitare questa richiesta si può utilizzare il comando "ReportError" che gestisce la corrispondente variabile binaria per abilitare/disabilitare l'invio del report di errore.

ReportError = 0 -> Non viene visualizzata la form di segnalazione

ReportError = 1 -> Viene visualizzata la form di segnalazione

Share

Database.Save e eFileInternalErr: bug di AutoCAD

In AutoCAD 2008 eseguendo il metodo managed ObjectARX:

Application.DocumentManager.MdiActiveDocument.Database.Save()

viene sollevata l'eccezione:

eFileInternalErr

ed il dwg non viene salvato.

Si tratta di un bug (l'ennesimo…) dell'API di AutoCAD.

Per aggirare il problema è sufficiente utilizzare il metodo SaveAs passando come nome del file il nome del dwg corrente:

Application.DocumentManager.MdiActiveDocument.Database.SaveAs

(Application.DocumentManager.MdiActiveDocument.Database.Filename, Autodesk.AutoCAD.DatabaseServices.DwgVersion.Current)

Oppure è possibile invocare il comando "_qsave".

E' veramente incredibile che un prodotto software di questo livello contenga dei bug di questo genere. 

[EDIT]

Grazie a Giuliano per questa segnalazione relativa alla documentazione:

"You can't save a database to the same file it was read from, because
it may not have been completely read in initially, so saving to the
same file poses the risk of concurrently reading/writing to the same
file. The SAVE command uses saveAs() to save to a different (e.g.,
temporary) file and then either deletes or renames the original to
*.bak, and then renames the saved file to the original filename. "

Resta valida la soluzione che propongo per salvare sullo stesso file.

Share

La compatibilità delle applicazioni tra le release di AutoCAD

Da through-the-interface un estratto sul tema della compatibilità tra le release:

Le applicazioni sviluppate sfruttando l'API AutoCAD devono essere testate (ed alcune volte modificate) per garantirne il funzionamento con nuove release di AutoCAD. Per alcune generazione di AutoCAD abbiamo scelto di non garantire la compatibilità binaria delle applicazioni ogni 3 release (storicamente questo è avvenuto con AutoCAD 2000, 2004 e 2007).

Inoltre le applicazioni sviluppate con diverse API richiedono un impegno diverso per effettuare il porting da una release all'altra. Le applicazioni [W:LISP] sono abbastanza portabili tra le release (anche se i nomi e le posizioni dei file di supporto potrebbero cambiare di volta in volta), così come lo sono le applicazioni COM (come VBA e applicazioni esterne VB). Le applicazioni che usano le API managed (C# o VB.NET) sono un po' meno portabili di quelle ObjectARX (C++).

Le applicazioni ObjectARX sono architetturalmente molto vicine al core di AutoCAD ed è per queste applicazioni che gli sviluppatori – sia esterni che interni ad Autodesk – devono dedicare molte risorse quando viene meno la compatibilità tra le release.

Perchè è necessario interrompere la compatibilità col passato? Ci sono alcune ragioni:

  1. Alcune volte vogliamo semplicemente aggiornare le classi dell'API, per aggiungere nuovi metodi ecc. Mentre è possibile aggiungere metodi non-virtuali durante un passaggio di release compatibile, non è possibile garantire la compatibilità quando vengono aggiunti metodi virtuali perchè viene modificata la v-table
  2. Potremmo aver bisogno di aggiornare l'architettura interna o l'uso della tecnologia. Un esempio di ciò è stata l'introduzione massiccia dell'[W:Unicode] in AutoCAD 2007. Questo è stato un profondo cambiato nel modo con cui AutoCAD gestisce internamente le stringhe e ha richiesto la modifica della signature di molte funzioni ObjectARX.
  3. Infine si vuole godere dei vantaggi offerti dall'ultima versione del compilatore per compilare AutoCAD. AutoCAD 2000-2002 sono state compilate con Visual Studio 6, AutoCAD 2004-2006 con Visual Studio .NET 2002 e AutoCAD 2007 con Visual Studio 2005. E' importante per Autodesk rimanere allineati con l'ultima versione supportata del compilatore per ottenere supporto da Microsoft su problemi critici ma soprattutto per fornire nuove funzionalità, come ad esempio la possibilità di usare WinForms in AutoCAD e di esporre un API managed.

La domanda adesso è: perchè non viene interrotta la compatibilità ad ogni release? A causa delle difficoltà che temono i clienti e gli sviluppatori. La mancanza di compatibilità di un'applicazione in una nuova release ha impatto sull'accettazione di quella release. Mantenere una finestra di 3 release (che ad oggi equivale a 3 anni) fornisce agli sviluppatori il tempo per concentrarsi sui miglioramenti dell'applicazione a favore del cliente piuttosto che spendere risorse per la migrazione alla nuova piattaforma.

L'articolo completo si trova a questo indirizzo: http://through-the-interface.typepad.com/through_the_interface/2006/06/compatibility_o.html 

Proprio in questi giorni stò migrando un'applicazione scritta in C#-VB.NET che funziona su AutoCAD 2006 alla nuova piattaforma AutoCAD 2008. La mancanza di compatibilità c'è ma è veramente ridotta al minimo (cose tipo enumerati che hanno cambiato nome o poche funzioni con una signature diversa), nulla che non si possa agevolmente gestire utilizzando le direttive del compilatore. In pratica ho definito una direttiva ACAD2006 ed una direttiva ACAD2008 e con quelle decido per quale piattaforma compilare la DLL.

Share

.NET e AutoCAD

Da through-the-interface:

Gli ingegneri di AutoCAD hanno creato il primo prototipo di API managed per AutoCAD 2004. Era una cosa abbastanza rivoluzionaria all'epoca: una DLL ibrida che espone un'interfaccia managed ed esegue il marshalling di queste chiamate verso le corrispondenti chiamate unmanaged ObjectARX. Erano molte, e lo sono ancora oggi, le ragioni per cui .NET era interessante per gli sviluppatori… 

.NET fornisce la facilità di sviluppo che era disponibile solo (o principalmente) ai client VB tramite COM. Puoi usare COM o dei componenti .NET nei tuoi progetti, ma puoi generare codice più facilmente utilizzando dei linguaggi di programmazione più evoluti (e VB.NET è molto più evoluto di VB6).

Un primo beneficio per Autodesk fu la possibilità di mappare dei tipi di dato molto più complessi (come quelli definiti in ObjectARX) su un'API managed. Quando progetti un API COM se molto più limitato – puoi utilizzare solo dei tipi base ed oltre quelli per definirne altri devi implementare delle interfacce complesse basate su IDispatch il che porta inevitabilmente ad un overhead di progettazione e di sviluppo: è laborioso esporre delle interfacce di COM Automation per delle classi C++ complesse.

Per un primo contatto con l'API .NET per AutoCAD visita l'AutoCAD Developer Center – dove i Labs sono un ottimo punto di partenza.

Nei prossimi post vedremo la struttura di base di una semplice applicazione .NET per AutoCAD e come sfruttare le API COM e unmanaged attraverso la COM Interop e P/Invoke.

Articolo originale: http://through-the-interface.typepad.com/through_the_interface/2006/06/net_and_autocad.html

Share

A breve la traduzione di alcuni post di Kean Walmsley dal blog through-the-interface

Chi è Kean Walmsley?

Come riportato sul suo blog (http://through-the-interface.typepad.com/) Kean ha lavorato in Autodesk sin dal 1995, concentrandosi su supporto alla programmazione, consulenza, formazione ed "evangelism" verso sviluppatori esterni. Ha lavorato in Autodesk in svariate nazioni: ha cominciato la sua carriera in Inghilterra e poi, spostandosi ogni 2-3 anni, ha lavorato in Svizzera, Stati Uniti ed India. Attualmente Kean è Senior Manager di Developer Technical Service (DevTech), un gruppo mondiale di guru che forniscono servizi tecnici tramite Autodesk Developer Network (ADN).

Ho avuto l'opportunità di contattarlo per richiedergli supporto tecnico per la soluzione di alcuni problemi presso un mio cliente e ne ho approfittato per chiedergli il permesso di tradurre su questo blog alcuni dei suoi post relativi ad ObjectARX e .NET per cercare di diffondere l'API in Italia e magari creare una comunità italiana specializzata.

Ha accettato con molto piacere quindi a breve inizierò a pubblicare alcuni suoi articoli in questo blog, il che sarà anche per me un'opportunità di approfondimento sui temi tecnici che via via propone.

Grazie!

Share

Hatch too dense (EHatchTooDense) tratteggiando un poligono

In una routine stò disegnando un rettangolo per poi riempirlo con un hatch tratteggiato.

Il più delle volte il codice funziona senza errori ma in alcuni casi ricevo l'errore "EHatchTooDense" ed il rettangolo non viene tratteggiato.

Il problema risiede nella variabile di sistema MaxHatch che determina il numero massimo di linee che possono essere disegnate in un poligono (a default 10.000).

Per sapere il valore corrente della variabile si può usare il comando:

(getenv "MaxHatch")

mentre per impostare il valore

(setenv "MaxHatch" "n")

dove n è compreso tra 100 e 10.000.000 e MaxHatch è case sensitive.
Un valore troppo elevato per la variabile potrebbe causare un degrado di prestazioni nel disegno. Il comando può essere eseguito ovviamente da C# ed il valore resta impostato anche chiudendo AutoCAD.

Leggi l'articolo nella Knowledge base Autodesk.

Share

DynamicBlockReferencePropertyCollection e IsDynamicBlock

Mi è capitato di accedere alle seguenti proprietà di un blocco dinamico:

  • DynamicBlockReferencePropertyCollection
  • IsDynamicBlock

e di non ottenere i risultati sperati. Mi aspettavo che IsDynamicBlock fosse true e che in DynamicBlockReferencePropertyCollection ci fosse l'elenco di tutte le proprietà dinamiche.

Il problema è che il metodo e la property funzionano correttamente se si accede dalla classe BlockReference all'interno di una transazione.

Se invece si accede al di fuori di una transazione (ad esempio io leggevo la BlockReference e poi chiudevo la transazione) non è possibile accedere correttamente a IsDynamicBlock e DynamicBlockReferencePropertyCollection.

Share

How to: sincronizzare le attribute reference dopo la modifica di un blocco con ATTSYNC

Se si modifica un blocco in AutoCAD le attribute reference non vengono automaticamente aggiornate al salvataggio del blocco.

In particolare se si aggiungo nuovi attributi al blocco questi non sono disponibili nella BlockReference e viceversa se si rimuovono degli attributi la BlockReference continua a visualizzarli.

Per sincronizzare la BlockReference è sufficiente eseguire il comando ATTSYNC.

Il comando consente di scegliere il blocco da sincronizzare selezionando una qualsiasi BlockReference oppure inserendo il nome del blocco.

Share

LoaderLock was detected – Autocad 2006 e Visual Studio 2005

Avviando l'esecuzione in modalità debug di una dll creata in Visual Studio 2005 per Autocad 2006 si riceve l'errore:

LoaderLock was detected

Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

E' sufficiente modificare la seguente chiave del registro di Windows:

[HKEY_LOCAL_MACHINESOFTWAREMicrosoft.NETFramework]

aggiungendo il valore stringa:

MDA = 0
Share