A normal Windows application might accomplish install-time registration by calling RegSvr32 after the files are copied to the destination folder, but this doesn’t work with ObjectARX or BRX modules. The reason it doesn’t work is because ARX modules cannot be loaded outside the AutoCAD or Bricscad process. RegSvr32 will fail with errors like “The module <filename> failed to load” or the even less helpful “The specified module could not be found.” There are some kludgy ways to get RegSvr32 to work anyway, but the simplest and most reliable way to solve this problem is to forget RegSvr32 and just add the needed registry values manually into your installer script. It’s not difficult, though it might be time consuming initially if your server implements a lot of COM objects.

At a minimum, a COM server must register at least one COM class under HKCR\CLSID. If the COM server needs to support OLE Automation (e.g. VBA, AutoLISP) it must register a type library in HKCR\TypeLib. In most cases, this is all that is needed, however you may also need to register a “ProgID” in HKCR if a script or in-process module needs to be able to connect to the server via human-readable ProgID.

Most installation script software can import Windows registry script (.reg) files, so it’s often helpful (and more maintainable) to create a registry script file manually, then simply import the .reg file into the installation script. If you use Visual Studio deployment projects, this is the only way to batch import registry values into the installation script. I’ve provided a minimal template for a registry script that registers a single COM object and ProgID. The template uses special characters as placeholders for the actual values: $$ is the human readable ProgID name, ## is the COM object’s CLSID, ** is the filename of your ARX module, and %% is the type library GUID. The type library and object class version numbers should match your actual version numbers as well, and of course [TARGETDIR] is the installation target directory that will be resolved at install time.

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\$$.1]
@=”$$ Class”

