Tag Archives: Startup

A & B Tip 1 – clean slate

7 Replies

In this series of posts, I’ll be providing tips that show how to do something in both AutoCAD and BricsCAD, hence A & B.

The Series

The idea behind this series is to provide useful information for several sorts of reader:

  1. AutoCAD users.
  2. BricsCAD users.
  3. People in the process of transitioning from AutoCAD to BricsCAD and who need to know what to do differently (if anything).
  4. People considering transitioning from AutoCAD to BricsCAD and who want to know about the differences and similarities.

Clean Slate

This first post explains how to convince your CAD application how to start in a ‘clean slate’ state – i.e. bypassing all interruptions and starting with your default template drawing, all fired up and ready to go. But first, some history. If you just want to get to the meaty bit, skip down to Summary at the bottom.

History

Once upon a time, long, long ago, when you started AutoCAD you would be presented with a Main Menu like this:

Before you could start drawing or have access to any interface elements, customization or programming, you had to pass this virtual gatekeeper. This persisted long after most applications had discarded this approach, and it made AutoCAD look rather old-fashioned. Then, in 1992, Release 12 arrived, which discarded this menu. It just threw you into the drawing editor at startup. You could do what you wanted from there, no gatekeeper required. The masses rejoiced, because this made perfect sense.

Later, in AutoCAD 2000i, Autodesk had apparently forgotten what a terrible idea it was to have a gatekeeper and reintroduced one. A pretty awful one. Slow, ugly, obstructive, unconfigurable and programmed using entirely the wrong tools, it was an excellent example of how not to do an interface. Despite many complaints, it remained in place until AutoCAD 2004, when Autodesk regained its senses and discarded it again, to near-universal applause.

In order to prove that Autodesk’s corporate amnesia on this matter was a permanent condition, Autodesk would flip-flop several times over AutoCAD startup screens. Every time, the new workus-interruptus device was introduced with a fanfare, until a bit later when it was unceremoniously discarded. In some cases, the unlamented former best-thing-ever was replaced immediately by another, without even a single unobstucted release inbetween. I won’t bore you with the whole saga, but will instead take you forward in time to one step before what we have now.

AutoCAD 2015

AutoCAD 2015 introduced a thing called the New Tab. Start up AutoCAD and you would be presented with something like this.

To convince AutoCAD that you don’t want to see this, set the system variable STARTUP to 0 (the default is 3). (Note: the STARTUP system variable dates back to AutoCAD 2004, but its function has changed over the years). Assuming you have specified a default template file, the next time you start AutoCAD you will be placed straight into the drawing editor, ready to work.

If you decide you want to see the New Tab after all, you can always use the NEWTAB command to invoke it directly.

But wait! That’s not the end of the story. If you close the last drawing tab without closing AutoCAD, the New Tab will appear again. If you don’t want the delay associated with this (and in some environments that delay can be 30 seconds or more), you may wish to disable it altogether. To do this, set the NEWTABMODE system variable to 0 (the default is 1). Once you do this, not only will you not see the New Tab accidentally, you’ll also not be able to get to it intentionally, because the NEWTAB command will be disabled.

With NEWTABMODE=0, if you close the last drawing tab, you will be placed in a blank grey screen with very limited functionality, as in previous releases. If your menu bar is turned on (MENUBAR=1), a set of three pull-down menus (File/Window/Help) is visible.

AutoCAD 2016 to 2019

In AutoCAD 2016, the New Tab was tweaked and renamed. It became the Start tab. This was pretty much the same thing, but of course the commands and system variables changed. One thing that didn’t change was the STARTUP system variable, which you still set to 0 to go straight into a drawing.

One difference is that the Start tab is still displayed in the list of tabs even with STARTUP=0. Unlike AutoCAD 2015’s New Tab, the Start tab does not include an X to allow you to close it. Instead of the NEWTAB command, you use the GOTOSTART command to switch to the tab that’s already there.

To make to Start tab go away completely, you need to set the STARTMODE system variable to 0. With this done, you have the same situation as AutoCAD 2015 with STARTUP=0 and NEWTABMODE=0. You still need to configure your desired default template, of course.

While we’re still on AutoCAD, I should mention that there’s a command-line switch (i.e. it can be used in your startup shortcut) called /nologo, which prevents AutoCAD showing its logo on startup. I haven’t discerned any performance benefit in doing so, so I don’t bother. (Edit: YMMV – see comment below). You can also specify your startup template using the /t command-line switch.

