Programming on ManuSoft

LspLoad updated for BricsCAD 17 and ZWCAD 2017

Fri, 04 Nov 2016 15:30:23 +0000

I have updated the automatic lisp loader modules (LspLoad.zip on my freebies page) to support BricsCAD V17 and ZWCAD 2017. Note that the source code for LspLoad is also available.

QuirkyPolyline updated for Bricscad and ZWCAD+

Tue, 09 Dec 2014 04:39:50 +0000

I’ve updated QuirkyPolyline and added support for Bricscad 14 – 15 and ZWCAD+ 2014 – 2015. The new QuirkyPolyline download is available on the ObjectARX freebies page.

Building a commercial grade lisp plugin installer in 5 easy steps

Tue, 18 Feb 2014 01:36:34 +0000

Rumors about the death of AutoLISP have been floating around for many years, but fear not, those rumors are greatly exaggerated. Bricscad and ZWCAD both have excellent support for lisp plugins, so well-written lisp code is truly cross-platform and enjoys a large and growing audience. Unlike other languages, the vast majority of lisp code works unmodified on any hardware architecture, in any version of Windows, and inside any host application that supports it, including AutoCAD versions released more than a decade ago. On top of that, OpenDCL gives lisp developers the power of a modern event-driven user interface that can put their lisp plugins on the same playing field as plugins written in any other language. This is a powerful combination, and given lisp’s low entry cost, it is not surprising to see lisp continuing to enjoy strong support in the developer community.

Don't catch what you can't handle

Fri, 07 Feb 2014 00:10:41 +0000

One of the cardinal rules of C++ exception handling is “don’t catch what you can’t handle”. Of course there are always, er, exceptions to the rule, but the basic principle always holds. The consequences of violating the rule are less severe in the .NET world, but even there it’s a good rule of thumb.

LspLoad now supports Bricscad V14 and ZWCAD+ 2014

Fri, 01 Nov 2013 10:48:12 +0000

I have updated the automatic lisp loader modules (LspLoad.zip on my freebies page) to support Bricscad V14 and ZWCAD+ 2014. Note that the source code for Lspload is also available.

LspLoad Updated for AutoCAD 2014 and Bricscad 13 64-bit

Sat, 13 Apr 2013 20:58:40 +0000

The automatic lisp loader modules (LspLoad.zip on my freebies page) have been updated to add support for AutoCAD 2014 and Bricscad 13 64-bit. The modules are now digitally signed so that AutoCAD 2014 loads them quietly.

C++ function declaration tips

Wed, 06 Feb 2013 22:59:29 +0000

Creating and calling functions is one of the most fundamental tasks in C++ programming. The function declaration serves as the primary description of a function’s interface - or contract - with callers, thereby making it the most important piece of code documentation. A good function declaration should convey as much information as possible. I’m sure an entire book could be written on the topic of function interface design, but I’ll just touch briefly on a few factors to consider when designing a function’s interface.

Using /delayload to specify dependent DLL path

Sat, 26 Jan 2013 01:03:48 +0000

Let’s say you have an ObjectARX module with an implicit dependency on another DLL. Your installer puts both your ARX module and the dependent DLL into a private application folder. Windows must be able to resolve the implicit DLL dependency at load time, otherwise it will fail to load your ARX module. Alas, Windows will not automatically search for the dependent DLL in your application folder, even though your ARX module is located there. Therefore your ARX module won’t load because the dependent DLL cannot be resolved.

QuirkyPolyline: exposing foolish programmers

Wed, 09 Jan 2013 02:38:45 +0000

In AutoCAD, the AcDbCurve class defines a general parametrized curve. On a parametrized curve, points in space are mapped to real numbers (parameters) by an arbitrary function F(p) for values of p from the curve start parameter to the curve end parameter. Defining a curve this way simplifies working with complex 3D curves because one can work in the curve’s one dimensional “parameter space” instead of the more complex three dimensional cartesian space.

RoboCache for Windows offline files cache management

Wed, 02 Jan 2013 08:50:27 +0000

I’ve written before about RoboCache, a command line utility I wrote for managing the offline files cache in Windows Vista, Windows 7, and now Windows 8. After using the utility internally for a few years, I decided that I might as well clean it up and make it available to the rest of you. RoboCache is now available at the ManuSoft web site. There is a shareware version available, and you can purchase the registered version at the ManuSoft store (cost is 25 USD for a single user license).

