Category Archives: Development

Old news – shipping version of ClassicArray released

I have been somewhat neglectful of this blog lately, including a failure to mention that my ClassicArray™ plug-in for AutoCAD 2012 has been shipping since 1 May 2011. Thank you to those people from various places around the world who have been prepared to go to the effort of registering and paying for the product.

Here are some details of the product taken from the ClassicArray page:

ClassicArray is a simple-to use but powerful tool for creating arrays in AutoCAD.

  • Provides a dialog box interface to AutoCAD 2012’s Array command. The familiar interface method provides continuity with earlier releases.
  • Supports the creation of both associative and traditional non-associative arrays.
  • Provides an in-dialog preview panel to give you a quick idea of what your array will look like before any objects are created.
  • Allows creation of a preview array which can be accepted, rejected or modified before the desired array is finally chosen.
  • Base objects can be incorporated into the array or left intact as desired using a simple toggle.
  • Allows simple creation of 3D arrays.
  • Comprehensive Help is available from within the dialog box.
  • Provides Ribbon tabs and toolbars, separated into associative and non-associative sections.
  • Setup routines are provided that support either all users (requires admin rights) or the current user (no admin rights required). Uninstallation is via the standard Windows Control Panel methods (Uninstall a Program, Add/Remove Programs).
  • Uses AutoCAD 2012’s new Plug-in feature to provide application behavior consistent with other add-ins.
  • Acts as a workaround for various AutoCAD 2012 Array bugs and limitations.
  • Supports AutoCAD 2012 for Windows and vertical products derived from it. Sorry, due to Autodesk API restrictions ClassicArray can support neither AutoCAD LT nor AutoCAD for Mac.

See the ClassicArray Help page if you want to see a full description of the product, including screenshots.

One more thing I should mention is that if you have used one of the Beta versions of ClassicArray, please make sure you uninstall it and install the shipping version before registering the product.

AutoCAD 2012 – Autoloader mechanism for plug-ins

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.

ClassicArray Release Candidate 2

I have now posted the second Release Candidate of ClassicArray™ (version number 0.7.0). The main changes from the first Release Candidate (0.6.0) are:

  • Help documentation, which you can also view here, now describes how to resolve an AutoCAD CUIx loading problem. (The problem is not specific to ClassicArray and can affect any CUIx file that is removed or relocated. More on that in a future blog post).
  • Timebomb mechanism now works 15 days after first use rather than a specific date. Also now allows the interface to still be used (but no arrays to be created) once the evaluation period has expired.
  • About dialog enhanced to show registration information and to provide access to a new registration dialog.

Barring disasters, I intend to release ClassicArray in this exact form (except for updating the version number to 1.0.0) in about a week.

Please see either www.classicarray.com or the main ClassicArray Beta post for the download, and provide feedback either as a comment on that post or in an email.

ClassicArray Release Candidate – massive download bloat

I have just posted the Release Candidate of ClassicArray™ (version number 0.6.0). The main changes from Beta 2 (0.5.0) are:

  • Setup executables have been provided to provide easier installation and uninstallation.
  • Pretty comprehensive Help documentation is now in place, which you can also view here if you want to learn about the product without installing it.
  • Bug fixed with Path preview not displaying accurately when no path is selected.
  • Minor cosmetic dialog box fixes.
  • Timebomb has been moved on 7 days to 28 April.

Regrettably, the download file size has blown out to 787 KB because of the inclusion of the Help files and setup executables. There are two setup choices; one for all users (requires admin rights) and one for the current user only (admin rights not required). When installing the Release Candidate, it is not necessary to uninstall the Beta first. I would appreciate any feedback you might have, particularly on installation and uninstallation. If there are no significant problems reported with this version, I intend to release it in this form, except for version information and the timebomb mechanism.

Please see the main ClassicArray Beta post for the download, and add any comments there.

ClassicArray pricing proposal

I am considering the following pricing model for ClassicArray™ when it’s released:

