Migration de solution ObjectARX pour AutoCAD 2013

 La nouvelle mouture d’AutoCAD va certainement vous demander plus d’adaptation à vos programmes ObjectARX, ObjectDBX et DotNet que les versions antérieures si vous désirez tirer pleinement des nouvelles technologies offertes par Autodesk. Dans ce premier article, on s’attardera sur les applications non managées, c’est-à-dire ObjectARX et ObjectDBX.

  • Nouvelles plateformes, nouvelles exigences.
  • Un petit mot sur DotNet
  • Préparation d’un nouveau projet ou migration
  • Compilation
  • Pas encore d’Assistant
  • Outils supplémentaire
  • Précautions
  • Pâques et l’informatique

Le prochain article traitera de la migration de solution DotNet.

Nouvelles plateformes, nouvelles exigences

Vous êtes sans doute au fait qu’il existe des applications telles qu’AutoCAD WS qui fonctionnent sur d’autres systèmes d’exploitation que Windows. Il existe maintenant le « AutoCAD 2013 Core Console » soit un AutoCAD dépouillé de toute interface graphique, idéal pour le scripting, l’impression en lot ou la publication.

Si vous demeurez du côté AutoCAD (ou de ses verticaux) sous Microsoft, vous n’aurez probablement pas à vous soucier des informations contenues dans cette section et pourrez, si vous le voulez, passez à la suivante.

Si vous demeurez du côté Microsoft mais désirez utiliser d’autres produits qu’AutoCAD, alors il faudra tendre le plus possible à restructurer le code en parties où le code interagit avec le dessin (appelé aussi la base de données) de celui qui interagit avec l’utilisateur (appelé aussi UI ou User Interface). Pour ceux qui avaient déjà partagé leur code en fichiers à extension arx et dbx, par exemple pour créer des Object Enabler ou pour utiliser RealDWG, vous avez une longueur sur les autres. Par ailleurs, si vous désirez butiner du côté des autres systèmes d’exploitation, le travail sera beaucoup plus long.

Le premier obstacle sera sans doute le traitement des chaines de caractères car cela représente peut-être jusqu’à une ligne de code sur 20. Aujourd’hui, il est très tentant de se servir de la classe CString. Cela signifie que vous avez créé des DLL qui utilisent la bibliothèque Microsoft Foundation Class (MFC) ou la bibliothèque de classe Active Template Library (ATL). Cela ne sera plus possible sur les autres systèmes d’exploitation. Il faudra revenir au ACHAR (Autodesk CHAR), une variante du TCHAR, elle-même une variante de wchar_t . On présume que les déclarations de type ASCII sont remplacées depuis la version 2008 par UNICODE. Pour ceux qui voudraient creuser davantage à ce sujet, consultez l’article « Migrating ObjectARX applications to support Unicode - some resources » de Kean Walmsley et trouvez l’outil de migration Visual Teefy (disponible sur le site du Autodesk Developer Network (ADN)).

Concernant les boites de dialogue, pour ceux qui trouvent les DCL archaïques, il faut quand même reconnaitre que cela était un avancement majeur à l’époque. Conçu en 1991 sous le nom de code Proteus, les DCL ont vu le jour avec la version 12 (pas 2012). À cette époque, AutoCAD était livré en version pour DOS (surtout), pour Windows 3.1, pour les mille et une saveurs de UNIX (Solaris, HP-UX, etc.) et aussi pour Macintosh. Ce que les DCL ont permis est de pouvoir créer des interfaces indépendantes du système d’exploitation en plus d’être liées dynamiquement au langage AutoLISP. Tout un tour de force. Encore une fois, si vos boites de dialogue sont basées sur le MFC, il faudra séparer le code concerné et faire des projets distincts, ce que vous n’aviez pas à vous soucier avec les DCL. L’équivalent du MFC sous MacOS est Cocoa.

Depuis la version 14 (il y a 14 ans), AutoCAD n’est offert que sous Windows 4.0 et suivantes (j’aurais bien écrit Windows 4.0 ou mieux mais certains malins m’auraient dit que mieux signifie Mac OS ou Linux). On avait annoncé qu’AutoCAD ne serait plus disponible autrement que sur cette plateforme. Depuis tout ce temps, le code ayant trait aux interfaces ou à la base de données est mélangé plus que jamais et il faudra repenser à le séparer comme à l’époque d’antan.

Si vous avez créé des Palettes, des menus déroulants MFC ou même des plug-ins pour la gestion des normes (CAD standards), ils sont tous basés sur COM. Encore une fois, COM est une technologie Microsoft et il faudra ségréguer ce code (l’équivalent de COM sous Mac OS est Corba).