Polymorphic bit flags in C++

Wed, 19 Dec 2012 11:55:45 +0000

I often encounter cases in ObjectARX programming where numerous boolean flags need to be persisted as part of an AutoCAD database object. For filing and for passing around to other functions, it’s most efficient to package those bit flags into a single unsigned integer. Below is an example that demonstrates how to use a union inside a containing class that can be simultaneously used as either a single unsigned integer or as individual booleans.

Checking function return values

Thu, 30 Aug 2012 15:48:36 +0000

A lot of you are guilty of not checking return values from API function calls. I’ll bet you have a good excuse, like “it’s a lot of extra typing for no reason”, or “that function should never return an error code”.

Registering an ARX/BRX module as a COM server

Tue, 11 Oct 2011 00:18:41 +0000

If you’re developing ARX modules that need to be registered as a COM server, you’re faced with some decisions about how to register them. In the old days before anyone cared about user permissions, registration could be safely accomplished at runtime, even via AutoLISP. Unfortunately runtime COM server registration just doesn’t work reliably any more under limited user accounts, not to mention registry redirection on 64-bit platforms. There is only one reliable way to register COM servers, and that’s doing it at install time under elevated privileges.

OpenDCL 6

Fri, 05 Aug 2011 14:32:27 +0000

You may not have noticed, but AutoLISP is still alive and kicking. This is evidenced by the growing community of developers and hobbyist programmers using the latest release of OpenDCL, the free graphical user interface library for AutoLISP applications. If you’re not familiar with OpenDCL, check out the newly released OpenDCL 6.

The MFC Balloon

Fri, 15 Apr 2011 17:24:46 +0000

The MFC version that ships with Visual Studio 2010 is known to cause major explosions in file size when you link statically. To avoid that problem, I use the Visual Studio 2008 build tools for such cases. I recently got quite a surprise when I rebuilt one such MFC application and discovered that the executable had ballooned from 400kb to 2MB in the space of one week despite only very minor changes.

BRX on Linux: Getting Started

Sun, 10 Apr 2011 11:19:35 +0000

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.

ObjectARX Wizard for Visual Studio 2010

Fri, 01 Apr 2011 20:04:33 +0000

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.

Simplifying the problem: plain vanilla configuration

Sat, 26 Feb 2011 14:21:32 +0000

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.

Simplifying the problem: divide and conquer

Fri, 25 Feb 2011 14:08:51 +0000

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.

The art of simplifying the problem

Wed, 23 Feb 2011 14:06:57 +0000

One of the most important skills in resolving technical problems is not problem solving, but problem definition. Stripping a problem down to its essence often makes the solution obvious. I think this is generally true, but especially true in my experience with software tech support and tracking down software bugs.

What's the diff?

Wed, 29 Dec 2010 16:32:31 +0000

One of the required tools in a programmer’s toolbox is a tool for comparing files. File comparison utilities have come a long way since the original Unix diff command, but this genre of utilities is still referred to as diff tools. For Windows, I use an open source diff utility called WinMerge. WinMerge includes a shell extension that makes it easy to use from within Windows Explorer.

Debugging heap corruption with PageHeap

Wed, 15 Dec 2010 12:58:33 +0000

Heap corruption bugs in C++ code can present some difficult debugging challenges. Often the actual corruption goes unnoticed until some apparently random point in the future when the corrupt memory is accessed by unrelated code. In such cases, it’s almost impossible to infer the location of the bug using typical debugging tools.

Visual Studio 2010 Migration Post Mortem

Mon, 18 Oct 2010 23:49:22 +0000

I have more or less completed the task of migrating my internal projects to Visual Studio 2010. Native C++ programmers are pretty low on the totem pole of programming coolness these days, but Microsoft did throw us a few bones. At this point I have to say I’m ambivalent overall with VS 2010, but I really like some of the architectural changes and I’m excited about the future.

Visual Studio 2010 Native Multi-Targeting

Thu, 07 Oct 2010 02:16:19 +0000

I was hoping that Microsoft would address the need to target earlier versions of Visual Studio within the Visual Studio 2010 IDE, but since they decided to punt, I tackled the problem myself. I’ve released my solution as an open source project named Daffodil for Visual Studio.