Edit: I have covered /nologo’s effect on performance in more detail in the post A & B Tip 3 – benchmarking – /nologo or no?

BricsCAD

What about BricsCAD? Well, it has its own startup screen, but it’s not part of the drawing tab interface.

Like most things in BricsCAD, its faster than AutoCAD’s. It’s simpler, smaller and yet provides more functionality. For a brief overview on how it works, see Heidi Hewett’s post BricsCAD Journey – Part 3: Welcome to BricsCAD.

While I still prefer to work ‘raw’, I find the BricsCAD startup the least offensive of any I’ve used. I actually have a use for some of its features, particularly when setting up profiles, and so don’t turn it off until I get into real production mode with a new release. Then I make it go away.

It’s easy enough to turn off, using the Don’t show this window again toggle at bottom right. This is equivalent to setting the system variable GETSTARTED to 0 (the default is 1). That’s it. If you change your mind later, just set GETSTARTED back to 1.

What happens with GETSTARTED=0 is determined by the STARTUP system variable. If STARTUP=1 then the Create New Drawing wizard is launched:

You probably don’t want this either, so set STARTUP to 0. As in AutoCAD, you’ll want to ensure your default template drawing is specified so you go straight into a blank drawing. If you don’t do this, BricsCAD displays the Select Template dialog which you probably also want to avoid.

The default template drawing is defined by the BASEFILE system variable. You can set this system variable directly, or through SETTINGS > Program Options > Files > Templates > Template.

Summary

AutoCAD 2015

STARTUP = 0
NEWTABMODE = 0
OPTIONS > Files > Template settings > Default template filename for QNEW > [your template]

AutoCAD 2016 to 2019

STARTUP = 0
STARTMODE = 0
OPTIONS > Files > Template settings > Default template filename for QNEW > [your template]

BricsCAD

GETSTARTED = 0 or SETTINGS > Program Options > User preferences > Get Started
STARTUP = 0 or SETTINGS > Program Options > User preferences > Startup
BASEFILE=[your template] or SETTINGS > Program Options > Files > Templates > Template > [your template]

CAD Panacea tip – startup files in BricsCAD

3 Replies

One of the things that might initially baffle a CAD Manager or power user when investigating switching from AutoCAD to BricsCAD is how to set up the startup routines. Head over to CAD Panacea for R.K. McSwain’s concise, handy description of how to do it.

Due to BricsCAD’s high level of compatibility, you can maintain a common folder or set of folders containing LISP and other custom files for both applications. That way, you don’t need to do double maintenance during the transition period. I’ve done this successfully in a highly complex custom environment. Some code and other adjustments were required in places, but all but a handful of my hundreds of AutoCAD LISP files worked as-is in BricsCAD with zero effort.

Having added your AutoCAD custom folder(s) to BricsCAD’s search path, I suggest you make a common startup LISP file (e.g. rename your old acaddoc.lsp to something like CADStartupDoc.lsp) and have tiny stub startup LISP files for each application (acaddoc.lsp and on_doc_load.lsp) that each loads the common startup file.

acaddoc.lsp contents:
(load "CADStartupDoc")

on_doc_load.lsp contents:
(load "CADStartupDoc")

You can add error checking and messaging if you like, but if you have control of your environment you probably won’t even need that. If you find you do need any application-specific code, you can just add it or load it from the acaddoc.lsp or on_doc_load.lsp stubs as appropriate.

AutoCAD 2012 – Autoloader mechanism for plug-ins

16 Replies

One of the less obvious features introduced by AutoCAD 2012 is the Autoloader mechanism that has been provided to make installation of plug-ins (current standard Autodeskspeak for add-ons, apps, utilities, routines, etc.) easier for both developers and users. It may not be immediately obvious, but it’s a useful and important addition.

This mechanism has nothing to do with the AppLoad command, the Startup Suite, acad*.lsp, the (autoload) function or anything else that existed in earlier releases. This is completely new, it has not replaced or broken any of the existing loading mechanisms, and is, in short, A Good Thing. Developers don’t have to use it, but those who do, and their customers, will have certain advantages. I have used it for the ClassicArray loading mechanism, and I expect to see it used by more and more plug-ins over time. It works fine with all of the usual AutoCAD add-on APIs, including LISP.

