What is ACME?

CADchUP ACME is an autoloader for both BricsCAD and AutoCAD.

ACME is a tool for highly efficient LISP programmers. Just plug in your code and ACME does the rest, such as:

Check and load menu’s
Set search paths and trusted paths
Load the right code
- On CAD program start, and or
- On CAD document load
See section TAGS for more…

Plugging in your code is nothing more than creating a small text file with instructions what to do and when to execute.

And there is more:

No more burden of Autodesk plug in overhead.
With one LISP code base for both BricsCAD and AutoCAD…
- It solves the distance between these programs.
- Migrating from AutoCAD to BricsCAD is easy.
- It saves time and costs.
Executable (LISP) code is always run from the protected environment.
ACME is very easy to use without bloat and is extremely fast, decreasing start up times: mean and lean!

ACME primer

ACME is a tool to improve security in BricsCAD, applications for ACME need to be installed in the protected “ProgramFiles” environment.

ACME makes it very easy to build apps in BricsCAD and, in particular, AutoCAD: Simply define your app in a text file and the following is dealt with:

Automatic loading of CUI(X).
Automatic setting of support files search paths and trusted paths.
Automatic loading your code on program start and or on document loading.
Checking whether CAD versions and your application match.
And more, see TAGS below for current possibilities.

Because of letting ACME do all things around your LISP solution, it not only saves you time: You can concentrate on your product instead of dealing with these distracting and error prone CAD administration tasks.

ACME collects all information from apps, After that, all LISP code is executed in one sequence. ACME is a way to use common code: App_A contains code used in App_X and App_Y. By first loading App_A, it is assured that App_X and App_Y run smoothly. Just use alphanumeric naming. You are in charge and it is a great way to work around Autodesk’s autoloader mechanism.

The way ACME works:

ACME itself is launched from AutoCAD as a standard app and from BricsCAD as defined in on_doc_load.lsp – just as any other app.
- Optional, you can define an environment variable “StartACME”. If set to “TRUE”, ACME and all subsequent apps are loaded. If set to “FALSE”, ACME and all subsequent apps are completely ignored.
ACME reads your directions from “DeveloperProduct.acme” files in “%AppData%\ACME”. These .acme files are easy to make text files with instructions what to do and when to execute.
Write your instructions and ACME does the rest, forget about writing code for menu loading and setting paths.
At the right time, when starting the CAD program and or when loading a document, appropriate actions are executed according to your wishes.

What is handled by ACME?

A .acme text file is your wish list…
Lines are in format Tag "Value", where Tag is a symbol and "Value" is always a string. Tag and "Value" is separated by a space.
Tags are not case sensitive.
If you don’t need certain non mandatory tags, simply leave them out of the .acme file.
Some tags can be repeated because the tag is extensible, like TAG[EXT]. These tag values are processed in alphanumeric order.

For example, if you need one LISP program to start when loading a drawing, you can add a line like:

LoadOnDoc "RunMeOnDocLoad.lsp"

If you need two LISP programs to start when loading a drawing, you can extend the tag alphanumeric and write:

LoadOnDoc1 "DoThisFirst.lsp"
LoadOnDoc2 "ThenDoThis.lsp"