GlowCode Success Story

Sat, 12 Jun 2010 18:56:33 +0000

I use GlowCode for profiling ObjectARX applications. As far as I know, this is the only profiler that works with AutoCAD. What makes GlowCode special is that it can instrument code on the fly, including a monster like AutoCAD. It has a clunky interface that takes some patience to figure out, but it’s a lifesaver when you need it.

Visual Studio 2010 Ships

Mon, 12 Apr 2010 20:34:40 +0000

Visual Studio 2010 shipped today accompanied by .NET Framework 4.0. I blogged before about the switch to using the MSBuild build system, and how that theoretically could be helpful in targeting multiple AutoCAD versions from the same solution. The shipping VS 2010 does not support non-Unicode response files, so out-of-the-box it cannot target VC 7.0 (for AutoCAD 2006 and earlier). When time permits, I’m planning to see if I can find a workaround; in the meantime, I’ll continue to use VS 2008 for ObjectARX.

AutoCAD for Mac

Sat, 10 Apr 2010 16:51:11 +0000

There have been rumblings and rumors for a while now about a native Mac OS X port of AutoCAD. The ObjectARX 2011 SDK header files contain clear evidence of a native Mac port in the works. The evidence comes in the form of code comments and changes made to the files so that they work with the GCC compiler and the Mac OS X libraries.

Port Your ObjectARX Code to 64 Bit

Thu, 11 Mar 2010 23:08:00 +0000

AutoCAD versions since AutoCAD 2008 (and since AutoCAD LT 2009) have included both 32 bit and 64 bit flavors on the same media. If you install on a 64 bit Windows system, you get the 64 bit AutoCAD; otherwise you get the 32 bit AutoCAD. The 64 bit AutoCAD can take advantage of as much memory as you can throw at it, whereas the 32 bit version is limited to 2 GB (3 GB if you cheat). They should be otherwise identical in theory, but in practice there are major differences.

One big difference is VBA. Microsoft put VBA out to pasture many years ago when they introduced the .NET framework, so there will never be a 64 bit version of VBA. Autodesk had to resort to a seriously inefficient kludge to get it to work at all in the 64 bit flavor of AutoCAD (VBA has to run in a separate 32 bit process, which makes typical applications two orders of magnitude slower).

The other big difference is that any third party ObjectARX applications must be installed for the correct architecture. A 32 bit ObjectARX application will not work in a 64 bit AutoCAD. [Note that .NET (or “managed”) applications typically work fine in both architectures – I’m referring to native C++ ObjectARX applications only.]

On the Autodesk discussion groups, many people ask how they can install the 32 bit version of AutoCAD on their new 64 bit operating system. Why would they want to do that? Almost always because they need to use an application that is only available for 32 bit AutoCAD architectures, or because they discover that their VBA applications become unbearably slow.

It is possible, with some hacking of the AutoCAD installation database, to install the 32 bit flavor of AutoCAD on a 64 bit system, but I don’t recommend that. There is just no excuse any more to not support the 64 bit architecture. If you find yourself in this situation, put pressure on the developer of the application to get it ported.

In fact, if you rely on an application that hasn’t been ported to the 64 bit architecture, I’d like to hear from you. Add a comment to this post and let me know the name of the application. If you are a vendor or developer that has not yet ported your 32 bit application, please contact me – I will gladly port it for you. Even large applications can typically be ported in several hours.

BTW, I am well aware that even Autodesk is guilty of not supporting 64 bit platforms in some of its vertical market AutoCAD versions (and corresponding object enablers). I certainly hope they remedy that situation in the next release cycle.

Visual Studio 2010 and VC Build Hook

Mon, 11 Jan 2010 20:32:00 +0000

[Update: See Visual Studio 2010 Native Multi-Targeting]

Many of you use my VC Build Hook utility to target multiple versions of AutoCAD from a single solution in Visual Studio 2008. Visual Studio 2010 now includes a new feature called native multi-targeting that performs the same function as VC Build Hook. The new feature works great for using build tools back to VC 7.1, but it does not work with VC 7, which is required for targeting AutoCAD versions 2006 and earlier.

Automatic LISP Loading

Thu, 24 Dec 2009 12:12:00 +0000