User perspective
As a user, what this means is that for AutoCAD and related applications from 2012 on, there is a standard loading mechanism for plug-ins. The installation should be straightforward, with no multi-step processes to go through for different AutoCAD variants and releases. The result of the installation should automatically present itself in a standard way, with a short-lived welcome bubble, an extra panel in the new Plug-ins Ribbon tab, plus any other interface additions the developer wants to provide. If you subsequently install another AutoCAD variant or release, the plug-in will automatically appear in that variant with no further user action required, as long as that AutoCAD variant is supported by the plug-in.

Developer perspective
What this means for me as a developer is that I have much less to worry about in terms of installation. All that needs to be done to make the loading happen is for a folder full of ‘stuff’ to be copied into a certain location. (There are actually two possible locations, but more on that later).

In Betas of ClassicArray, I just provided the folder, plus instructions that asked the user to copy that folder into place. I could have simplified that further by providing batch files that did the copying. In the end, I created setup executables using the free Inno Setup utility, but that was a much easier job that it would have been if this Autoloader mechanism didn’t exist. I didn’t have to worry about discovering what releases were installed, deciphering Registry entries, creating user installaton scripts, or issuing instructions to users to edit files or mess with the AppLoad command. I don’t have to worry about what happens if the user subsequently installs another AutoCAD variant.

Of course, for developers who support releases prior to 2012, there is no less work to do than before, and some time needs to be spent to learn and implement the new mechanism. In the case of ClassicArray, that was not an issue because it’s only needed and supported in 2012. I expect this is one of those problems that will resolve itself over time as developers adopt the new mechanism.

The bundle folder
So what is this ‘stuff’ that needs copying into place? It’s called a bundle folder. It’s just a folder with a name that ends in .bundle (e.g. ClassicArray.bundle), and it typically contains the usual files needed to run your add-in, often tidied up within other folders. The only new thing that it needs to contain is a file called PackageContents.xml. That XML file is the key to the Autoloader mechanism. AutoCAD finds the file, reads it, and acts accordingly in terms of version support, loading program files, partial cuix files and so on.

Bundle folder location
So where does this folder with its XML file have to go? There are two possible locations. If you want the plug-in to be available to all users on the computer, you place it in the Autodesk\ApplicationPlugins folder underneath the system’s ProgramFiles folder. For example, ClassicArray usually gets put here:

C:\Program Files\Autodesk\ApplicationPlugins\ClassicArray.bundle

If you only want the plug-in to be loaded for the current user, it goes in the Autodesk\ApplicationPlugins folder underneath the system’s AppData folder instead, for example:

C:\Documents and Settings\[login]\Application Data\Roaming\Autodesk\ApplicationPlugins\ClassicArray.bundle

in XP or

C:\Users\[login]\AppData\Roaming\Autodesk\ApplicationPlugins\ClassicArray.bundle

in Windows 7.

Describing the contents of that all-important XML file is beyond the scope of this post, but I may do a follow-up post if there is enough interest. In either case, the reference material is available in the AutoCAD Help, under Help > Customization Guide > Introduction to Programming Interfaces > Install and Uninstall Plug-In Applications > PackageContents.xml Format.

What is loaded at AutoCAD startup, and when?

23 Replies

Warning, CAD nerd stuff ahead. This is a long and technical post and if you’re using AutoCAD in a largely out-of-the-box state you probably won’t care about any of it.

If your modification of AutoCAD extends beyond the trivial, you may find it useful to know what AutoCAD loads, and in what order things are loaded. It is possible for LISP files in particular to tread on each other’s toes, so knowing what gets loaded when can be useful information for diagnosing such clashes. This post aims to provide that information. It uses AutoCAD 2009 as an example, but the same principles apply to all releases from AutoCAD 2006 onwards.

On startup, the first things AutoCAD loads are its CUI files. It first loads the Enterprise CUI file, then the Main CUI file, then any partial CUI files attached to the Main, then any partial CUI files attached to the Enterprise. I have no idea of the reasoning behind this slightly strange order, but there it is. The order of the partial CUIs loaded in each case is determined by the order in which they appear in the parent CUI files, which is determined by the order in which you attached them. If you don’t like this order, you can attach and reattach them in the CUI interface, or you can do the same thing much quicker with a text editor if you feel confident enough. If there are LISP files associated with these CUI files, they are not loaded yet. You’ll need to wait a few paragraphs for that.