[HKEY_CLASSES_ROOT\$$.1\CLSID]
@=”{##}”

[HKEY_CLASSES_ROOT\CLSID\{##}]
@=”$$ Class”

[HKEY_CLASSES_ROOT\CLSID\{##}\InprocServer32]
@=”[TARGETDIR]**.arx”
“ThreadingModel”=”Apartment”

[HKEY_CLASSES_ROOT\CLSID\{##}\ProgID]
@=”$$.1″

[HKEY_CLASSES_ROOT\CLSID\{##}\Programmable]

[HKEY_CLASSES_ROOT\CLSID\{##}\TypeLib]
@=”{%%}”

[HKEY_CLASSES_ROOT\CLSID\{##}\VersionIndependentProgID]
@=”$$”

[HKEY_CLASSES_ROOT\TypeLib\{%%}]

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0]
@=”$$ 1.0 Type Library”

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\0]

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\0\win32]
@=”[TARGETDIR]**.arx”

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\FLAGS]
@=”0″

[HKEY_CLASSES_ROOT\TypeLib\{%%}\1.0\HELPDIR]
@=”[TARGETDIR]“

It’s really not that complicated for a single module. The work can be tedious to create all the values for multiple modules in scenarios where you support multiple AutoCAD and/or Bricscad versions or platforms, but these values typically don’t change over the life of the project, so it only needs to be done once. Once you have created the registry values manually, disable all other forms of COM server registration such as wizard-generated runtime registration or automatic “self-registration” at install time. A bonus side effect of the manual registration approach is that a normal uninstall reliably removes all traces of the COM server registration.

With some experimenting, I found that my Motorola Droid 2 Global from Verizon can be tethered just fine right out of the box, and without paying anything extra.

Recently I’ve been playing nursemaid to my ill mother, so I frequently take my work along with me on overnight shifts. I’ve settled on connecting to my main desktop machine via remote desktop, and using my 15″ laptop as the client.

The remote desktop connection works great. My 3G connection is noticeably slow, but it’s very workable. Since I’m working on my office computer, there’s no need to sync anything, and I can pick up from one place right where I left off in another. In a pinch I can even use my phone as a client (using an inexpensive remote desktop client from Xtralogic).

To get my internet connection, I installed Motorola’s drivers on my Windows 7 laptop, then enabled the Bluetooth controller on my phone and paired it with the laptop. Now I can connect my laptop to the internet via Control Panel simply by connecting to the phone as an “Access Point”, as shown below.

Connecting to my Droid 2 Global via Bluetooth

I don’t know whether this technique works for other phones or other carriers, but it has certainly worked well for me.

I assumed that one of my piddly little changes must have unleashed a dependency that sucked in the entire MFC library, which is exactly what happens in VS 2010. To test this hypothesis, I rolled back all my changes to the previous build state and did a complete rebuild. No change; the executable was still 2 MB. Wonderful.

It turns out a recent Visual Studio update (delivered automatically via Windows Update in my case) “broke” the VS 2008 MFC files, so they now suffer the same massive bloating problem that VS 2010′s MFC library suffers from. I applied the solution mentioned in this blog post (actually in my case I only needed to hack the afxglobals.cpp file). Now the MFC balloon is deflated again and my file sizes have dropped back to normal.

[Update 1: Ted has now tracked down more specifics about this problem and posted a cleaner solution.]

[Update 2: Microsoft has now fixed this problem at the source with updated patches.]

If you link statically to MFC with VS 2008 or VS 2010 in any of your projects, check your executable sizes now.

Installing Ubuntu was straightforward, and I had no problems. Installing Bricscad went off without a hitch. I downloaded the Debian package of Bricscad v11 Pro and Ubuntu’s Software Center installed it much like Windows Installer would install an MSI file on Windows.

Bricscad v11 on Ubuntu Application Menu

After installation, Bricscad fired right up. Except for a mysterious black splotch in the layer dropdown, it looked and felt very much like Bricscad on Windows.

Black Splotch on Bricscad Layer Dropdown

The next order of business was to build and load a BRX module. I started by installing Code::Blocks, an open source cross platform C/C++ IDE that can be used in both Windows and Linux. The IDE installed fine, but then things got interesting.

First of all, I found that I had to install the build tools (namely the g++ compiler), because they are not included with the IDE. Eventually I had to set an environment variable for my BRX project pointing it to the BRX SDK, which required a Code::Blocks plugin that had to be installed separately. I did get everything working, and built a simple BRX module without error — but then it refused to load in Bricscad.

Now, one of the things about Linux that is very different to Windows is the culture of users. Googling for help on something invariably leads to instructions that start out “It’s extremely easy to do this on Linux” and end with 4 pages of command line gibberish, including a list of all the stuff that must first be installed for these instructions to work correctly, and the inevitable warning that the instructions may only work on certain “distros” and versions of Linux.

I learned this first hand when I set out to determine why my .brx module was failing to load. I eventually learned that I had to manually add the BRX SDK library path to Bricscad so it could find the needed libraries at runtime. That was the easy part. To make a long (and rather harrowing) story short, I eventually determined that I was missing a single required library (the libgl graphics library). Installing the library in Ubuntu got things working.

Loading a test BRX module in Bricscad

Next up: figuring out how to build a Linux BRX module in Windows using the Visual Studio 2010 IDE. That should prove to be very interesting indeed.

Until now, the one thing that didn’t work in VS 2010 was the ObjectARX Wizard. I’m happy to report that the latest wizard seems to works fine in both VS 2008 and VS 2010. Thanks to Alexander Rivilis for revealing the secret URL:
http://images.autodesk.com/adsk/files/objectarx_2012_wizards.zip

The best way to test in a plain vanilla AutoCAD configuration is to install it on a virtual machine. I use VMWare Workstation for this purpose (Microsoft’s Windows Virtual PC is another popular choice). Virtual machines are completely separate from the host system, so they provide an ideal testbed for isolating software problems. Unfortunately, virtual machines take time and resources to build and manage, so they won’t work for everyone.

For most common cases, it’s sufficient to start AutoCAD with a “vanilla” profile (ideally using the /p <profile_name> target argument in a shortcut) that loads only the standard AutoCAD menu and no third party add-ons, but this can be a bit tricky. The problem is that some third party add-ons are determined to load, and it’s difficult to stop them.

Lisp add-ons can be thwarted by ensuring that your “vanilla” profile uses a clean path (i.e. a folder structure containing only unmodified out-of-the-box files) for all support files. In addition, you must ensure that only the standard unmodified menu files are loaded. Finally, you can set the DEMANDLOAD system variable to zero to disable all object enablers from loading. Note that AutoCAD must be closed and restarted after any changes to see the effect.

Finally, here’s one last tip: you can enter (arx) at the AutoCAD command prompt to see a list of loaded ARX modules. Some ARX modules may automatically load at startup; those can be disabled by tweaking the registry, but I don’t recommend that unless you really know what you’re doing.

In the end, the goal is to determine whether the problem can be reproduced on a “plain vanilla” configuration. If the problem goes away, you can start adding things back one at a time to see when the problem resurfaces. If the problem still occurs on a clean configuration, you can focus attention on other possible causes.

To divide and conquer an AutoCAD drawing, I start by getting a quick feel for what is in the drawing and how it is structured (I use Periscope for this; in fact I originally wrote Periscope for this purpose). The general approach I use is to eliminate roughly one half of the drawing at a time by erasing an arbitrary half, then checking to see whether the problem still exists in the remaining half. Doing this reliably requires some care.

If the drawing has layouts, I start by erasing all layouts except model space. I then save the new file with a new filename, close AutoCAD, restart, open the last file, and test to see whether the problem still exists. If the problem went away, I go back to the original file and start over, erasing everything in model space, then repeat the saveas/close/reopen sequence. Once I pin the problem down to a specific layout (or layouts), I start working on individual drawing entities.

A typical iteration consists of erasing roughly half the drawing entities, then checking whether the problem persists. If the problem goes away, back up and erase the other half, otherwise continue. Entities can be erased either by selection or using QSELECT. If the drawing consists of entities nested inside blocks, I first try erasing the block references; if the problem goes away, I back up and use BEDIT to erase part of the block content.

While going through these iterations, I sprinkle in a periodic purge (using SuperPurge, of course) to remove hidden and invisible objects that become unreferenced as visible entities are erased. I continue this process until I have a drawing file cleaned of everything except the bare minimum needed to reproduce the problem. Often, but not always, that means a drawing file with a single visible entity in it.

The key to success is being methodical and saving with incremented filenames so that it’s easy to back up a step and start over when the problem disappears. Closing and restarting AutoCAD between each iteration helps ensure that the test is not influenced by erased objects remaining in memory. With experience and a bit of skill in correctly guessing where to look, I’ve learned that almost all drawing-specific problems can be narrowed down to the bare minimum in 5 to 10 iterations.

The problem is that “empty drawing” is too nebulous. No drawing is completely empty, and in any case, even drawings with no visible geometry can be far from empty. What I really want to test is whether the problem occurs with a drawing that is as nearly empty as possible. To achieve that, I ask the customer to perform the test on “a new drawing created from scratch, with no template”.

New file with no template

The extra “no template” instruction is necessary because just creating a new drawing will bring in any flotsam and jetsam saved in the default template drawing, which could affect the results.

[Side note: it is my experience that many template drawings contain a lot of invisible junk that does nothing but slow things down. If you're curious about your own templates, open them and use my shareware SuperPurge tool to see what all they contain. You may be surprised.]

If the steps for reproducing the problem are such that they require some visible geometry, I ask the customer to draw a unit circle at the origin in a new “no template” drawing.

If the problem still occurs in a minimal drawing, then it is not drawing-specific; otherwise the next step is to divide and conquer the drawing to narrow things down further.