There are a myriad of ways to load AutoLISP applications in AutoCAD, including acaddoc.lsp, an .mnl file, the Startup Suite, and manually by various means. For application developers wishing to deploy their applications to others, all of these methods have drawbacks. The ideal solution should be easy to implement in an installation program, require minimal or zero changes to the user’s AutoCAD configuration, work the same way across all versions of AutoCAD, and easily undone when the application is uninstalled.

ArxDbg Utility

Wed, 23 Sep 2009 18:31:00 +0000

ArxDbg is the name of a sample project that has been included with the ObjectARX SDK for many years. It’s primary purpose is to demonstrate how to use the ObjectARX API, but it is a complete free-standing utility in its own right. ObjectARX programmers often use this utility during development for testing and exercising their application code, but it can be useful to anybody, not just programmers.

Disable InfoCenter in AutoCAD 2010

Mon, 30 Mar 2009 18:13:00 +0000

[Update: See Disable AutoCAD InfoCenter]

In case you missed it, Tony Tanzillo has posted instructions for disabling the InfoCenter in AutoCAD 2010. AutoCAD 2010 starts faster when the InfoCenter is disabled.

To make it easy, I’ve created an AutoLISP file that defines commands named DisableInfoCenter and EnableInfoCenter:

ObjectARX 2010: Dealing With Missing Exports

Sat, 28 Mar 2009 16:54:00 +0000

In the new ObjectARX 2010 SDK, Autodesk has added some new virtual member functions that are not exported as they should be. For example, the AcGiFaceData class has had two new virtual functions added for setting and getting the face transparency:

class AcGiFaceData: public AcRxObject
{
//[… deleted for brevity]
ACDB_PORT virtual AcDbObjectId materials() const;
ACDB_PORT virtual AcGiMapper mappers() const
virtual void setTransparency(const AcCmTransparency transparency);
virtual AcCmTransparency transparency() const
private:
AcGiImpFaceData mpAcGiImpFaceData;
};

As you can see, whoever added the new functions neglected to prefix them with the ACDB_PORT macro. ACDB_PORT evaluates to __declspec(export), which tells the compiler to export the function. Since the macro is missing, the new functions are not exported from acdb18.dll.

Since these are virtual functions, you won’t have any problems calling them through a pointer to an AcGiFaceData object that was constructed by AutoCAD. The problem arises when you derive a class from AcGiFaceData. Since the functions are not exported, the linker has no way of resolving their address for creating the virtual function table of your derived class. This results in linker errors:

acrxEntryPoint.obj : error LNK2001: unresolved external symbol “public: virtual void __thiscall AcGiFaceData::setTransparency(class AcCmTransparency const )” (?setTransparency@AcGiFaceData@@UAEXPBVAcCmTransparency@@@Z)
acrxEntryPoint.obj : error LNK2001: unresolved external symbol “public: virtual class AcCmTransparency * __thiscall AcGiFaceData::transparency(void)const " (?transparency@AcGiFaceData@@UBEPAVAcCmTransparency@@XZ)
Following is an example that results in these errors:

class AcGiFaceDataEx: public AcGiFaceData
{
public:
AcGiFaceDataEx() {}
~AcGiFaceDataEx() {}
} Test;

The only solution is to provide an implementation of the missing functions. In this case, it could be accomplished by something like this:

class AcGiFaceDataEx: public AcGiFaceData
{
AcCmTransparency mpTransparency;
public:
AcGiFaceDataEx() : mpTransparency( NULL ) {}
~AcGiFaceDataEx() { delete mpTransparency; }
virtual void setTransparency(const AcCmTransparency transparency)
{
delete mpTransparency;
mpTransparency = (transparency? new AcCmTransparency( transparency ) : NULL);
}
virtual AcCmTransparency transparency() const { return mpTransparency; }
} Test;
This will fix the linker errors, but there is no guarantee that it will work as intended. AutoCAD might access its internal transparency value directly without calling through the member functions, which means it would never “see” the transparency set through the replacement member functions. Furthermore, the addition of the new pointer member changes the size of the class, which causes AcGiFaceDataEx arrays to have a different memory footprint than AcGiFaceData arrays. Lastly, what if Autodesk fixes the problem in a future AutoCAD service pack?