Next, if you have created a file called acad.rx in AutoCAD’s search path, any ARX files listed in that file will be loaded. There are other ways in which developers can load their ARX files at startup, but I won’t go into that here.

Following that, the acad*.lsp files are loaded. First, Autodesk’s acad2009.lsp file is loaded. Next, if you have created a file called acad.lsp, that is loaded. These two files are only loaded at first startup, unless the ACADLSPASDOC system variable is set to 1, in which case the acad.lsp file is reloaded with each new drawing. Next comes Autodesk’s acad2009doc.lsp and any acaddoc.lsp file you may have created, in that order. These two files are loaded at startup and with every new drawing session.

It’s worth pointing out here that the acad200x.lsp and acaddoc200x.lsp files are Autodesk’s and are not intended to be modified by users. You can modify them, and adding things in there works fine, but updates and hotfixes can overwrite these files, leaving you to patch things up again afterwards. The acad.lsp and acaddoc.lsp files are yours, and that is where you are best advised to put your additions.

I hesitate to mention VBA because I have long avoided that development environment and my knowledge in that area is very limited, but if you’re a VBA developer and have created an acad.dvb file in AutoCAD’s search path, it gets loaded at this point.

Once the acad*.* files are loaded, then come any LISP files associated with the CUI files that were loaded at the beginning. For each CUI file, if there is a *.mnl file of the same name, that will be loaded first (*.mnl files are just *.lsp files renamed). After that, any LISP files that are specified in the CUI file will be loaded, in the order in which they appear in the CUI file itself. This order can be modified in the same ways that the partial CUI loading sequence can be modified; “delete” and “load” (detach and attach, really) the files within the CUI interface, or hack the CUI file with a text editor.

The CUI-associated LISP files are loaded as described in the above paragraph for each CUI file in turn, in the same order as the CUI files themselves: Enterprise, then Main, then partials to Main, then partials to Enterprise.

The Appload command provides a Startup Suite facility, where you can specify any number of files to load (*.arx, *.lsp, *.dvb, *.dbx, *.vlx or *.fas). If you have done so, those files are loaded at this point, in the order in which they appear in the Startup Suite list.

That’s all the actual loading done, but we’re not finished yet. At this point AutoCAD’s environment should be all ready to do pretty much anything, including things that modify the drawing database, including invoking commands. This was not true earlier on, so if you want to do things like change the drawing or run commands, this should be done using a startup routine rather than called directly at load time from any of the files loaded above.

If you’ve defined a VBA sub called AcadStartup(), it will be called now. If starting a new drawing, any sub called AcadDocument_Activate() will be called instead. The caveat about my VBA ignorance still applies here.

If a LISP function called (S::STARTUP) has been defined, it will be called next. Where could that be defined? Anywhere in any of the LISP files mentioned above, or in any LISP or other files that are loaded by any of those files, or by any files that are loaded by any of those files, and so on ad infinitum. It could even be defined in one of the ARX files loaded at any point. This would be unusual, but is quite possible.

If there are multiple (S::STARTUP) functions defined in various places, which one wins? Whichever one loaded last. That’s why the load order can be important, but it’s also why you should never have an unconditional (defun S::STARTUP …) definition in your LISP code. Instead, you should append your startup code to any existing (S::STARTUP) function. That way, your startup can cooperate with any others in your environment rather than walking all over it. If there is some interest in that subject, I can cover it in more detail in a future post.

In summary, here is the AutoCAD startup sequence:

A. CUI files loaded:
1. Enterprise
2. Main
3. Partials to Main
4. Partials to Enterprise

B. acad*.* files loaded:
1. Files listed in acad.rx
2. acad2009.lsp
3. acad.lsp
4. acad2009doc.lsp
5. acaddoc.lsp
6. acad.dvb

C. CUI-associated MNL and LSP files loaded:
1. Enterprise named MNL
2. Enterprise loaded LSP and MNL
3. Main named MNL
4. Main loaded LSP and MNL
5. Partials to Main named MNLs
6. Partials to Main loaded LSPs and MNLs
7. Partials to Enterprise named MNLs
8. Partials to Enterprise loaded LSPs and MNLs

D. Startup suite files loaded

E. Startup routines run:
1. AcadStartup() called (AutoCAD startup)
2. AcadDocument_Activate() called (Drawing startup)
3. (S::STARTUP) called