À noter que cet article ne traite pas de DotNet mais il existe une autre technologie disponible grâce aux FrameWorks depuis la version 3.0 soit le Windows Presentation Foundation (WPF). Si vous vous en servez, il va de soi que cela n’aide en rien la compatibilité entre OS. Cette technologie est une surcouche basée sur une collection de bibliothèques destinées à la programmation d’applications multimédia.

Un petit mot sur DotNet

Je reviendrai sur DotNet dans un autre article mais je glisse un petit mot sur deux éléments :
1. Le Runtime est différent
2. Il faut spécifier une référence de plus à chaque projet.

Le premier point concerne le Runtime. Entre les versions du FrameWork (ou FM) 2.0 et 3.5 SP1, le Common Langage Runtime (ou CLR) est demeuré à la version 2.0 mais est passé à 4.0 avec le FM 4.0. AutoCAD 2012 était basé sur ce FM 4.0, ce qui signifie en théorie une cassure potentielle dans la compatibilité. Si vous avez des DLL conçues pour AutoCAD 2010 ou 2011, ils seront compatibles en 2012 mais l’inverse est faux.

Le deuxième point concerne les références aux DLL. Jusqu’à maintenant, vous deviez inclure des références à AcDbMgd.dll (l’équivalent du ObjectDBX/RealDWG pour l’interaction avec le dessin mais sans interactions avec l’utilisateur) et le AcMgd.dll (l’équivalent de la partie communicante avec l’utilisateur (les messages, les demandes d’information, les JIG (poignées et/ou déformation d’objets), le Graphical User Interface (GUI), etc.). La venue du « AutoCAD 2013 Core Console » mentionné plus haut entraine l’ajout du composant AcCore.dll.

Préparation d’un nouveau projet ou migration

Visual Studio 2010 vous propose l’utilisation de feuilles de propriétés (Properties Sheets). Ce que cela vous donnera comme gain de productivité dans vos projets ObjectARX est que vous aurez moins à vous préoccuper des dépendances supplémentaires concernant les répertoires Include, du fichier de définition et des bibliothèques de liens. Note : pour les puristes, oui on peut définir des répertoires dans l’environnement de Visual Studio (Propriétés communes -> Répertoires VC++) mais ils s’appliquent alors à tous types de projets alors qu’on veut s’attarder uniquement aux projets de types ObjectARX.

Méthode traditionnelles avec un projet à extension vcproj

Avec la méthode traditionnelle, il faut spécifier les répertoires des fichiers Include et des librairies selon les 4 possibilités soit Debug-win32, Release-win32, Debug-x64 et Release-x64.

On doit aussi spécifier le fichier de définition du module mais comme on exporte à Windows seulement les 2 symboles acrxEntryPoint et acrxGetApiVersion depuis la nuit des temps, cela est beaucoup moins important. À la rigueur, vous pourriez lui trouver un emplacement fixe en dehors des répertoires de ObjectARX et ne plus y prêter attention lors des migrations.

Méthode améliorée avec un projet à extension vcxproj

La nouvelle façon de faire, bien que l’ancienne soit toujours compatible, est de remplacer ces références « dures » par des feuilles de propriétés qui ajouteront les informations sous la forme de valeurs héritées. Si vous examinez le répertoire C:\ObjectArx\ObjectARX 2013\inc, vous remarquerez la présence des 6 fichiers de propriétés :

  • arx.props
  • brep.props
  • dbx.props
  • rxsdk_common.props
  • rxsdk_debugcfg.props
  • rxsdk_releasecfg.props

Ceux qui nous intéressent pour la plupart des projets sont le premier et les 3 derniers. Regardons de plus près le fichier arx.props

arx.props
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
<Import Project="dbx.props" />
</ImportGroup>
<PropertyGroup>
<_ProjectFileVersion>10.0.30306.1</_ProjectFileVersion>
<_PropertySheetDisplayName>Arx settings</_PropertySheetDisplayName>
<TargetExt>.arx</TargetExt>
</PropertyGroup>
<ItemDefinitionGroup>
<Link>
<AdditionalDependencies>accore.lib;acad.lib;acui19.lib;adui19.lib;%(AdditionalDependencies)</AdditionalDependencies>
</Link>
</ItemDefinitionGroup>
</Project>

La ligne intéressante ici est celle étiquetée « AdditionalDependencies ». On remarque immédiatement les fichiers de bibliothèques qui reviennent à chaque projet. Si on s’est bien servi des fichiers de propriétés (ici arx.props), on pourra vérifier les dépendances comme suit et constater les valeurs héritées:

De même, si on regarde le fichier rxsdk_common.props dont voici une version écourtée, on remarque les lignes suivantes :

rxsdk_common.props
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemDefinitionGroup>
<Link>
<AdditionalLibraryDirectories>..\..\..\lib-$(Platform);..\..\..\..\lib-$(Platform);..\..\..\..\..\lib-$(Platform);%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories>
</Link>
</ItemDefinitionGroup>
</Project>

Encore une fois, on constate les valeurs héritées.

Une tracasserie de moins !

Vous aurez constaté que par défaut, les répertoires de bibliothèque sont composés de chemins relatifs, ce qui est adéquat tant et aussi longtemps que vous exécutez des projets parmi les exemples d’ObjectARX, lesquels sont situés tout près des répertoires ciblés. Dans la vraie vie, vos projets seront ailleurs. Certains ajustements seraient appropriés.

Voici comment ajouter des feuilles de propriétés nouvelles aux projets C + +

  • Assurez-vous d’abord d’avoir défini les plateformes win32 et x64 dans le Gestionnaire de configuration.
  • Dans le menu Affichage, sélectionnez l'élément de menu Autres fenêtres puis Gestionnaire de propriétés (il n’y a pas de raccourcis clavier). La fenêtre Gestionnaire de propriété s’ouvre alors.
  • Dans le Gestionnaire de propriété, cliquez-droit sur le projet qui contiendra la feuille de propriétés nouvelles, puis sélectionnez « Ajouter une feuille de propriétés existante ».

  • Dans la boite de dialogue, repérez le fichier arx.props dans le répertoire Include d’ObjectARX 2013
  • Cliquez sur Ajouter.
  • Recommencez la procédure pour les autres fichiers

La feuille de propriétés nouvelles apparaît comme un nœud dans l'arborescence de la fenêtre Gestionnaire de la propriété pour chacune des 4 configurations.

Pour en connaitre davantage sur a structure des feuilles de propriété, consultez ce lien : http://blogs.msdn.com/b/visualstudio/archive/2010/05/14/a-guide-to-...

Compilation

Lors de la compilation de votre, vous pourriez recevoir l’avertissement sibyllin suivant : 

Avertissement 1 warning MSB8012:
TargetPath(C:\Dev\Arx\rds_MonProjet\rds_MonProjet\Win32\Debug\rds_MonProjet.dll) ne correspond pas à la valeur de la propriété OutputFile (C:\Dev\Arx\rds_MonProjet\rds_MonProjet\Win32\Debug\rds_MonProjet-w32.arx) de Linker. Cela peut entraîner une génération incorrecte de votre projet. Pour corriger ce problème, vérifiez que les valeurs des propriétés $(OutDir), $(TargetName) et $(TargetExt) correspondent à la valeur spécifiée dans %(Link.OutputFile). C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets 990 6 rds_MonProjet

Ce message est assez bénin mais quand même irritant. Pour corriger la situation, ouvrez la boite des propriétés du projet et modifiez le nom de la cible $(ProjectName) en $(ProjectName)-w32 ou $(ProjectName)-x64 selon la plateforme et la configuration de même que l’extension dll en arx.

Vous aurez peut-être remarqué que j’utilise le suffixe w32 au nom de mes fichiers de sortie pour montrer clairement leur compatibilité (de même que x64). Cela est légèrement différent du répertoire Win32 ciblé par $(Configuration). Je préfère en effet le nom rds_MonProjet-w32.arx et rds_MonProjet-x64.arx à rds_MonProjet-Win32.arx et rds_MonProjet-x64.arx. De plus, j’utilise un sous-répertoire Temp pour les fichiers intermédiaires. Cela nous permet de repérer les fichiers arx plus rapidement.

Pour ceux qui se demandent pourquoi j’ai choisi le préfixe rds comme nom de projet, cela signifie Registered Developer Symbol. Vous devriez en obtenir un auprès d’Autodesk si ce n’est déjà fait. Voir ici : http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=107...

Voici en passant une petite astuce qui peut vous sauver bien du temps. Il s’agit de créer une batch file pour que votre fichier arx se copie dans le bon répertoire tout de suite après sa compilation. Ainsi, si vous aurez toujours la bonne version si vous utilisez un Assistant de création (setup.exe ou msi) ou si vous désirez charger le fichier depuis un répertoire parmi les chemins de recherche ou encore si vous avez déclaré une clé de registre pour l’auto-chargement du fichier.

Voici la signification de la ligne de commande $(MSBuildStartupDirectory)\MonBatch $(TargetPath) $(PlatformName)

$(MSBuildStartupDirectory : indique le répertoire de votre solution
MonBatch : indique un fichier à extension *.bat que vous aurez créé
$(TargetPath) : indique le nom complet de votre fichier à extension arx
$(PlatformName): indique si vous êtes en Win32 ou x64 (ceci est une précaution

Voici un exemple de ce que pourrait contenir votre fichier MonBatch.bat

MonBatch.bat

@if "%1"=="" Goto HelpEmptyString
@if "%2"=="" Goto HelpEmptyString
@goto Begin

------------------------------------------------------------------------------
Exemple de traitement lors de l’événement Post-Build
On copie le fichier ARX dans le répertoire C:\AcadSup2013
Puis on le copie dans le répertoire de notre Assistant d’installation.
Par Serge Camiré
------------------------------------------------------------------------------

:HelpEmptyString
@rem La ligne suivante contient des caractères MS-DOS code page 437. Ce n'est pas des erreurs.
@echo Ce fichier %0 ne peut ˆtre lanc‚ directement. Utilisez l’‚v‚nement post-build de Visual Studio.
pause
@goto end

:Begin
COPY %1 C:\AcadSup2013
COPY %1 ..\Install\%2
goto end

:end

Pas encore d’Assistant

La version d’ObjectARX 2013 utilisée était issue des versions beta. Pour l’instant, il n’existe pas encore d’Assistant de création de projet. J’ignore si la situation sera différente dans la version finale. Quoi qu’il en soit, en attendant et si vous le pouvez, créez votre projet avec une version antérieure avec l’ancien Assistant d’ObjectARX puis migrez-le.

Outils supplémentaire

Je vous recommande fortement l’outil « Visual Assist X for Visual Studio » de la compagnie Whole Tomato dont le site est à l’adresse suivante : http://www.wholetomato.com/. Le produit est même déjà prêt pour Visual Studio 2011 (et oui, ça va vite).

Précautions

Autodesk recommande fortement de désactiver le programme de participation de la clientèle lors du développement de leur produit, au moins en mode débogage. Voici tiré de la documentation d’ObjectARX :

Developers should opt out of Customer Involvement Program
Developers should opt out of the Customer Involvement Program to prevent causing such a crash when AutoCAD is run from the debugger.

Il suffit de cocher « No, thanks » dans cette boite de dialogue.

Pâques et l’informatique

En passant, hier c’était Pâques et pour l’occasion j’ai reçu un œuf en chocolat. Je me suis demandé si je devais l’entamer par le gros bout ou le petit bout. La réflexion n’intéresse personne car le résultat est le même (des calories à perdre). Cela a cependant motivé Jonathan Swift à écrire son roman satyrique « Les Voyages de Gulliver » où les habitants des iles Lilliput et Blefuscu se font la guerre. L’origine de celle-ci vient d’un roi qui avait voulu imposer le côté par lequel devaient être cassés les œufs à la coque ; d'où le nom des partisans de chaque doctrine, les Gros-boutiens et les Petits-boutiens – en anglais Big-Endian et Little-Endian. Ces noms vous disent quelque chose? Si vous avez fait des accès à des fichiers en C++ ou en DotNet (via les StreamReader / StreamWriter), vous avez sans doute remarqué les formats Unicode (et ses variantes UTF-8, UTF-16, et UTF-32) mais il y a aussi le type Big-Endian. Si vous voulez vous cassez le coco mais ne savez pas encore par quel bout, je vous propose cet article sur Wikipédia intitulé Endianness (http://fr.wikipedia.org/wiki/Endianness).

 

Vues : 564

Etiquettes : 2013, autocad, migration, objectarx, solution

Commenter

Vous devez être membre de AUGIfr pour ajouter des commentaires !

Rejoindre AUGIfr

Commentaire de Patrick EMIN le 11 mai 2012 à 13:29

Les nouveaux wizards pour ObjectARX 2013 ont été postés par le réseau ADN.

Commentaire de Patrick EMIN le 23 avril 2012 à 18:44

Cet article pourrait aussi intéresser les lecteurs de ce billet.

Commentaire de Patrick EMIN le 12 avril 2012 à 12:00

Je ne connais pas d'oeufs de Pâques depuis la 2008 non plus, voilà qui va motiver les chercheurs d'oeufs...

Commentaire de Serge Camiré le 12 avril 2012 à 2:13

Je ne sais pas où en est la tradition des oeufs de Pâques dans AutoCAD. Le dernier que je connaisse date de la version 2008. Y en a-t-il eu d'autres depuis ?

Commentaire de gile le 11 avril 2012 à 22:02

Merci pour cet article, Serge.

J'attends avec impatience la suite pour .NET (qui me concerne plus). D'après les quelques tests que j'ai fais, la migration semble bien plus simple.

Commentaire de Patrick EMIN le 11 avril 2012 à 20:40

Encore un article très technique de notre ami Serge dont nous admirons toujours autant les connaissances et apprécions toujours la pointe d'humour finale qui ravira même ceux qui auront été rebutés par l'aridité du sujet.

Membres

Bibliothèque TraceParts - Fichiers 2D & 3D GRATUITS

© 2014   Créé par AUGIfr

Badges  |  Signaler un problème  |  Conditions d'utilisation