`TAG[EXT]`	`"VALUE"`	Remarks	Description
`ShortName`	`ExampleApp`	Mandatory	One word description.
`Name`	`"ExampleApp example utilities"`	Mandatory	Short description, published during loading.
`Description`	`"ExampleApp is a ... etc."`	Mandatory	Description, one line, published during loading.
`AppVersion`	`"0.1.0"`	Mandatory	Application version, published during loading.
`VendorName`	`"Example Corp."`	Mandatory	Name of vendor (you), published during loading.
`VendorUrl`	`"http://example.com"`	Mandatory	URL of vendor, published during loading.
`VendorEmail`	`"info@example.com"`	Mandatory	E-mail of vendor, published during loading.
`HelpFileLocal`	`"Help\manual.html"`	Mandatory	Local HTML help file under “ProgramFilesRoot“, optionally with a folder as prefix.
`HelpFileURL`	`"http://example.com/exampleapp"`	Mandatory	Internet help location.
`CADReleaseMin`	`"20.1"`	Mandatory	Application will not run when CAD release is less than this version.
`CADReleaseMax`	`"21.0"`	Mandatory	Application will not run when CAD release is above this version.
`CADPlatform`	`"3"`	N/A, Mandatory	Not implemented yet… Bit codes : “0” = Do not run app “1” = BricsCAD “2” = AutoCAD The sum of bit codes determines in which programs your app will be launched. For example, if 1, it runs only in BricsCAD, if 3 it runs on both platforms.
`ProgramFilesRoot`	`"ExampleCorp\ExampleApp"`	Mandatory	The root location for typical ProgramFiles files. In this example, ProgramFilesRoot evaluates to “%ProgramFiles%\ExampleCorp\ExampleApp“. From here you can create extra folders like “Help” and “LISP“.
`CodeDir`	`"Lisp"`	Optional	The location for LISP programs (as defined with tags LoadOnStart and LoadOnDoc). If LISP files are directly placed under ProgramFilesRoot (not recommended), do not use this tag. Otherwise, CodeDir is appended, i.e. “ProgramFilesRoot\CodeDir“. Whatever you choose, the location for code will be added to the trusted paths in case of AutoCAD.
`ProgramFilesSupport`	`"LispLib"`	Optional, Extensible	A support file location under folder ProgramFilesRoot. This location is added to the “Search File Support Path”. In this example, ProgramFilesRoot evaluates to a library with LISP programs in “%ProgramFiles%\ExampleCorp\ExampleApp\LispLib“. TRUSTEDPATHS NOT SUPPORTED YET!
`ProgramFilesTrusted`	`"LispUtils"`	N/A, Optional, Extensible	A trusted file location under folder ProgramFilesRoot. This location is added to “Trusted Paths” in case of AutoCAD. In this example, ProgramFilesRoot evaluates to a folder with LISP utilities in “%ProgramFiles%\ExampleCorp\ExampleApp\LispUtils“.
`AppDataRoot`	`"ExampleCorp\ExampleApp"`	Mandatory, limited	The root location for typical AppData files. In this example, AppDataRoot evaluates to “%AppData%\ExampleCorp\ExampleApp” which often boils down to “C:\Users\USERNAME\AppData\Roaming\ExampleCorp\ExampleApp“. From here you can create extra folders like “Menu“. This tag is only mandatory when the following is defined: `AppDataSupport` , `LoadUI` .
`AppDataSupport`	`"Blocks"`	Optional, Extensible	A support file location under folder AppDataRoot. This location is added to the “Search File Support Path”. In this example, AppDataSupport evaluates to “%AppData%\ExampleCorp\ExampleApp\Blocks“.
`AppDataTrusted`	`"UserLispUtils"`	N/A, Optional, Extensible	A trusted file location under folder AppDataRoot. This location is added to “Trusted Paths” in case of AutoCAD. In this example, “AppDataRoot” evaluates to a folder with LISP utilities in “%AppData%\ExampleCorp\ExampleApp\UserLispUtils“.
`NetworkSupport`	`"H:\CadUsers\Libraries\DirectAccess"`	Optional, Extensible	A support file location on the network (local location is fine too). This location is added to the “Search File Support Path”.
`NetworkTrusted`	`"D:\CadUsers\Lisp"`	N/A, Optional, Extensible	A trusted file location. This location is added to “Trusted Paths” in case of AutoCAD. In this example, “D:\CadUsers\Lisp” contains LISP utilities.
`LoadAtStart`	`"run_on_start.lsp"`	Optional, Extensible	Load this file on CAD program start. Multiple lines are permitted. It is expected to be under “ProgramFilesRoot\\CodeDir” (or “ProgramFilesRoot” when tag “CodeDir” is not used).
`LoadAtDoc`	`"run_on_doc_load.lsp"`	Optional, Extensible	Load this file on document load. Multiple lines are permitted. It is expected to be under “ProgramFilesRoot\\CodeDir” (or “ProgramFilesRoot” when tag “CodeDir” is not used).
`LoadUI`	`"Menu\ExampleApp"`	Optional, Extensible	Load this menu on CAD program start. Do not add an extension: “CUIX” is assumed in AutoCAD, “CUI” is assumed in BricsCAD. Location under “AppDataRoot“, optionally with a folder as prefix.
`CommandString`	`"._layer;_m;0;;"`	Optional, Extensible	When running LISP sequences at program start or on document load, you should not run CAD commands. Instead they should be added to function S::STARTUP for post execution. Tag CommandString can contain these commands with semicolons for “enter” keys. Since CommandString is extensible, it is better to use multiple tags than putting multiple commands in one string. The example issues a layer command, Makes and sets current layer 0 end ends with an empty extra return. Other examples: “ribbonclose;” and “menubar;1;”. Due to AutoCAD rejecting commands at program and document start, this tag is ignored for AutoCAD untill Autodesk solves this issue.

Tags Explained

LoadAtStart and LoadAtDoc

This tag needs some explanation first. LoadAtStart is only run once per CAD session, while LoadAtDoc is run when opening a document (new or existing). LoadAtStart is run first. LoadAtStart can pave a way by taking care of typical “once per session” settings like registry settings and defining global variables that can be used by LoadAtDoc. This way document loading can be speeded up, it is good programming practise and not new. BricsCAD and AutoCAD have files for these too:

When\Vendor	BricsCAD	AutoCAD	ACME
At program start	on_start.lsp	acad.lsp	LoadAtStart
At document loading	on_doc_load.lsp	acaddoc.lsp	LoadAtDoc

In AutoCAD, the standard behaviour of loading order is unpredictable. The order of the XML file is not by definition the load order. What is wanted is an order where first CAD system settings are handled and next document settings. That is what ACME takes care for behind the scenes. LoadAtStart only runs once per CAD session and before LoadAtDoc. That makes ACME attractive to use, in order to get rid of the annoying AutoCAD behaviour (BricsCAD does load in the right order by the way). For example, you can use (setvar registry-setting-x) in LoadAtStart, in order not to repeat it for every document by putting it in LoadAtDoc.

Troubleshooting

ACME collects information and takes action in a grouped way – doing all menu actions for all applications in one step, doing all search path modifications in one step, and so on. It is important to realize this. As a consequence, program loading and starting documents is pretty fast. The downside is that one bug in one application can terminate the complete sequence of instructions.

However, there is a positive side too: By reading which application causes error messages – the last action when pressing F2 – you can easily determine which application is causing trouble.

Now that you know this, you should disable this faulty application. The safest way is to simply rename its .ACME file into another extension: ApplicationX.acme becomes for example ApplicationX.acme.paused. These files are located in %AppData%\NedCAD\ACME\Apps. Start your CAD program to make sure no errors occur and contact the vendor for support. Needless to say an error in ACME itself is a possibility too, in which case you should contact us.