BRX on Linux: Getting Started

When I heard that Bricsys had shipped Bricscad for Linux, I was anxious to get to work on supporting the Linux platform. The first order of business was getting familiar with Linux. For that, I chose Ubuntu 10.10 32-bit running on a VMWare Workstation 7.1 virtual machine hosted on my Windows 7 64-bit workstation.

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.

ObjectARX Wizard for Visual Studio 2010

If you’re an ObjectARX programmer, you may still be using Visual Studio 2008 because you’ve been told that you must. It’s true that you need Visual Studio 2008 installed to compile native ObjectARX code, but with Daffodil you can do all your work in the Visual Studio 2010 IDE.

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

AutoCAD 2012 InfoCenter

If you’re upgrading to AutoCAD 2012, don’t forget to also disable InfoCenter (unless you really need it). Just download and install AcadInfoCenterOff to disable it on any version of AutoCAD or AutoCAD LT. If you already have AcadInfoCenterOff installed, you can just run a repair install to apply it to a newly installed instance of AutoCAD 2012.

Simplifying the problem: plain vanilla configuration

One of the stages in simplifying an AutoCAD software problem is to rule out (or in) third party add-ons as the cause. To do that, you’ll need a “plain vanilla” test bed configuration that consists of only the out-of-the-box components with no add-ons loaded.

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.

Simplifying the problem: divide and conquer

When a customer reports a drawing-specific issue, the next stage in simplifying the problem is to eliminate all drawing content that has no bearing on the problem. Unless the drawing object that causes the problem is obvious and can be immediately ascertained, I use the divide-and-conquer method to zero in on the cause.

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.