Individual licenses: $12
Up to 20-user license: $100
Up to 50-user license: $200
Up to 100-user license: $300
Unlimited site license: $500

Prices in US$, payment by PayPal, delivery by download only. Australian purchasers would have to pay 10% GST on top of that.

Comments? Suggestions?

ClassicArray Beta 2 (0.5.0)

I have just posted the second public Beta of ClassicArray™ (version number 0.5.0). There are some documentation updates (still no Help, though), and the main changes are:

  • Bugs fixed with rectangular arrays where single-row and/or column arrays confused AutoCAD.
  • The command now remembers its settings from one invocation to the next, within a single drawing session.
  • Timebomb has been moved on 7 days to 21 April.

The ReadMe.txt file in the zip explains how to uninstall the old version. Simply delete the old ClassicArray.bundle folder from the place you put it. Replace it with the new ClassicArray.bundle folder from the later zip file. Then try to break it!

Please see the main ClassicArray Beta post for the download, and add any comments there.

AutoCAD 2012 – ClassicArray Beta

People have already started to notice that AutoCAD 2012 has killed the dialog box interface for the Array command, and not everybody is happy about it. So I guess it’s time to launch ClassicArray™ Beta.

ClassicArray is an add-on for AutoCAD 2012 for Windows that allows the creation of arrays using a dialog box interface similar to that provided in AutoCAD from 2000 to 2011, but enhanced to include new AutoCAD 2012 functionality. I will create another post later have created a Help page that describes ClassicArray more fully, but for now here are the commands ClassicArray adds to AutoCAD:

ClassicArray (short form CA)
ClassicArrayRect (short form CAR)
ClassicArrayPolar (short form CAP)
ClassicArraypAth (short form CAA)

In addition, there are the same names with N appended, which default to creating non-associative arrays. For example, ClassicArraypAthN (short form CAAN) will create a non-associative path array. However, it is easy to create associative or non-associative arrays of any type, whatever command you use to start it. Toolbar and Ribbon buttons are provided. Help is currently non-functional now complete. This pre-release software is time-bombed, meaning it will no longer work after the date shown below.

Here it is to download:

