Trouble adding External Command

[davidgarner]

I've created an assembly (.dll) and edited the revit.ini file as follows

[ExternalCommands]
ECCount=1
ECName1="Hello"
ECDescription1="Say hello to user."
ECAssembly1="C:\Documents and Settings\dlg\Desktop\AutoCAD dotnet\C# Labs\MyLabs\RevitTesting\AUSampleCode\bin\Release\AUSampleCode.dll"
ECAssemblyName1=AUSampleCode.Class1

When I open Revit 8.1 the External Command does not appear in the menu and when I look at the revit.ini the ECCount has been changed (not by me) from 1 to 0.

What is going on? Any ideas?


I've confirmed that 1) the dll is in the specified directory and 2) there are no spelling errors in the ECAssemblyName1.

[ChrisArps]

This is an ini file from the samples folder, note the ClassName attribute.
>>>>>
[Revit.ini must be Unicode file, edit with Notepad; if there are no foreign characters it can be ANSI though]

[ExternalCommands]
ECCount=1
ECName1="ArchSample1"
ECDescription1="Retrieves properties from the elements in the project and exports to an Excel file"
ECClassName1=ArchSample1.Command
ECAssembly1="C:\Revit API\Samples\ArchSample1\bin\ArchSample1.dll"
>>>>>

IMHO this whole mechanism needs to be replaced by something more reasonable. How can they expect two different developers to modify this file for installs or uninstalls?

.INI files are DOS technology, it needs to be upgraded to use an XML file at the very least.

Chris Arps

[davidgarner]

Regarding your comment about XML. I completely agree.

.ini files are sooooooo last century.

At least they don't have us hacking at the registry. 🙂

I tried again and got it to work. Same file except I changed the order of the ECClassName and ECAssembly and it worked fine.

Still don't understand why that would be the case. .ini files are not "order dependant". And why would it change my .ini file ECCount=1 to ECCount =0? Puzzling.

But I've got the "hook" now. On to learning the API.

[Anonymous]

Chris,

From a developer standpoint, the use of INI files seems rather
outdated. However, they have one thing going for them: they are easy to
edit with a standard text editor by someone without experience with XML.
Revit's INI file is used for many other things other than adding
external applications and it can be edited by any Revit user, so from
that standpoint it makes perfect sense to keep it as it is.

Perhaps a better alternative would be a separate XML file just for
initializing external applications. I agree with David: at least we
don't have to hack the registry.

My 2¢,
-Danny

CArps wrote:
> This is an ini file from the samples folder, note the ClassName attribute.
>
> [Revit.ini must be Unicode file, edit with Notepad; if there are no foreign characters it can be ANSI though]
>
> [ExternalCommands]
> ECCount=1
> ECName1="ArchSample1"
> ECDescription1="Retrieves properties from the elements in the project and exports to an Excel file"
> ECClassName1=ArchSample1.Command
> ECAssembly1="C:\Revit API\Samples\ArchSample1\bin\ArchSample1.dll"
>
>
> IMHO this whole mechanism needs to be replaced by something more reasonable. How can they expect two different developers to modify this file for installs or uninstalls?
>
> .INI files are DOS technology, it needs to be upgraded to use an XML file at the very least.
>
> Chris Arps

[jimmie_fulton]

INI files for user editable values may be fine, but this format for loading external apps is practically unusable. Your installers will be required to get the ECCCount, and then add your entries with the correct numbers. Not too bad. But then your uninstaller needs to figure out which entry your app is, and renumber any of the app entries that may have been added by another party. Ahem. Is this doable? Sure, but that functionality has not been provided and leaves developers to come up with a bunch of varied, non-standard solutions to the problem.

For what it's worth, I went to an ADN day and asked about this "feature". They are supposedly working on an improved mechanism, but did not give specifics on how long we would have to wait.

Just a couple more ¢.

[Anonymous]

At present, keeping a backup of the previous Revit.INI file in your
installer and restoring new version of Revit.INI to the old version in your
uninstaller is a way. This not only removes anything added by the installer
but also restores other things to its original status. - Bill

wrote in message news:5057625@discussion.autodesk.com...
INI files for user editable values may be fine, but this format for loading
external apps is practically unusable. Your installers will be required to
get the ECCCount, and then add your entries with the correct numbers. Not
too bad. But then your uninstaller needs to figure out which entry your app
is, and renumber any of the app entries that may have been added by another
party. Ahem. Is this doable? Sure, but that functionality has not been
provided and leaves developers to come up with a bunch of varied,
non-standard solutions to the problem.

For what it's worth, I went to an ADN day and asked about this "feature".
They are supposedly working on an improved mechanism, but did not give
specifics on how long we would have to wait.

Just a couple more ¢.