The ideal solution should not change the size of the class. It should check at runtime whether the function is exported, then use the exported function if it exists. That way, code that is written now will use the exported function if and when it becomes available in a future version of AutoCAD. When the function is not exported, an alternate implementation must be provided. This is not an unusual scenario, and the solution I present for the specific case of AcGiFaceData can be adapted to the more general problem.

In the AcGiFaceData case, the missing functions are virtual functions. Knowing this, it is possible to use a trick to get the address of the real function. In the code below, the function getAcGiFaceData_vtable() constructs a temporary AcGiFaceData object, from which it extracts a pointer to the object’s virtual function table. The virtual function table is just an array of function pointers, so the address of the desired function can be obtained by indexing into the virtual function table. The question is, how far? By counting virtual functions and data members starting from the top of the class hierarchy: in this case, 6 virtual functions in AcRxObject plus 16 virtual functions in AcGiFaceData = 22.

Note that obtaining a function pointer this way relies on Visual C++ implementation details, but this is safe to do since all ObjectARX modules must be compiled in Visual C++.

Following is my solution to the missing AcGiFaceData functions:

#pragma warning(push)
#pragma warning(disable: 4608)
template < typename Src, typename Dest >
Dest force_cast( Src src )
{
union _convertor { Dest d; Src s; _convertor() : d(0), s(0) {} } convertor;
convertor.s = src;
return convertor.d;
}
#pragma warning(pop)

static FARPROC getAcGiFaceData_vtable()
{
static FARPROC rfVTable = (FARPROC**)&AcGiFaceData();
return (rfVTable? rfVTable : NULL);
}

void AcGiFaceData::setTransparency( const AcCmTransparency transparency )
{
typedef void (AcGiFaceData::F_setTransparency)( const AcCmTransparency );
static F_setTransparency pfSetTransparency = force_cast< FARPROC, F_setTransparency >(GetProcAddress( GetModuleHandleA( “acdb18.dll”), “?setTransparency@AcGiFaceData@@UEAAXPEBVAcCmTransparency@@@Z” ));
if( !pfSetTransparency )
{
static FARPROC rfVTable = getAcGiFaceData_vtable();
if( rfVTable )
pfSetTransparency = force_cast< FARPROC, F_setTransparency >( rfVTable[22] );
}
if( pfSetTransparency )
(this->pfSetTransparency)( transparency );
}

AcCmTransparency AcGiFaceData::transparency() const
{
typedef AcCmTransparency (AcGiFaceData::F_transparency)() const;
static F_transparency pfTransparency = force_cast< FARPROC, F_transparency >(GetProcAddress( GetModuleHandleA( “acdb18.dll”), “?transparency@AcGiFaceData@@UEBAPEAVAcCmTransparency@@XZ” ));
if( !pfTransparency )
{
static FARPROC rfVTable = getAcGiFaceData_vtable();
if( rfVTable )
pfTransparency = force_cast< FARPROC, F_transparency >( rfVTable[23] );
}
if( pfTransparency )
return (this->*pfTransparency)();
return NULL;
}

Missing Menu Madness

Mon, 22 Dec 2008 18:15:00 +0000

One of my many complaints about about the CUI system introduced in AutoCAD 2006 is that it's not very friendly to third party developers. In my opinion, it's not very friendly to end users either, but I digress...

One example of the unfriendly CUI is the case where a third party application installs a partial menu. In the pre-CUI days, adding a partial menu was an easy way to add an application specific menu to AutoCAD without making any changes to the end user's existing menu files. If the application was later uninstalled, the uninstall script could remove its menu and clean up the registry, leaving no trace behind. CUI breaks that scenario.

Debugging ObjectARX: Break on Exception

Mon, 12 May 2008 11:11:00 +0000

I have presented a class entitled High Octane ObjectARX at Autodesk University the past two years. In 2006 the focus was on project organization, and last year I focused more on techniques for supporting multiple versions of AutoCAD with a single Visual Studio solution, touching briefly on testing and profiling. For 2008 I plan to focus on debugging.

Hotel Autodesk

Wed, 30 Apr 2008 12:06:00 +0000

Steve Johnson asks “where have all the developers gone?”, and Deelip Menezes wonders in a comment whether Autodesk’s annual release cycle for AutoCAD is part of the problem. I’ve always said that an annual release cycle is untenable. The annual release cycle is motivated by Autodesk’s desire to make the subscription program look attractive. Has it worked?