ClassicArray.1.0.0.zip (Shipping product – 850 KB – will not create arrays after 15 day evaluation period
ClassicArray.0.7.0.zip (Release Candidate 2 – 850 KB – will not create arrays after 15 day evaluation period)
ClassicArray.0.6.0.zip (Release Candidate – 787 KB – will not work after 28 April 2011)
ClassicArray.0.5.0.zip (49 KB – will not work after 21 April 2011)
ClassicArray.0.4.2.zip (48 KB – will not work after 14 April 2011)

It’s a small zip file; unzip it and read the readme to see what to do with it run the setup routine of your choice, depending on whether you want to install it for just the current user or for all users. Installation is a matter of simply copying a folder to a specific location; uninstallation is simply a matter of removing that folder. The mechanism I used for this is AutoCAD 2012’s new Plug-In feature. This feature is A Good Thing that deserves to be described more fully, which I intend to do when I get the time.

This is pre-release software. It generally works fine, but it will contain bugs. Please let me know about them, either in a comment here or using my email form. Over time, I expect to update this post with later versions, so I would appreciate it if you let me know the version number along with any other relevant information, such as the AutoCAD variant and OS you have installed it on. If you have any suggestions, of even if it works without problems, please feel free to let me know that, too!

Autodesk for Mac – the hole story

You may remember my pre-release speculation about what was likely to be missing from the Mac version of AutoCAD 2011. It turns out that my list was pretty accurate as far as it went, but very incomplete.

In a move that I can only applaud, Autodesk has now published its own list of missing Mac features. It includes this statement:

Although AutoCAD 2011 for Mac is based on AutoCAD 2011, it was written to be a native Mac application. As such, it is a new and separate product and not simply a port from the Windows version. In the first release of this new product, there are some features and functionality that exist in AutoCAD 2011 that are not yet available in AutoCAD 2011 for Mac, including (but not limited to):

This is followed by a list of over 80 holes in the product. Many of them are minor, but the number of absent but important features is quite an eye-opener. I really can’t imagine anyone who is used to the Windows-based product being content with AutoCAD for Mac 2011 if forced to switch by a Apple-centric boss. Hardware, great. OS, fine. App, not so much. I expect future releases will gradually fill many of those holes, but Autodesk isn’t promising that. For now, I can state that at least one of my dire predictions was spot-on. AutoCAD for Mac is indeed half-baked.

Autodesk has stated that the Mac version is the same price as the Windows version, despite being incomplete, because Mac users (particularly architects) won’t notice the missing stuff. That may be true (if somewhat insulting to architects and fanboys) or not, but it definitely doesn’t apply to the rest of us.

Existing AutoCAD users, have a look at the list. What in there would be a dealbreaker for you? From my own CAD manager point of view, I can see about a dozen killer omissions, with the API holes at the top of the pile. No DCL support, for example? Wow.

Executive summary of Deelip’s AutoCAD for Mac interview

Deelip has just published an extensive interview with several Autodesk people about AutoCAD for the Mac. Deelip had a good set of questions and I suggest you read the whole thing, but if it’s all too tl;dr for you, then here is the lazy reader’s version of what Autodesk had to say:

  • The AutoCAD code was split up into 3 sections: the core CAD engine (platform-independent), the Windows-specific (MFC) parts and the Mac-specific (Cocoa) ones.
  • AutoCAD for Mac is incomplete. Choosing which features to leave out was done with the aid of CIP (oh, dear) and Beta feedback. (Hang on a minute, I thought CIP said most people were using the Ribbon…)
  • No comment on when or if AutoCAD for Mac functionality will catch up with its Windows counterpart.
  • No comment on the stability or performance of the Mac version.
  • Buying Visual Tau wasn’t a complete waste of money.
  • If Mac users want Windows-level functionality, they should use Bootcamp.
  • The Mac version is intended to expand the AutoCAD market to those Mac users who are frustrated by Bootcamp or who find it too hard.
  • Some mind-blowing spin was attempted in a valiant but vain attempt to explain away the Ribbon = productivity, Mac <> Ribbon marketing problem. You will really have to read it for yourself, as I can’t do it justice here. But “just because 2+2=4 doesn’t mean 4-2=2” will give you some idea of what to expect.
  • The Mac version is the same price as the Windows version, despite being incomplete, because Mac users won’t know or care about the missing stuff.
  • There are no plans for a Linux port, or any other platforms.
  • Autodesk will wait and see how AutoCAD for Mac does before porting any of the vertical products. (Very sensible).
  • Autodesk closed off the AutoCAD for Mac Beta program on announcement day because it wouldn’t have been able to cope with the mass of feedback from new users.
  • Autodesk will not allow dual use (Windows + Mac) licenses. If you want to have both products available to you, you will need to buy the software twice.
  • You can cross-grade AutoCAD from Windows to Mac for a nominal fee, or for nothing extra if you upgrade at the same time. (Although at 50% of the retail price of a whole new license, such an upgrade hardly represents a bargain).
  • Autodesk really doesn’t have any idea what is going to happen in the Mac CAD marketplace. (Refreshingly honest).
  • Little comment on why AutoCAD WS is called AutoCAD, other than iOs users not expecting their apps to do much anyway, plus it’s “part of the AutoCAD family.”
  • WS doesn’t stand for anything.

Another language pack cleanup solution

My CADLock, Inc. colleague, Owen Wengerd has posted about a fix utility he has written to help clean up drawings infested with the language pack problem discussed here. I have not yet tested Owen’s utility*, but as this should run in any AutoCAD-based product from 2007 on, it could well be a better partial solution than Autodesk’s Civil 3D-only (so far) patches. Autodesk still needs to sort out its dodgy templates, of course, and should probably provide its own non-Civil 3D fixes, if only to maintain a little corporate self-respect.

As Owen has a long and distinguished history of being consistently and demonstrably better at AutoCAD programming than Autodesk’s own programmers, I’d be tempted to try this one first. However, Civil 3D users should probably apply the patches and updates anyway to help resolve other issues.

To find Owen’s utility, go to the ManuSoft ARX freebies page and look for CleanLanguage.zip. While you’re there, use the Software menu to check out some of the other stuff Owen has done.

* Edit: I have now tested it, and it works beautifully in both AutoCAD 2010 and Civil 3D 2011.

Civil 3D 2011 ANZ comes complete with “virus”

If you install Civil 3D 2011 using the ANZ (Australia/New Zealand) profile, when you start it up for the first time, you will see a large warning indicating that the drawing requires an Asian language pack to be installed. It also warns that this is a symptom of the acad.vlx virus:

Language Pack warning

Now I know that in this case it’s not an actual virus causing the problem, but rather the ANZ template drawing being “infected” with this Language Pack requirement. I have had to deal with quite a few incoming drawings in this state, and that’s painful enough without Autodesk also infecting every Australasian Civil 3D drawing with the problem. Other profiles may be similarly infected, but at the moment I don’t know. Edit: Matt Anderson reports that the problem occurs on US systems too.

Autodesk, I suggest that as a matter of great urgency you create a clean ANZ template file, post it as a hotfix and warn all your Civil 3D customers of the SNAFU. Neither “install the language pack” nor “turn off the warning” are adequate workarounds. Your customers do not want to send out or receive any drawings in this state.

Beyond the immediate issue of Autodesk shipping software that on first use warns the user that they may have a virus (and encourages the creation of drawings that spread that warning far and wide), I would appreciate some assistance in dealing with “infected” drawings, whether in Civil 3D or plain AutoCAD.

First, I need to be able to detect such drawings using LISP so I ensure they are rejected rather than allowed into our drawing management system, and this detection will need to work in releases at least as far back as AutoCAD 2004.

Second, I need a mechanism of cleaning up such drawings. The only thing I have discovered that works so far is the manual, time-consuming and dangerous process of recreating the drawings by starting from scratch and Copy/Paste in each layout. With big jobs using nested xrefs, this is fraught. I need to be able to provide a LISP-based cleanup mechanism that I can set up to work in batch mode on a set of drawings.

I would be grateful for any clues anyone might have about the above detect & cleanup needs.

Edit: see the comments for further important information.

Programmers, have your say

Autodesk wants your input in its annual API survey. What used to be a closed survey for Autodesk Developer Network (ADN) members has been open to all for the last couple of years, and if you do any Autodesk-based development at all I encourage you to take part. Yes, that includes those of us who do most of our development in LISP. In fact, I am especially keen to see LISP developers adequately represented in this survey.

This is a one-page survey and it doesn’t take long. The full list of API surveys is on Kean Walmsley’s Through the Interface blog. Most of you would be interested in the AutoCAD survey, so here’s a direct link to that.

Kean assures us that our feedback will not fall on deaf ears, although I have yet to see any evidence of that in terms of any change to Autodesk’s decade-long policy of total LISP neglect. I guess many of us gave up hope of any improvement years ago and can’t be bothered providing feedback any more. Please don’t give up. Fill in the survey and let Autodesk know you still exist.

Filling the holes in Autodesk’s CHM Help stopgap

It was good to see Autodesk react to criticism of AutoCAD 2011’s browser-based Help with an acknowledgement of the problems and an attempt to provide a workaround by making a zip file of CHM files available for download. That’s much better than ignoring people’s concerns, denying the validity of those concerns or shooting the messenger, which has been known to happen in the past.

However, there are some holes in the workaround, only some of which can be filled.

  • Under 64-bit Windows 7, the Search pane is blank, as it is in the CHM Help for earlier releases on that platform. This is stated on the download page. Index works well, but Search doesn’t. As Search is one of the worst aspects of the browser-based Help, this is a rather unfortunate.
  • There is no obvious way of making the CHMs provide contextual help. Don’t bother pointing at acad181.chm in the Files tab of Options, it doesn’t work. Edit: See Chris Cowgill’s post on the AUGI forums for a partial workaround.
  • Even without contextual help, no advice is provided for calling the CHMs from within AutoCAD; you are only told that you can set up a shortcut on your desktop and double-click on that when you need it. However, you can set up an alias command in AutoCAD. To do this, edit the acad.pgp file or use the Express Tools Aliasedit command to set up a shell command. The alias name can be whatever you like (e.g. HEL), the command name should simply be the path and filename of the main acad181.chm file.
  • The CHM files are currently available only in English.
  • The set of CHM files is incomplete. See below for more details and what you can do about it.

These are the CHM files provided with AutoCAD 2011:

acet.chm – Express Tools
AdRefMan.chm – Autodesk Reference Manager
adrefmanctxt.chm – Not to be launched manually
ole_err.chm – Not to be launched manually
webbrw.chm – Not to be launched manually

These are the CHM files provided in the zip file download:

acad181.chm – Main AutoCAD 2011 Help file
acad.readme.chm – Readme
acad_acg.chm – Customization Guide
acad_acr.chm – Command Reference
acad_aug.chm – User’s Guide
acad_dpg.chm – Driver and Peripheral Guide
acad_install.chm – Installation
acad_nfw.chm – New Features Workshop
adsk_lic.chm – Licensing

These are the CHM files that are missing:

acad_aag.chm – ActiveX and VBA Developer’s Guide
acad_alg.chm – AutoLISP Developer’s Guide
acad_alr.chm – AutoLISP Functions
acad_alt.chm – AutoLISP Tutorial
acad_car.chm – Connectivity Automation Reference
acad_dev181.chm – Developer Documentation
acad_dxf.chm – DXF Reference
acad_sso.chm – Sheet Set Objects Reference
acadauto.chm – ActiveX and VBA Reference
adsk_brw.chm – Licensing – (this appears to be a later version of adsk_lic.chm).

Do you need any of the above? I did. To obtain a full set of AutoCAD 2011 CHM files, I had to do the following:

  1. Download a vertical AutoCAD 2011-based variant. I used AutoCAD Civil 3D 2011, because I am entitled to download that from the Subscription Center. You may need to download an evaluation copy of a vertical. If so, make sure you delete the files after your evaluation period of 30 days, won’t you? Hopefully, Autodesk will have provided a better workaround by then.
  2. Double-click on the downloaded executable (which is actually a self-extracting archive). You will be prompted for a location for the files to be unzipped to. I accepted the default of C:\Autodesk\AutoCAD_Civil3D_2011_English_32bit.
  3. After the unzipping process is complete, the installtion window will appear. Pick Exit; you do not need to go ahead with the whole installation.
  4. Search for the CHM files in the unzip location. There are a variety of locations, some of them containing duplicate files, but I was able to find what I needed in C:\Autodesk\AutoCAD_Civil3D_2011_English_32bit\x86\en-US\C3D\Acad\Help.
  5. Copy the files from here to a safe location, and set up shortcuts and/or alias commands to access them.

Note that I can’t vouch for the completeness or correctness of these files (which may be why Autodesk didn’t include them), but I can’t do that for the HTML versions either. For those of you in non-English-speaking locations, I would be interested in finding out if you can use this method to obtain non-English CHM files. Are there non-English AutoCAD 2011-based verticals available for download yet? If so, are the CHMs in your language?

Finally, if you are having trouble reading CHMs over a network, check out this Microsoft document on a security update that may be the cause.

CAD International interview on drcauto and other subjects

This morning I spoke with CAD International‘s Nigel Varley. Here is a paraphrased summary of the interview.

SJ: When did CAD International buy the drcauto intellectual property rights?
NV: About two weeks ago.

SJ: You are currently helping drcauto customers with authorisation codes, is that correct?
NV: Yes, masses of them. It’s taking up a lot of our peoples’ time.

SJ: Are you charging for this service?
NV: Not at present.

SJ: Do you intend to charge for this service in the future?
NV: Maybe. We may need to, both to pay for our time and to recoup our investment. I don’t particularly like the idea of annual renewals for software, so we may do something different in future.

SJ: If somebody wanted to buy drcauto products such as LT Toolkit now, could they do so?
NV: No, we’re still processing the materials we were given when we bought the rights. It wasn’t left in a well-organised state. I’m not sure if that was done deliberately or if it was just like that.

SJ: Do you have any plans to continue development of LT Toolkit or the other drcauto products?
NV: It’s too early to say at this time. I understand it doesn’t work right now with AutoCAD LT 2010 with Update 2 applied, or on 64-bit Windows, or on Windows 7. It’s not clear at this stage how much work is involved in making it work. It should be doable, but we can’t make any commitments at this stage.

SJ: So do you have a timeframe for doing any of this stuff?
NV: No, it’s too early. We’re still processing it.

SJ: What about former drcauto employees helping people out with authorisation codes?
NV: They have no rights to do that. They don’t own the intellectual property, we do. People need to be very careful.

SJ: Are you contemplating legal action?
NV: I think I’ll keep that under my hat for now.

SJ: Do you foresee any problems with Autodesk if you go ahead with LT Toolkit?
NV: I don’t think so. Autodesk would be pretty naive, with competing products around at a lower price than LT and with LISP built in, to think that they would gain any sales by blocking LT Toolkit. They would just be shooting themselves in the foot.

SJ: Autodesk has always been strongly opposed to products like LT Toolkit. Are you concerned about legal action from Autodesk?
NV: Well, people say that Autodesk has been against it, but I haven’t seen any evidence of that. When I spoke to the late Gary D’Arcy he told me that Autodesk had never once even contacted him to try to get him to stop developing it.

On Deelip’s blog there has been some discussion about resellers and what they should be allowed to do, so I asked some questions along those lines.

SJ: What is the relationship between CAD International in the USA and Australia?
NV: We’re an Austalian company, moving into the US marketplace for those people in the USA who want to buy our products. We don’t have offices in the USA, but we do have people on the ground.

SJ: Is CAD International an authorised AutoCAD reseller?
NV: No. We’ve been selling Autodesk products for 15 years without a direct relationship. We buy from Scholastic like everybody else in the same position. It’s not worth becoming a dealer; the obligations are too great and the margins are not worthwhile. We’ve been asked on several ocasions over the years and always said no.

[Note: I’ve since read (in something written well before this issue was raised here) that Autodesk Australia intends to tighten up the reseller situation in the very near future. These things go in cycles, and have for the last 25 years.]

SJ: Does Autodesk have a problem with you promoting competing products such as Bricscad?
NV: They have never spoken to us about it in the past, but as we don’t have a direct relationship with them it’s not surprising.

SJ: I see from your web site that you are selling DWG TrueView for $195. Isn’t that a free product?
NV: That fee is for supply services; research services if you prefer. People can download it from Autodesk if they like or get it from us. We just put it on the site as a trial to see if anybody wanted to buy it.  Nobody has, yet.

SJ: I can’t say I’m greatly surprised by that. Has Autodesk contacted you about this issue?
NV: No, we’ve heard nothing from Autodesk. They don’t really care about us, we’re a pretty small player in the market.

[Edit: the $195 price tag has since vanished from the site.]

Hope for drcauto LT Toolkit orphans

LT Toolkit from the now-defunct drcauto was an add-on for AutoCAD LT that provided LISP and other capabilities that Autodesk disabled. Autodesk hated this, of course, but the late Gary D’Arcy made sure everything was done legally so it couldn’t be stopped even by Autodesk’s hyperactive legal team.

If you are a user of LT Toolkit and you want to keep using the software now the company has closed down, you may find this information from Evan Yares useful:

I’ve gotten in contact with Leonard Liang, the former key developer at DRCauto. He’s asked me to send any Toolkit Max users to him, and he will help them. His website is www.cadsta.com. His email, at that domain, is “leonardl”.

Source: a comment in this this WorldCAD Access post. If you don’t read comments, you may well have missed this, so I thought it was worth repeating.

Edit: events have overtaken this news since it was written. Please see here and here.

(Don’t) Ask Autodesk a question

If you had a real live Autodesk development person standing in front of you right now (an AutoCAD Product Manager, for example) and were allowed to ask one question, what would it be?

Please add a comment here with your question. I would ask that you keep your question civil and reasonably concise (one or two sentences), and bear in mind that the development person in front of you isn’t going to have a useful answer to policy questions about pricing, license agreements, customer service and so on. Other than that, anything goes, so let’s have ’em.

I can’t promise that your question will get answered, but I’ll see what I can do.

Note: comments are now closed, as this post keeps getting mistaken for an ongoing mechanism for asking Autodesk questions.

Autodesk discussion group alternatives

As I’m typing this, the Autodesk discussion groups are down for maintenance again. Let’s hope that when they come back up, some of the problems are fixed.

In the meantime, if you’re an AutoCAD user and have something to ask or say, where can you go? Here are a few suggestions.

  • I like the AUGI forums. It’s an even more modern, more graphical and less space-efficient web interface than the new Autodesk one, but there’s a good community there and, hey, the search feature works. Mike Perry and colleagues run a tight ship, so please read the rules and be good.
  • If you have something to tell Autodesk and want practically no restrictions in the way you say it, submit a new message on dear Autodesk, or vote for the existing messages you like. It’s looking a bit bare and empty at the moment, so go fill it up.
  • As a Cadalyst person, it would be remiss of me to avoid mentioning the Cadalyst forums.
  • The Swamp is biased heavily toward CAD programming, so if you have a LISP question then head there, but it also hosts general CAD discussion. In this community, you are expected to be courteous and professional.
  • Old-timers like myself will remember that the CompuServe ACAD forum’s Take 5 section was carried over into the AutoCAD discussion groups. It was kept going for a few years before Autodesk felt it was getting out of hand and killed it. That community refused to be killed, and actually still flourishes for newsgroup (NNTP) users at the t5 dot dynip dot com server.
  • R. K. McSwain suggests the CADTutor forums.

If you wish to point out any other sites I’ve missed, please let me know and if they’re relevant I’ll edit this post to include them.

While I was typing this, the Autodesk discussion groups came back up, but who knows how long that’s going to last?

Also while typing this I also received a phone call from a helpful Indian gentleman at Subscription Support (which was working fine as of yesterday). He asked for details about the broken search (it doesn’t find anything posted prior to the update), confirmed that it’s broken, and promised to inform the relevant department. That’s a much better response than the email I mentioned in my last post.

What is loaded at AutoCAD startup, and when?

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

Where have all the developers gone?

I noticed in Ralph Grabowski’s latest upFront.eZine that Autodesk has announced that 100 developers have 200 add-ons working with its 2009 series of software. I hope I’m not supposed to be impressed by those numbers. I remember when Autodesk boasted about having over 3500 third-party developers. What happened to the other 3400-odd? This is a serious question; if anybody knows where they all went, and why, I’d love to know.

Of those two hundred 2009-ready applications, how many of them take advantage of 2009’s Big New Feature, the Ribbon? My guess would be close to zero. Why? Because the AutoCAD 2009 CUI architecture is all wrong. Adding custom stuff to the Ribbon is simply a lot more trouble than it’s worth. Even Autodesk’s own vertical teams have shunned it.