To make it less confusing when working with multiple versions of ObjectARX, I recommend removing the ObjectARX SDK folders from your global VC settings, and adding them instead to the project settings for each individual project. Doing so gives you more local control over the project, and makes it less confusing when you need different build configurations to use different versions of ObjectARX in the same project. ...
[Update: Visual Studio 2010 now includes a built in feature called native multi-targeting that replaces the need for VC Build Hook. Read this blog post to learn how to use VS 2010 to target older versions of Visual Studio.] I created the VC Build Hook utility in order to make it possible to use the current Visual Studio IDE for building ObjectARX applications that target any version of AutoCAD. This is desirable because ObjectARX applications must be built by the Visual C/C++ build tools that correspond to the ObjectARX SDK version for the target AutoCAD version. VC Build Hook works by switching the executables path during a Visual Studio build and pointing the paths to the desired version of the Visual C/C++ build tools. In addition, VC Build Hook automatically fixes build tool command options to account for differences between VC versions so that build commands produced by one version of Visual Studio are correctly interpreted by another version of the build tools. Assuming you've already set up your projects as described here (note that you must have a working installation of the necessary version of Visual C/C++ build tools and runtime libraries), then you'll need to install the current version of VC Build Hook: ...
The registry demand loading feature in AutoCAD, BricsCAD, and ZWCAD is a great method for loading ObjectARX/BRX/ZRX modules automatically at startup, and it's relatively easy to create the demand loading settings from an installation program or MSI file at install time. Unfortunately it only works for ARX/BRX/ZRX files (and also with .NET dlls in AutoCAD 2006 and later). Some years ago, I created a small ARX module called VLXLoad. The purpose of this module was to work as a stub to load an associated .vlx file of the same base name in the same folder. I've since renamed this small utility to LspLoad and expanded it so that it can load any type of LISP file. The idea is to rename the LspLoad.*.* file to the name of the associated .lsp/.vlx/.fas file (i.e. MyApp.18.arx will look for and load MyApp.vlx in the same directory), then create demand load registry settings to load the renamed LspLoad module. Voila, the associated LISP file gets loaded as if it was being demand loaded from the registry. ...
With the advent of AutoCAD 2004 and Visual Studio .NET (aka Visual Studio 2002), ObjectARX programmers are again faced with the task of moving from an older version of a compiler (VC6) to a newer version (VC7). Rather than maintain two versions of compilers and two versions of projects for supporting both AutoCAD 2000/2002 and the new AutoCAD 2004, it makes sense to use only the newest IDE to support *all* target AutoCAD platforms. ...
A common complaint among ObjectARX programmers is that Visual C/C++ doesn't display IntelliSense context menus for classes defined in the ObjectARX headers. The trick is to include all the ObjectARX headers files somewhere in your solution. I created a new folder called ARXHeaders with subdirectories for every version of the ObjectARX SDK. ...
Despite the minor numerical change from Visual C/C++ version 7 to 7.1, Microsoft made some major changes in the compiler and linker in order to become more C++ standard compliant. These changes make it virtually impossible to use 7.1 to build for ObjectARX 2004 and earlier ObjectARX versions. The new compiler chokes on the earlier versions of ATL and MFC libraries because they were not standard compliant, yet these are required when building for ObjectARX because of its reliance upon Autodesk libraries. What's more, the tricks outlined here are not enough to solve this problem. ...
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.
Although my blog has become relatively stagnant, the rest of my life has been changing — and there are even bigger changes ahead. My children have been growing into adulthood one by one, and my parenting time has been shrinking as a result. To take up the slack, I bought a bike a few years ago and started riding it on the many local bike trails. Initially cycling was a way to get healthy and enjoy the outdoors, but it has turned into much more. Riding a bike is great exercise, but it’s also a fantastic social activity when you do it with friends, and I have made many new friends in the very large and growing cycling community here in Ohio. ...
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. Share ThisTweetFacebookLinkedInTumblrStumbleDiggDelicious
New Visual Studio C/C++ users sometimes get tripped up by IntelliSense errors, so today I’ve decided to share the secret, undocumented solution: just turn them off! IntelliSense is a nice user interface feature when it works, but it has nothing whatever to do with building and running your C/C++ code. IntelliSense errors do not equal compiler errors, and trying to “fix” them is fruitless. ...
Recently I had to debug an intermittent access violation exception in one of my AutoCAD plug-ins. I needed to get the exception while the debugger was attached so I could break the process and analyze the state of memory before AutoCAD’s global exception handler got control. Unfortunately, sometimes it took several hundred runs before the exception occurred. ...