Based on what I’ve read and heard through the grapevine, it has definitely worked. More customers than ever are choosing the subscription model. In many cases, the annual subscription business model actually works well for software like AutoCAD, providing benefits for both Autodesk and their customers. But subscription is not for everyone.

In typical greedy big corporate fashion, Autodesk have overplayed their hand. Instead of concentrating on those customers for whom subscription makes sense and leaving the others to choose a different model, the “more is always better” marketing machine kicked in. Ergo, the annual release cycle carrot and the AutoCAD retirement program stick were invented. [Oh sorry, it’s called the Autodesk Loyalty Program.]

I am already seeing the beginnings of a movement of discontent among Autodesk customers, and I expect the annual release cycle to collapse under its own weight within another year or two. In the meantime, tremendous damage is being done. Customers, third party developers, authors, and consultants all suffer under the strain of the annual release cycle, but that’s only the tip of the iceberg.

To pull off annual releases, Autodesk have to be working on multiple versions of AutoCAD in parallel. While AutoCAD 2006 was being beta tested, AutoCAD 2007 and 2008 were already under development, and AutoCAD 2009 was already in the planning stages. When CUI was first introduced to the public, the new ribbon UI was likely already in the planning stages. Is it any wonder that the angry feedback about CUI was ignored?

When you have an annual release cycle with 3 or 4 future releases on parallel tracks, you can’t just stop and fix a fundamental design flaw. All you can do is increase your public relations budget. The harm done to third party developers is substantial, but the inability to shift gears and correct fundamental design flaws is the real travesty of the annual release cycle.

AU 2007 Post Mortem

Mon, 03 Dec 2007 15:12:00 +0000

The Hot List

Carl Bass munching on fast food in the food court, and spotted throughout the week yakking with average folks in the halls.
Staggered classes reduced the lunchtime crush experienced at AU 2006.
More ObjectARX programming classes this year. I’m pushing for creating a new “Developer” track for AU 2008.
The Matt Murphy Head (peace be upon him).
Meeting a lot of familiar faces and a few new ones!

The Cold List

VC Build Hook utility for Visual Studio 2008

Mon, 26 Nov 2007 02:27:00 +0000

The new Visual Studio 2008 has been released, and to celebrate, I’ve updated VC Build Hook. The updated utility allows you to use the new IDE while still building with older versions of the build tools.

Why is this necessary? If you build your AutoCAD 2007/2008 ObjectARX application with the Visual C/C++ 9.0 tools, AutoCAD will display a warning message about an incompatible module when you try to load it. You can use VC Build Hook to target all previous AutoCAD versions from a single Visual Studio 2008 solution (if you have the correct version of Visual C/C++ installed alongside Visual Studio 2008).

In my testing so far, existing Visual Studio 2005 projects build without problems in Visual Studio 2008 when VC Build Hook is installed and the new ‘BuildToolVersion’ property is set to the correct version.

OpenDCL 4.0 Debuts

Wed, 01 Aug 2007 09:51:00 +0000

OpenDCL 4.0 has finally been released. If you’re not familiar with OpenDCL, check it out at www.opendcl.com, or on SourceForge at sourceforge.net/projects/opendcl.

OpenDCL, based on the original commercial ObjectDCL software by Chad Wanless, is a modern replacement for the old DCL dialog control language in AutoCAD. The current OpenDCL Runtime supports AutoCAD 2002 through 2008 (except AutoCAD 2008 x64). It is designed to give AutoCAD end users and AutoLISP application developers a simple yet powerful way to design and use rich user interfaces in their applications.

The goal for version 4.0 was to get it stable and fix all the bugs, with minimal new feature development. OpenDCL 4.1 will add support for AutoCAD 2008 x64. After that we will start working on localized language versions, and adding new features.

OpenDCL is licensed under the GNU General Public License (GNU GPL) open source license, completely free to use, and source code is available on SourceForge.

Visual Studio Build Configuration Tip

Fri, 15 Jun 2007 12:30:00 +0000

I’ve received several emails recently from users of my VC Build Hook utility that mention switching the ‘UseVC7Paths’ setting on and off depending on the build configuration they are working on. If you are doing this, you need to change your project structure!

Introducing OpenDCL for AutoCAD

Wed, 31 Jan 2007 19:44:00 +0000

AutoLISP programmers may remember a product named ObjectDCL, by 3rd Day Software. ObjectDCL was released as open source in the summer of 2006 by developer Chad Wanless due to his inability to continue supporting the software because of “health reasons”. At the time, many users of ObjectDCL hoped that someone would update the code to work in AutoCAD 2007. Programmer David Robison did some work to get AutoCAD 2007 supported, but the project has been languishing, almost to the point of extinction.

After being asked by several ObjectDCL users whether I could help, I decided a few weeks ago to contribute to the community by getting the original C++ code updated to support AutoCAD 2007. As I am wont to do, I’ve ended up re-architecting much of the code in the process.

The results of my work are available now at the new OpenDCL project on SourceForge. The new 4.0 release is still in the alpha testing phase. If you program in AutoLISP and want to create rich user interfaces for your applications, check it out!

My ManuSoft manifest manifesto

Thu, 11 Jan 2007 13:10:00 +0000

With the advent of Visual Studio 2005 and automatically generated manifest files, the topic of when and how to use manifest files comes up occasionally. Since a default ObjectARX wizard generated project in Visual Studio 2005 generates an embedded manifest by default, most people don’t even think about it. Of course that was the whole idea – the manifest would ensure that the correct dependent DLLs get loaded, and voila, no need to think about it. One of my programming axioms applies in this case: TANSTAAFL.

The problem is that ObjectARX applications are not in charge. AutoCAD is in charge, and it will decide which VC runtime and MFC runtime DLLs to load. If your ObjectARX application loads a different VC or MFC runtime than the ones AutoCAD is using, you’ll encounter big problems. I’ve always advised disabling the manifest completely (see my ObjectARX Tips page) to avoid such a possibility. Unfortunately, there’s a catch.

The problem is that linking to the ATL80.DLL file isn’t possible by just disabling the manifest and doing nothing more. ATL is now a side-by-side (SxS) assembly, and it no longer lives on the Windows support path, so a standard un-manifested DLL won’t be able to find it. The preferred solution is to link statically to ATL (see Configuration -> General -> ‘Use of ATL’ in VS 2005 project properties) and avoid the problem altogether. If you only have one module that uses ATL, this is always the best solution.

The less desirable solution is to add a manually-created manifest that specifies the desired ATL SxS assembly, but ignores the VC and MFC runtime DLLs. You’ll still need to decide whether to make ATL shared or private, and in either case you must distribute ATL with your application to ensure that it is available when your application is deployed. You can cheat, and let VS generate your manifest file (instruct it to not embed the file), then just edit the resulting .manifest file to remove references to the VC and MFC assemblies. For example, here’s one that I generated (you’ll need to generate your own to ensure that the manifest matches the version you are redistributing):

<?xml version=“1.0” encoding=“UTF-8” standalone=“yes”?>
<assembly xmlns=“urn:schemas-microsoft-com:asm.v1” manifestversion=“1.0”>
<dependency>
<dependentassembly>
<assemblyidentity type=“win32” name=“Microsoft.VC80.ATL” version=“8.0.50727.762” processorarchitecture=“x86” publickeytoken=“1fc8b3b9a1e18e3b”>
</assemblyidentity>
</dependentassembly>
</dependency>
</assembly>

In my work, I’ve had very little need for manifests. The VC optimizer is able to strip the unused portions of statically linked ATL out of your code, leaving a much smaller footprint than the entire assembly would require. This eliminates the need to redistribute ATL with your application, thus reducing the overall potential for deployment issues. Nevertheless, there are exceptions to every rule, and your mileage may vary.

VCBuildHook updated for VS 2005 SP1

Tue, 19 Dec 2006 17:13:00 +0000

I’ve installed Visual Studio 2005 SP1 and have been busy testing all my projects to make sure they didn’t break. Microsoft did fix at least one of the bugs I reported (the resource editor choked on resource strings that contained an embedded NULL character), but the IDE still crashes fairly consistently if I initiate a large solution build while the Intellisense database is being rebuilt. SP1 also managed to break my VCBuildHook utility, so I’ve uploaded an updated version (2.0.3.0) for use with SP1.

Visual Studio 2005 Service Pack 1 is here!

Mon, 18 Dec 2006 16:51:00 +0000

Finally, the long awaited service pack 1 for Visual Studio 2005 is released! The service pack has been in the pipeline since soon after Visual Studio 2005 shipped last November, with release dates slipping month after month. The latest official release date was announced as “early 2007”. Perhaps this was an intentional attempt to alleviate some of the waiting pains with a suprise release (or maybe just the Microsoft rumor mill on autopilot).

Be prepared for a long install. The download page warns that it could take an hour or more to verify digital signatures before the service pack installation even begins.

Visual Studio Version Hunt

Fri, 08 Dec 2006 20:06:00 +0000

If you’ve been programming with ObjectARX for a while, you already know that each version of the ObjectARX SDK only works with a specific version of Visual Studio. Mazhar Basa touches on the subject in his article Components of ObjectARX Applications. My VCBuildHook utility makes it possible to build for multiple target AutoCAD versions from a single Visual Studio 2005 solution, but this utility still needs the older versions of Visual Studio to be installed on the same system in order to perform its magic.

The problem is, legitimate licenses of older versions of Visual Studio are hard to come by. Back in the Visual Studio .NET 2003 days, you could purchase a new license of VS 2003, then get a free license downgrade from Microsoft that allowed you to install Visual Studio 2002 side by side on the same system. That combination allowed you to target AutoCAD versions as far back as AutoCAD 2004. Unfortunately, Microsoft stopped offering the VS 2002 downgrade license when Visual Studio 2005 began shipping in November of 2006.

The end result is that new ObjectARX programmers are faced with a dilemma if they need to target anything older than AutoCAD 2007. One of the attendees at my “High-Octane ObjectARX” class at AU 2006 reminded me that MSDN (Microsoft Developer Network) members can download older versions of Visual Studio from the MSDN subscriber download center.

I have verified that Visual Studio .NET 2002 (VS 2002) is available for download to MSDN Professional subscribers, but I could not find Visual Studio 6.0, which is required to target AutoCAD 2000 - 2002. Visual Studio 4.2 (required for AutoCAD R14) is available though, so maybe I’m just not looking in the right place.

If you are a professional software developer, whether commercial or in-house, you should consider subscribing to MSDN for various reasons. If you’re an ObjectARX programmer and need to target older versions of AutoCAD, MSDN may be the only way to obtain the older Visual Studio build tools and libraries that you’ll need.

Demand Loading a VLX File

Mon, 04 Dec 2006 18:34:00 +0000

Some years ago I wrote a small ObjectARX module named VLXLoad that loads a .vlx file of the same name and in the same directory as the .arx module. I never claimed credit for the utility, but now that I’ve released the source code, I guess I’ll have to own up to it.

Have you made your mistake today?

Mon, 04 Dec 2006 07:38:00 +0000

It may seem strange to some of you, but I consider myself an artist. Visual Studio is my canvas, and the keyboard is my paintbrush. This is why I wouldn’t survive in a stuffy corporate environment with committees, red tape, and politics. I’m a visionary, not a software engineer. I don’t like to plan every little detail; I’d rather start with a grand vision and just let the code go wherever my vision leads it.

I confess this can be both a strength and a weakness. For example, I’ll spend two weeks refactoring perfectly working code because I don’t think it’s elegant enough. On the other hand, aesthetic beauty of structure and architecture is every bit as important in software as it is in other fields. It’s just that the benefits are intangible and more difficult to quantify.

Perfectly working code, you say? I admit, that’s a bit of a rarity these days. It’s a rarity precisely because not many programmers consider programming as an art form. Real artists are never satisfied with their work; they never stop working toward absolute perfection of both form and function.

This leads me to my real point. I have a favorite saying, “Have you made your mistake today?” Ironically, perfection can only be achieved by making mistakes. If you’re not making mistakes, you’re not learning. If you’re not learning, you’re not taking any risks. If you’re not taking any risks, you’re achieving mediocrity at best. Learn to make mistakes gracefully. Enjoy your capacity to learn and evolve toward perfection, no matter what kind of art you create.

Teaching and learning at AU

Mon, 04 Dec 2006 06:44:00 +0000

This year I taught an ObjectARX class at AU. As usual, there wasn’t nearly enough time to cover all the things I wanted to cover. I’m still contemplating what I want to do differently next year in order to be able to spend more time on the subject without boring everybody to death.